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

Thu Jun 1 22:55:52 MST 2017

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. ***”

-----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>
Cc: Kirk Hall <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/e3570e45/attachment-0001.html>