[cabfpub] How do you handle mass revocation requests?

[Ryan Sleevi]

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?

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

> 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?

(This is the problem, I agree)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180228/f092f881/attachment-0003.html>