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

[Ryan Sleevi]

Right, my goal in raising this issue was to make sure that there's a
consistent understanding - between Subscribers, Root Stores, Relying
Parties, and CAs - as to what Misuse is.

The proposal in the meeting had been "Treat misuse as defined in the CA's
CP/CPS", and the question that came from that was whether or not that
requirement was already captured in our existing reasons for revocation.

It sounds like there's a thin sliver that is distinct - since our
Subscriber Agreement/TOU requirements don't actually require that the
Subscriber use it in the CP/CPS-dictated way - so we can alternatively word
that requirement as:

4.9.1.1 (currently)
"4. The CA obtains evidence that the Certificate was misused;"

4.9.1.1 (future)
"4. The CA obtains evidence that the Certificate was misused, as defined by
Section 1.4.1 and 1.4.2 of the CA's CP/CPS;"

This makes it clear what misuse is, and where CAs should specify what
misuse is.

Similarly, we'd want to make sure that the Agreement/TOU was also updated
to reflect what "misuse" is to more accurately capture it, namely
9.6.3 (future)
"8. Acknowledgment and Acceptance: An acknowledgment and acceptance that
the CA is entitled to revoke the certificate immediately if the Applicant
were to violate the terms of the Subscriber Agreement or Terms of Use or if
the CA is required to revoke the certificate for one of the reasons
described in Section 4.9.1.1"

That above change would cover all CA-initiated revocation indemnification,
which CAs should appreciate.

On Fri, Jun 8, 2018 at 6:31 AM, Adriano Santoni via Public <
public at cabforum.org> wrote:

> IMO, a CA can describe in their CPS what "misuse" is, and the BRs should
> allow CAs to revoke certificates that are "misused" according to their
> respective CPSes. The CPS is a contract, in essence, and it's up to the
> Applicant to decide whether they like it or not. If a CPS provides for
> revocation of the SSL certificate in case it is used on a web site that
> (just for example, I am not suggesting anything to anyone) sells weapons
> ... the Applicant may not say they did not know, and I do not think that
> this need to be expressly covered in the BR (nor should it be forbidden).
>
> Il 08/06/2018 11:52, Ryan Sleevi via Public ha scritto:
>
> 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
>>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>
>
>
> _______________________________________________
> Public mailing listPublic at cabforum.orghttps://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180608/5b90b982/attachment-0003.html>