[cabfpub] How do you handle mass revocation requests?

Wed Feb 28 14:33:41 MST 2018

Here’s 10 CSRs that people can correlate with the CT logs. I’ll create another 100 or so to dispel any doubt. 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Wednesday, February 28, 2018 2:01 PM
To: Geoff Keating <geoffk at apple.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>; Jeremy Rowley <jeremy.rowley at digicert.com>
Subject: Re: [cabfpub] How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 3:46 PM, Geoff Keating <geoffk at apple.com <mailto:geoffk at apple.com> > wrote:

> On 28 Feb 2018, at 11:08 am, Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:
>
>
>
> On Wed, Feb 28, 2018 at 1:59 PM, Geoff Keating via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:
>> This raises a question about the MDSP policy and CAB Forum requirements. Who is the subscriber in the reseller relation?  We believe this to be the key holder. However, the language is unclear.
>
> ‘Subscriber’ is a defined term in the BRs:
> Subscriber: A natural person or Legal Entity to whom a Certificate is issued and who is legally bound by a Subscriber Agreement or Terms of Use.
>
> That’s pretty clear and can’t be stretched to cover a reseller—a reseller won’t be able to comply with a Subscriber Agreement.
>
> At the risk of stretching things, I want to point out that taking this interpretation requires determining whether or not the Reseller is acting as an Applicant Representative during the process.
>
> In this case, is the Reseller legally binding the "user" (for lack of better word) to a Subscriber Agreement? If so, how does the CA determine that the Reseller is an authorized Applicant Representative, and thus entitled to legally bind the "user" to the Subscriber Agreement?

There are several ways this could be done.  However there is no question about the result, because that’s covered by 4.1.2:
Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant:

        • A certificate request, which may be electronic; and

        • An executed Subscriber Agreement or Terms of Use, which may be electronic

So after a CA issues the certificate, it’s easy to find out who the Subscriber was (for some definition of ‘who’): you get the CA’s copy of the Subscriber Agreement and look for the bit where it says “This is an agreement between ______ and <the CA>.” and see what was written in the blank.  (and yes, it does have to be between the Subscriber and the CA, not between the Subscriber and anyone else, see the definition of ’Subscriber Agreement’.)

Right, we're in violent agreement here :)

In addition under 9.6.1 item 6, the CA ‘represents and warrants’ that “the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements…” and under 9.6.3, "The CA SHALL implement a process to ensure that each Subscriber Agreement or Terms of Use is legally enforceable against the Applicant."

Here's where I'm saying I've seen fuzziness, with respect to the Reseller being nominated as an Applicant Representative (effectively), thus binding the Agreement between the user (who is now the Subscriber) and <the CA>. We've left under-specified how the Applicant Representative is authorized (under than 'express authority') - other than the 3.2.5 case.

To be clear: I don't think this is a defensible position, but I'm saying that based on how some of the issuance practices (or, more aptly, based on complaints we've heard re: various API integrations, including those of former CAs no longer members), this does seem an interpretation that some have advanced. The CA has defined a process (the Applicant Representative agreed), but it's not a very ... good... process. The CA would be at fault, but this is where the messiness is.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180228/242aa420/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4984 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20180228/242aa420/attachment-0001.p7s>