[cabfpub] Preballot - Revised Ballot 190

[Peter Bowen]

> On May 19, 2017, at 2:31 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Fri, May 19, 2017 at 5:16 PM, Peter Bowen <pzb at amzn.com> wrote:
> It was my intent and understanding that the 30 days had nothing to do with 4.2.1 or 3.2.2.4’s reuse requirements or allowances.  We wanted to limit how long a validation could be in a “pending” state. Therefore we added a constraint on the delta between the time the confirmation was received and the time the random value was generated.  As long as the CA recorded when the Random Value was created, recorded when the confirming response was received, and those were not more than 30 days apart, the data could be reused months or even years later.  
> 
> Ah, I see, on the basis that by confirming the reception of the random value - and thus completing all the necessary steps of 3.2.2.4.[method using random value] - this act constitutes a "completed confirmation of Applicant authority" (with respect to 3.2.2.4's reuse)

I was trying to explain that the 30 days reference has nothing to do with reuse.  It is intended to create a new independent rule — the specific step that requires receiving a confirmation utilizing the random value be completed within 30 days of generating the random value.  Once the step is completed it becomes data.  Depending on your take on other points, that might be data that is reused in future validations (4.1.2) or data that feeds into a completed validation, which is then reused (3.2.2.4).  Either way it was not written to limit the reuse of the confirmation data to 30 days.

>  
> You also seem to hint at another possible point of contention.  There appears to be a possible disagreement as to whether CAs have to follow a specific order of processing for certificate requests.  Notably, in https://cabforum.org/pipermail/public/2017-April/010539.html, Ryan described an possible order.  However some CAs have described a different order, wherein the customer initiates the request saying “we will be requesting a certificate for example.com”, then the CA validates the domain, then the customer submits the CSR and other required information necessary to complete the request.  The duration between the initial steps (through domain validation) and the latter steps can be considerable — possibly months apart.  This is what some have called domain “pre-validation”.  I think some have suggested that the BRs don’t allow this alternative order of operations, but I’m having a little trouble finding the specific cite.  Do you, Ryan, or does anyone else, think the order of operations described above is not valid?
> 
> I think we're in agreement that the Applicant must initiate the request in some form. I called that out in the previous message - that in some manner, a request must be generated.
> 
> 1.3.2 implies that a request includes the Subject name, and by proxy, the domain names. We can also conclude it includes additional data (e.g. see Section 3.2.3), and more explicitly spelled out by 4.1.2.
> 
> "The	certificate	request MUST contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct."
> 
> On the basis of this, I would suggest that a "We will be requesting a certificate for example.com" does not in and of itself constitute a certificate request. It may be that the request is _only_ for the binding of the domain, but I'm not sure that would be a valid request, under both 4.1.2 and 4.2.1. Now, assuming the request holds at least a domain and public key, arguably it meets the definition of 4.2.1, and all other factual information about the Applicant to be included (e.g. in the case of OV/EV) can be obtained out of band, consistent with 4.2.1
> 
> Does that help provide the cite? 

Yes, it does.  We know that CAs can generate keys on behalf of the subscriber, so it is clear that a public key is not required.  This means that a CA could take the request for “issue a certificate to example.com”, do validation and key generation, throw away the private key, issue the cert, and end up with a “pre-validated” domain.  This is compliant.  The generated cert could have some flag in it, similar to a pre-cert, that makes it unusable for any real world purpose, and it would still be fine.  But this is silly.  We don’t want to have hoop jumping for no discernible value.

Can you suggest a change that you feel would make it clear that CAs may validate identities (organizations, domains, etc) independent of issuing certificates and use the documents and data gathered during such validation for future issuance, subject to the aging requirement of 4.2.1?  I would suggest a change myself, but I’m not quite clear which part of the BRs you feel prevents this today.

Thanks,
Peter