<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 28, 2018 at 1:59 PM, Geoff Keating via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span class=""><div></div><blockquote type="cite"><div><span style="font-family:Calibri,sans-serif;font-size:12pt">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.</span></div></blockquote><div><br></div></span><div>‘Subscriber’ is a defined term in the BRs:</div><div>
<div class="m_6228770905496930813page" title="Page 17">
<div class="m_6228770905496930813layoutArea">
<div class="m_6228770905496930813column"><p><span style="font-size:10.000000pt;font-family:'Cambria';font-weight:700">Subscriber: </span><span style="font-size:10.000000pt;font-family:'Cambria'">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.</span></p></div></div></div></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>That is, I can see several models of Reseller being done by CAs, so it's... perhaps nuanced</div><div>- One model is that the Reseller performs all the interaction with the CA, acting as an "Applicant Representative" of sorts</div><div> - 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.</div><div>- 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.</div><div> - 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.</div><div> </div><div>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.</div><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span class=""><div></div><blockquote type="cite"><div><span style="font-family:Calibri,sans-serif;font-size:16px">At this time, Trustico has not provided any information about how these certificates were compromised or how they acquired the private keys.</span></div></blockquote><div><br></div></span><div>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.”</div></div></blockquote></div><br></div><div class="gmail_extra">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?</div><div class="gmail_extra"><br></div><div class="gmail_extra">(This is the problem, I agree)</div></div>