[cabfpub] Preballot - Revised Ballot 190

Peter Bowen pzb at amzn.com
Fri May 19 07:27:18 MST 2017


> On May 19, 2017, at 5:12 AM, Ryan Sleevi via Public <public at cabforum.org> wrote:
> 
> On Fri, May 19, 2017 at 2:00 AM, Kirk Hall via Public <public at cabforum.org> wrote:
>  
> > However, in our current discussion of Ballot 190, no such strong evidentiary showing has ever been made by anyone, and so Ballot 190 clarifies that the long-standing rule permitting reuse of proper validation data under 
> > BR 4.2.1 and EVGL 11.14.3 continues in place.
> 
> That is, there's the reuse of data and documents - 4.2.1 - and there's the reuse of domain validation - 3.2.2.4. Peter rightfully pointed out the arguments with 3.2.2.4 allowing this reuse, but you agreed by citing 4.2.1.
> 
> I do not think there is a reasonable argument for suggesting that the domain validation process itself constitutes data or documents - that part clearly contradicts with the language in 3.2. I think Peter's summary of the debate around 3.2.2.4 is reasonable and accurate, but it's entirely separate from 'reuse of proper validation data' - because, very clearly, when you're using one of these legacy methods, you are _not_ reusing previous data to verify the current request (4.2.1) - you're using a previous validation to skip domain validation entirely (3.2.2.4).

Ryan,

I think you highlight another point of contention.  Section 4.2.1 of the current BRs says " The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 3.2 no more than thirty‐nine (39) months prior to issuing the Certificate.”  This text has not changed since at least version 1.1 of the BRs with the exception of changing the section references when we moved the BRs to use the RFC 3647 outline.

The contention, from my view, is the definition of “data or document”.  I think that all agree that a "utility bill, bank statement, credit card statement” provided by the customer in order for address verification is clearly a document and falls within the scope of this requirement.  I also think all agree that data obtained from Companies House in the UK or the Division of Corporations of the State of Delaware about the existence of a company is clearly data that falls within the scope of this requirement.  What is less clear or contentious is data obtained as a result of the validation process.  For example, there is contention as to whether the data recorded by the CA that states that customer X controls p.com and example.aws is within the scope of the requirement.  Additionally there is contention as to whether intermediate data is within the scope, such as data that shows that a Random Value was emailed to hostmaster at example.com on 2017-02-24 at 15:52 UTC and the CA received a confirming response using the Random Value on 2017-02-24 at 17:14 UTC.

From reading emails, it seems that one view is that data that records the completion of the validation process is within scope for 4.2.1.  Another view is that only data used as input to a validation process is within scope for 4.2.1.  And a third view is that data that is obtained during a validation process is within scope for 4.2.1 but the output is not.

Additionally I have seen some contention about the meaning of "The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation” as found in ballot 169.  As one of he authors of this language, I intended it to mean that the confirming response must have been received within 30 days of creation of the random value, but that the response itself could be reused as per 4.2.1.  That is a CA could send a random value to the domain registrant on 2017-03-01 and received the confirming response on 2017-03-05 and then use that to issue a certificate for the domain on 2017-12-29.  However I think I’ve heard someone suggest that the 30 days is how long you can reuse the confirming response which would mean it could not be used to issue on 2017-12-29.  This is probably another place where it would be helpful to make super clear the expectation.

Thanks,
Peter


More information about the Public mailing list