[cabf_validation] New draft Ballot 190 dated June 1, 2017

[Kirk Hall]

Thanks for the explanation, Peter.  I think you cover two main points.

1.  At some point, we will need to change references to “WHOIS” to “RDAP” (or maybe change the reference from “WHOIS” to “WHOIS or RDAP” to cover both systems for a while, including a period when a prior validation lookup in WHOIS can be reused even though new lookups are now done in RDAP).

Ballot 190’s main goal is to re-insert the remaining 7 validation methods from Ballot 169 back into the BRs, so I’d suggest this topic would be best reserved for a follow-on ballot, when we can take the time to think it through.  We will need to make multiple changes in the BRs, not just in BR 3.2.2.4.

2.  You also mention possible changes to the introduction to BR 3.2.2.4 to deal with certain validation methods like Method 8, where validation can only be used for the exact Authorization Domain Name that is verified.  Don’t we  have that covered pretty well right now for Method 8?  It can only be used for the exact FQDN that is validated, and is prohibited for wildcards.
3.2.2.4.8  IP Address
Confirming the Applicant's control over the requested FQDN by confirming that the Applicant controls an IP address returned from a DNS lookup for A or AAAA records for the FQDN in accordance with section 3.2.2.5.

Note: This method is NOT suitable for validating Wildcard FQDNs.

So I’d say let’s keep these ideas and discuss them in a new ballot after we get the Ballot 169 methods back in the BRs.

From: Peter Bowen [mailto:pzb at amzn.com]
Sent: Friday, June 2, 2017 9:01 AM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [EXTERNAL]Re: [cabf_validation] New draft Ballot 190 dated June 1, 2017


On Jun 1, 2017, at 10:55 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>> wrote:

Peter - I'm puzzled.  What does your sentence mean?  What problem is it addressing?

“Additionally, CAs may use any of the domain validation methods allowed in the version of these Requirements in effect at the time the validation data was collected to validate new certificate issuances as long as this section allows reuse of the validation data.”

Yes, of course CAs may choose to revalidate domains using a new method after it is adopted, if they choose.  Why do you think we need to say that in Section 4.2.1, which is about reuse of previously collected validation data?  BR 4.2.1 is already permissive (“MAY”), not mandatory, so I would not favor adding the sentence you propose unless it is addressing some problem I’m not aware of.

Sec.4.2.1 Performing Identification and Authentication Functions
*** Section 6.3.2 limits the validity period of Subscriber Certificates. 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 [825 days] prior to issuing the Certificate. ***”

Kirk,

As I understand it you want to be able to issue a new certificate by validating the FQDN in the certificate using data collected a year (or longer) ago and a validation method from a prior version of the BRs.  As a clear example, consider the following:

You have a customer request a certificate for images.example.com<http://images.example.com>.  Six months prior, you followed the BRs in effect at the time and used a method which sending an email with a random value to an email address, getting a response using the random value, and ensuring that the email address is one of the example.com<http://example.com> registrant, technical contact for example.com<http://example.com> or administrative contact for example.com<http://example.com> based on information provided via WHOIS.  You want to be able to say “no need to send a new email”.

Now imagine that .com rolls out their spiffy new WHOIS replacement called RDAP.  You may recall that ICANN presented this to the CAB Forum about a year ago at a F2F.  Because of this change by .com, the BRs are updated to say “listed in RDAP for the Base Domain” rather than “listed in the WHOIS record for the Base Domain”.  This would mean that the data collected from a whois server is still able to be used but there is no method to which it can be applied.  So the CA would have to consult RDAP to get the contacts, then check that the email confirmation matches one of the current contacts.  While this seems good to me, it is my understanding that your intent is that validation based on WHOIS would be allowed until the data expires.  The only way to make this work is to allow reuse of the _methods_ in addition to the data.

I hope that helps explain the additional sentence.

Looking at the BRs, you could also address this by adding a method to 3.2.2.4 that is something like “Confirming the Applicant's control over the FQDN by verifying the CA has a completed verification of Applicant authority for an Authorization Domain Name that was completed using a method that was acceptable when the verification was completed.”  Note that refinement is needed to ensure verifications completed per 3.2.2.4.8 cannot be used as verification for an Authorization Domain Name unless the Authorization Domain Name is the name being verified.

Thanks,
Peter


-----Original Message-----
From: Peter Bowen [mailto:pzb at amzn.com]
Sent: Thursday, June 1, 2017 5:55 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org<mailto:validation at cabforum.org>>
Cc: Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>>
Subject: [EXTERNAL]Re: [cabf_validation] New draft Ballot 190 dated June 1, 2017

Kirk,

