[cabf_validation] Ballot 190 Section 2

Kirk Hall Kirk.Hall at entrustdatacard.com
Mon Apr 24 12:14:41 MST 2017


Can you explain your last sentence - not clear to me.  What BR and EVGL section(s) are you referring to?

From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
Sent: Monday, April 24, 2017 12:04 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Cc: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Subject: RE: Ballot 190 Section 2

That is my understanding of Google’s position. However, he wasn’t wrong that the proposed language would permit unlimited reuse for longer lived certificates.

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Kirk Hall via Validation
Sent: Monday, April 24, 2017 12:57 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: Re: [cabf_validation] Ballot 190 Section 2

If I understand correctly, Google wants all domain validation data that was based on prior validation methods 1-7 (even if properly executed) to be discarded, even if the resulting validation data is still within the permitted data reuse period, if the domain validation was based on any validation procedure that was changed by Ballot 169 (now, Ballot 190).
All such domains would have to be re-validated immediately using the changed methods as specified in Ballot 190.
Mozilla pointed out on the last Forum call that taking this position (and not allowing prior domain validation data to be reused according to our reuse of data rules until the data expires) will be a big disincentive for CAs to ever vote for incremental changes to validation methods - if it means that CAs are suddenly required to revalidate thousands of domains all at once (even domains that were properly validated under old rules the day before the new rules take effect), CAs won’t want to vote for that unless there is a showing of a some serious and widespread security issue affecting the prior validations.
I think the new rules of Ballot 190 should only apply to new domain validations that occur after Ballot 190 is approved and becomes effective.  The only argument I heard about past deficiencies in validation related to (new and improved) BR 3.2.2.4.6- Agreed-Upon Change to Website (i.e., there was an argument that some past validations were not correct in some way) - but I don’t think we received any details, examples, or numbers.  Old method 6 stated “Having the Applicant demonstrate practical control over the FQDN by making an agreed‐upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN.”  We are not aware of any problems for past validations we have done using this method.
One problem with discarding all or most prior domain validation data is - we have no automated way of knowing which domains were validated using particular methods - so if Ballot 190 says (for example) that  domains verified using the prior Agreed Change to Website method have to be revalidated (but no other methods), we would have to manually review ALL our past domain validations to find which were done using this method - again, a major task, and not something we want to do unless there is evidence presented that these past domain validations have lots of serious problems.
That’s why Section 2 was included in Ballot 190 - to make these changed to domain validations apply only to new validations occurring after the ballot effective date.  I think that is how we have handled incremental changes to validation methods in the past, and I still think that’s the best approach.
From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Doug Beattie via Validation
Sent: Monday, April 24, 2017 11:35 AM
To: CA/Browser Forum Validation WG List <validation at cabforum.org<mailto:validation at cabforum.org>>
Cc: Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>
Subject: [EXTERNAL]Re: [cabf_validation] Ballot 190 Section 2


The “any other method”  still remains as a valid option and the problem outlined below is only when this method is removed, correct?  We basically need to grandfather in validation data collected under method 11 for some period of time.  Ryan does not want this to be 39 months for all the reasons he listed.
Is that the crux of the issue?
Doug


From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Jeremy Rowley via Validation
Sent: Monday, April 24, 2017 1:37 PM
To: CA/Browser Forum Validation WG List <validation at cabforum.org<mailto:validation at cabforum.org>>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>
Subject: [cabf_validation] Ballot 190 Section 2

Section 190 was withdrawn because of objections to Section 2 of the ballot:
“This provisions of Ballot Section 1 will apply only to the validation of domain names occurring after this Ballot 190’s effective date.  Validation of domain names that occurs before this Ballot’s effective date and the resulting validation data may continue to be used for the periods specified in BR 4.2.1 and EVGL 11.14.3 so long as the validations were conducted in compliance with the BR Section 3.2.2.4 validation methods in effect at the time of each validation.”
Basically, the browsers would like a date when this cuts off so that old certificate validation data can’t be reused. Any thoughts on how to reconcile?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20170424/1520cbbb/attachment.html>


More information about the Validation mailing list