[cabfpub] Ballot 194 – Effective Date of Ballot 193 Provisions

[Peter Bowen]

> On Apr 12, 2017, at 9:48 AM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Mon, Apr 10, 2017 at 8:05 PM, Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
> Ryan,
> 
> 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:
> 
> If the BRs were to have codified existing practices, we wouldn't have seen so many BR violations, both in audits and in issuance ;-)
> 
> If those BRs were improper - e.g. didn't align with practice _un_intentionally, we would have seen more proposals to change them.
>  
> 1) Customer contracts with CA for certificates and to establish an Enterprise RA that is authorized to confirm authenticity of certificate requests
> 2) CA and customer negotiate authentication credentials for Enterprise RA (could be signatures using public key crypto, shared secret, etc)
> 3) CA obtains documents that cover evidence of identity (for OV/EV) and evidence of domain control/authorization for customer specified identities and domains
> 4) CA receives application for certificate from Enterprise RA, authentication based on #2
> 5) CA uses information collected in #3 to verify the information in the request
> 6) If verified, issues certificate
> 
> 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.
> 
> #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.
> #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.
> 
> 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.

The Network and Certificate System Security Requirements are kind of special.  As far as I can tell, it is only the ETSI and WebTrust criteria that require anyone to follow them; they were never added to the BRs.   Therefore there is no requirement that an Enterprise RA follow them, as Enterprise RAs don’t need to follow ETSI or WebTrust according to the BRs.

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

The first paragraph of 4.2.1 discusses whether the certificate request contains all information that will end up in the certificate.  That is not relevant here.  For a DV certificate, for example, the request will contain all factual information to be included in the certificate (e.g. the public key and the dNSNames).

The third paragraph is the relevant portion.  This is where the _verification_ of information comes in to play and is even a “MAY”.  It is section 7.1.4.2 that mandates that the CA validate domain names info according to 3.2.2.4; 4.2.1 does not mandate such.

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

My view is that the process I described is compliant to the BRs and is the basic process I’ve observed as a customer of several different “account based” CAs.

Thanks,
Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170412/a8efd33a/attachment-0003.html>