[cabfpub] Preballot - Revised Ballot 190

[Ryan Sleevi]

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)


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


> I do want to stress the flexibility and openness to consider
> interpretations so that we harmoniously align, despite the deep concerns
> about the security implications and the practices of some CAs, provided
> that we find an appropriate route to transparently quantify and assess the
> certificates, so that it is possible for relying parties to distinguish
> these issues.
>
>
> I think our objective should be to get to a common understanding for all.
> The BRs have historically been a consensus document, setting the minimum
> requirements.  CAs are welcome to go above and beyond.  Where there is
> contention, we should clarify, but the focus should not necessarily be on
> raising the security bar, rather we should document where we are first,
> then discuss raising it.
>

Indeed. But we certainly should provide proactive ways for CAs to assert
conformance to a higher level, much as we allow CAs to attest a more rigid
validation with respect to EV certificates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170519/6496af4b/attachment-0003.html>