> On 28 Feb 2018, at 11:08 am, Ryan Sleevi <[email protected]> wrote: > > > > On Wed, Feb 28, 2018 at 1:59 PM, Geoff Keating via Public > <[email protected]> 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).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
