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

[Peter Bowen]

> On Apr 10, 2017, at 10:53 AM, Ryan Sleevi via Public <public at cabforum.org> wrote:
> 
> On Mon, Apr 10, 2017 at 11:48 AM, Doug Beattie <doug.beattie at globalsign.com> wrote:
> Here are a couple of challenges the CAs face:
> 
> -        Updating all managed service Org and Domain information that is older than 27 months is a big task.  We normally do this at some point just before expiration (prior to 39 months), but now we need to do an entire year’s worth of customer data in a month.  That’s a big task.
> 
> 
> That's interesting. Could you clarify where you believe the Baseline Requirements permits what you described?
> 
> Specifically, Section 4.2.1 of the Baseline Requirements only permits reuse of information pursuant with Section 3.2 ("The CA MAY use the documents and data provided in Section 3.2 to verify certificate information")
> 
> Section 3.2 consistently describes the documents and data obtained as pursuant to processing the Applicant's request.
> 
> The term "Applicant" is explicitly defined in Section 1.6.1 as "The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber."
> 
> 
> As such, I don't believe it's valid to do so prior to expiration unless and until there has been an explicit customer request, thereby making them "An Applicant", and thereby triggering the verification process of Section 3.2. As such, what you've described does not sound consistent with the Baseline Requirements, but perhaps there's a section or qualification within them that I've missed.
> 
> Assuming I'm correct, and no such section exists, then the process you've described - updating managed Org and Domain information - only triggers once the Org requests a new certificate. Since that happens regardless of expiring this year or next, I fail to see how that reasonably represents a significant hurdle, although I would be happy if you could describe how it is.
> 
> It seems that, effectively, regardless of _when_ the deadline is set, at some point, a customer is going to request a certificate (thereby becoming an Applicant), and you're going to have to reobtain the data, so that you can use it to reverify every request (as you're required to do, since verification is different than obtaining data and documents, and you MUST reverify the Applicant using those documents for every request).

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

Alternatively more of the validation could be delegated to the Enterprise RA as per 1.3.2 — specifically the CA can verify the domain namespaces for the RA and rely upon the Enterprise RA to validate FQDNs under the namespace.

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.

Thanks,
Peter