> On Apr 10, 2017, at 10:53 AM, Ryan Sleevi via Public <[email protected]> > wrote: > > On Mon, Apr 10, 2017 at 11:48 AM, Doug Beattie <[email protected]> > 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 _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
