<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 10, 2017 at 8:05 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ryan,<br>
<br>
The existing practices of many CAs that were intended to be codified into the BRs (at least as I understand it) include supporting the following workflow:<br></blockquote><div><br></div><div>If the BRs were to have codified existing practices, we wouldn't have seen so many BR violations, both in audits and in issuance ;-)</div><div><br></div><div>If those BRs were improper - e.g. didn't align with practice _un_intentionally, we would have seen more proposals to change them.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1) Customer contracts with CA for certificates and to establish an Enterprise RA that is authorized to confirm authenticity of certificate requests<br>
2) CA and customer negotiate authentication credentials for Enterprise RA (could be signatures using public key crypto, shared secret, etc)<br>
3) CA obtains documents that cover evidence of identity (for OV/EV) and evidence of domain control/authorization for customer specified identities and domains<br>
4) CA receives application for certificate from Enterprise RA, authentication based on #2<br>
5) CA uses information collected in #3 to verify the information in the request<br>
6) If verified, issues certificate<br>
<br>
This would appear to be compliant with the BRs.  The CA can “obtain[] the data or documentfrom a source specified under Section 3.2” ahead of the application. (see 4.2.1)  I read “provided” in that sentence to mean “presented” or “prescribed” in 3.2, not that they had to be obtained as part of the processing of an application for a certificate.<br></blockquote><div><br></div><div>#1 - The relationship for designating an Enterprise RA comes from Section 1.3.2. It allows delegation of the performance of all, or any part, of Section 3.2, provided the process as a whole fulfills all of the requirements of Section 3.2.</div><div>#2 - An Enterprise RA is a Delegated Third Party (per 1.3.2). As such, the Network Security Controls apply, which restricts the type of authentication credentials for the Enterprise RA. That is, the Enterprise RA is fully expected to perform the steps in Section 2 (Each CA or Delegated Third Party SHALL). The only loosening of those requirements is in Secion 2, Item (n) (ii), which allows technical controls to restrict the DTP's ability to approve certificate issuance to a limited set of names in lieu of 2(n)(i), which requires multi-factor authentication.</div><div><br></div><div>I think this is important to stress - an Enterprise RA is a Delegated Third Party (this is entirely consistent with Section 8.4), and so each of these "Enterprise RA" accounts you described are fully expected to abide by the NSCs, and fully perform the duties of Section 3.2.</div><div><br></div><div>I don't think your read of provided in Section 4.2.1 is consistent with the first paragraph, since it explicitly describes it as being included as part of the certificate request. If you're going to make the argument that information can be obtained prior to the request, then the phrase to hinge on would be "the CA SHALL obtain the remaining information from the Applicant or, having obtained it from a reliable, independent, third party data source, confirm it with the Applicant." With that, you could at least question whether "having obtained" allows for it to have been obtained prior to the request (I don't think that'd be a consistent read, but hey, at least it'd be an argument)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It seems there in not alignment on the acceptable processes for issuing certificates.  I wonder if it might be helpful for you to write up what Chrome sees as the acceptable processes (a straw man) and have CAs give customer cases where the described processes do not work.  The reverse (having CAs describe every possible process) doesn’t seem as useful, as there are many assumptions today about how things work that probably will get missed going that direction.<br></blockquote><div><br></div><div>I disagree that it doesn't seem as useful. I think it remains incredibly useful if CAs who believe they are affected negatively by this to explain how. To date, I don't think there's been a good explanation, although certainly, there have been attempts (and I'm greatly appreciative of them, even if I disagree with them). </div></div></div></div>