[cabfpub] On the use of misuse - and the necessity to remove it

[Moudrick M. Dadashov]

Ok, I asked this because of RFC 3647 (see 4.1.4. Certificate Usage).

Thanks,
M.D.


On 2018-06-08 12:52, Ryan Sleevi wrote:
> I'm not sure. Misuse defines what it's not, while allowing for a whole
> host of things which it is. If it's defined as the antonym, and we
> defined that particular function or use, then that would forbid any
> uses not covered - probably not what is intended.
> 
> On Fri, Jun 8, 2018 at 5:36 AM, Moudrick M. Dadashov via Public
> <public at cabforum.org> wrote:
> 
>> Would it help if we define its antonym e.g. "designed for or capable
>> of a particular function or use"?
>> 
>> Thanks,
>> M.D.
>> 
>> On 2018-06-07 17:32, Ryan Sleevi via Public wrote:
>> 
>> On Thu, Jun 7, 2018 at 10:24 AM, Geoff Keating <geoffk at apple.com>
>> wrote:
>> 
>> On Jun 7, 2018, at 1:40 PM, Ryan Sleevi via Public
>> <public at cabforum.org> wrote:
>> 
>> In the pursuit of a definition, we tried to work backwards - what
>> are situations we think are misuse.
>> 
>> The dictionary definition of ‘misuse’ is:
>> 
>> use (something) in the wrong way or for the wrong purpose
> 
>  I'm not sure how this helps us move forward - were you suggesting
> that
>  4.9.1.1 would read:
> 
>  4. The CA obtains evidence that the Certificate was used for the
> wrong
>  way or for the wrong purpose;
> 
>  With such a definition, this supposes there's a right way or right
>  purpose.
> 
>  1) Do you believe the right purpose is wholly reflecting in the
>  Subscriber Agreement or Terms of Use?
>  2) Do you believe the right way is wholly reflected in the definition
>  I provided (from 1.1), that the right way is "used for authenticating
>  servers accessible through the Internet"
>   
> 
>>> Another suggestion was that it involved scenarios where the
>> Subscriber private key was in an HSM, and itself was not
>> compromised, but had signed things it was not expected to. This
>> wasn't elaborated on further - so I'm uncertain if this meant
>> things
>> other than the TLS handshake transcript - but this is already met
>> by
>> our definition of Key Compromise in 1.6.1, that is:
>> 
>>> ""A Private Key is said to be compromised if its value has been
>> disclosed to an
>> 
>>>     unauthorized person, an unauthorized person has had access
>> to it, or there exists a
>> 
>>>     practical technique by which an unauthorized person may
>> discover its value. “""
>> 
>> If a key is in a HSM and not exportable, then its value is not
>> disclosed, nor does an unauthorized person have access *to the
>> key*.  Dictionary definition of ‘access’ is 'obtain, examine,
>> or retrieve’ none of which apply here.  So it is not covered by
>> Key Compromise.
> 
>  I'm not sure - what are you providing an example of? I would think
>  that, say, generating a signed message that was not authorized, then
>  "an unauthorized person has access to it". Perhaps you could help me
>  understand this misuse - is it that the signature was authorized and
>  was directed to sign something that they didn't want to do?
>  _______________________________________________
>  Public mailing list
>  Public at cabforum.org
>  https://cabforum.org/mailman/listinfo/public [1]
>  _______________________________________________
>  Public mailing list
>  Public at cabforum.org
>  https://cabforum.org/mailman/listinfo/public [1]
> 
> 
> 
> Links:
> ------
> [1] https://cabforum.org/mailman/listinfo/public