[cabfpub] How do you handle mass revocation requests?

[Geoff Keating]

> On 28 Feb 2018, at 11:08 am, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Wed, Feb 28, 2018 at 1:59 PM, Geoff Keating via Public <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’.)

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."

> That is, I can see several models of Reseller being done by CAs, so it's... perhaps nuanced
> - One model is that the Reseller performs all the interaction with the CA, acting as an "Applicant Representative" of sorts
>   - That is, Reseller may say "User is ID_X", and then directly talks to the CA on the user's behalf, saying "User that I call ID_X has agreed to your Subscriber Agreement" - without demonstration of proof, necessarily.
> - Another model is that the Reseller "introduces" the "user" to the CA. The CA has a notion and binding directly with the user (who themselves may be an Applicant Representative of a Legal Entity), and the Reseller has a _separate_ notion - which may be further linked to the CAs' notion, but are otherwise kept separate.
>   - That is, Reseller may say "User is ID_X", introduces them to CA and says "I call them ID_X", the CA assigns "ID_1", and records that if it needs to communicate with the Reseller again (e.g. for billing/recovery), "ID_1 == ID_X". The CA always has direct exchange with the user.
>  
> Looking at the reseller/integration APIs that CAs have shared in the past, I understand both models are deployed and in use, thus some degree of ambiguity.
> 
> In the first case, where the user always talks to Reseller and Reseller always talks to CA, I would argue that the Reseller is likely the Subscriber, and CAs are playing shellgames if they claim otherwise. I don't think this is necessarily bad (consider that hosting providers that terminate TLS themselves generally fall into this bucket).

In this first case, the Reseller has to be either part of the CA, or a Designated Third Party, because they’re doing things that the CA has to do (compliance with 9.6.3, for example).

>  In the second case, I think we've got a clearer separation that the "user" is the true Subscriber - because the CA can demonstrate they're legally bound (for some value) - and the Reseller is just a random nobody.

That can happen.  Sometimes resellers really have nothing to do with the certificate issuance process.

>> At this time, Trustico has not provided any information about how these certificates were compromised or how they acquired the private keys.
> 
> One question I would have is whether Trustico is in compliance with 6.1.2, "Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.”
> 
> If we accept Trustico is a Reseller, then what binding does any of the BRs have on them? They're not a CA, and they're not party to the Subscriber Agreement, so... so what?

It depends on whether they’re a first-kind or second-kind reseller.  In the second-kind case, the liability would fall onto the Subscriber for disclosing their private key to an unaffiliated person, which seems a bit unfair, but it’s what happens; and they get their certificate revoked (required under 6.1.2).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3321 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20180228/171cee76/attachment.p7s>