Looking at your changes in 4.2.1, I don’t think they match what you verbally said on the call today was your goal.  Specifically they do not say that validations completed under prior versions of the BRs are acceptable.    To be clear, I don’t support allowing reuse of completed validations that would not be acceptable under the revised methods, but I think it is important that the proposal is unambiguous.

I have mostly heard concern over the change to the requirements around demonstration of control via file (3.2.2.4.6 in this ballot).  I looked back and this method has been unmodified for more than year (https://cabforum.org/pipermail/public/2016-April/007459.html).  I also appears that DNS based validation (3.2.2.4.8) has not had changes in the last year.  This would seem to be plenty of notice for CAs to get their systems updated and determine which domains will need new validations.

That being said, I suggest adding a sentence to the proposal to avoid any ambiguity.  The revised change to 4.2.1 I propose is:

"After the change to any validation method specified in the Baseline Requirements or EV Guidelines, a CA may continue to reuse validation data collected prior to the change for the period stated in this BR 4.2.1 unless otherwise specifically provided in the ballot that makes the change to the validation method.  Additionally, CAs may use any of the domain validation methods allowed in the version of these Requirements in effect at the time the validation data was collected to validate new certificate issuances as long as this section allows reuse of the validation data.”

This harmonizes both interpretations on the definition of “validation data”: both those who interpret “validation data” as only include inputs to validation methods and those who interpret “validation data” as also include outputs of validation methods.

Thanks,
Peter

> On Jun 1, 2017, at 4:34 PM, Kirk Hall via Validation <validation at cabforum.org<mailto:validation at cabforum.org>> wrote:
>
> OK, I spent some time reviewing lots of prior drafts, including Jeremy’s recent draft with its additional provisions as we discussed on the call today (which I had not taken the time to read before).  A few comments:
>
> 1. Jeremy, your draft has lots of interesting ideas, but it also proposes language that I don’t think has been broadly accepted by the Forum members (and to which we would object).  Some of these ideas are big changes, and will take a lot of time to discuss and act on.  So I didn’t use your draft in the attached documents, and suggest you revisit your proposals and bring them up for further discussion (if needed) AFTER some form of Ballot 190 passes.  Ballot 190 is chiefly intended to put back in the remaining seven methods of Ballot 169 and remove “any other method” forever.
>
> Incidentally, please look at the new language I added to BR 4.2.1 to clarify the existing rule on data reuse – I think this will eliminate the need for some of your suggested changes.  In the future, if a new ballot changes a new validation method, and the Forum believes the change is so important that all domains vetted using the old method must be revetted, we can add that specific requirement in the same ballot (e.g., “all domains previously vetted using the old method #X must be revetted within [120] days”, or whatever – but the general case would remain clear validation data can be reused under 4.2.1 for new certificates in all other cases, even after validation methods are changed.
>
> Because we did not include your most recent changes, I have changed the Proposer in this draft from you (Jeremy) to Chris Bailey.  However, we would very much like DigiCert’s endorsement.
>
> 2.  Remember that BR 3.2.2.4 now exists as passed under Ballot 181.  To make review and a final Ballot 190 easier to understand, I created the attached document “Ballot 190 (6-1-2017) showing changes from Ballot 181” in track changes mode.  That’s how we should present a ballot of this complexity.  Most of the changes you see involve re-inserting Methods 1-4 and 7-9 as they existed in Ballot 169.  However, several people have suggested minor changes or corrections to Ballot 169, which I have noted in comments and with highlighting.
>
> Ballot 190 has been slowed down by discussion and different interpretations of BR 4.2.1.  Gerv has indicated that in the future he wants the ability to require revetting of domains in some cases (i.e., forbid reuse of prior validation data) on a method-by-method basis if validation methods are amended.  However, that does not apply to any of the ten methods in Ballot 190, so the best practice is to restate the general rule in BR 4.2.1 that we have always followed in the past (no revalidation required when methods are amended).  You can see the change in this draft.
>
> 3.  Finally, to make it easier for people to review and analyze this Ballot 190 draft if it is passed in the form attached (the draft is dated June 1, 2017), I also attach a document “Ballot 190 (6-1-2017) if adopted”, which accepts all changes in the track changes draft.
>
> Let’s review by email in the VWG for a few days.  At that point, we can put on the Public list as a pre-ballot.
> <Ballot 190 (6-1-2017) showing changes from Ballot 181.docx><Ballot 190 (6-1-2017) showing changes from Ballot 181.pdf><Ballot 190 (6-1-2017) if adopted.docx><Ballot 190 (6-1-2017) if adopted.pdf>_______________________________________________
> Validation mailing list
> Validation at cabforum.org<mailto:Validation at cabforum.org>
> https://cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20170602/23c846e7/attachment-0001.html>