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? 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)
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
