[cabfpub] Ballot 190

[Kirk Hall]

One other comment.  Remember that for the last few months, new Methods 1-4 and 7-10 were actually included under Method 11 “any other method” after Ballot 181’s effective date, and that situation will continue until the effective date of Ballot 190.  Also, the same is true for any validations that followed old Method 7 “any other method” prior to the effective date of Ballot 169.  So be very careful in saying anything in Ballot 190 that would invalidate validations done prior to Ballot 190 under “any other method” so long as they complied with any of Methods 1-10 of the new methods or Methods 1-6 of the old methods.

I would be open to saying that any prior vetting done under old Method 7 or more recent Method 11 “any other method” must be revalidated upon the effective date of Ballot 190 IF they did not follow EITHER Methods 1-6 (as the existed before Ballot 169) or Methods 1-10 (as put forward in Ballot 169).  In other words, the ONLY validations that have to be redone before the expiration of the re-use period are validations that were done that did not comply with either old Methods 1-6 or new Methods 1-10.  That should flush out any unknown and unsecure validations that occurred in the past.

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer via Public
Sent: Thursday, April 27, 2017 8:53 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>; Ryan Sleevi <sleevi at google.com>
Cc: Wayne Thayer <wthayer at godaddy.com>
Subject: [EXTERNAL]Re: [cabfpub] Ballot 190

Jeremy,

>>If there are still concerns, should we drop the reuse language altogether?

I would support this ballot regardless of what explicit reuse language is included, but I would like to see some explicit statement on reuse included, even if the statement is “you can’t reuse data/documents from non-compliant methods”.

Given the desire to remove “any other method” from the BRs ASAP, I think either of the compromises you proposed is preferable to a delayed effective date for the entire ballot, which is what I suspect would be required to gain consensus if the reuse language was dropped.

Thanks,

Wayne
From: Public <public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>> on behalf of Jeremy Rowley via Public <public at cabforum.org<mailto:public at cabforum.org>>
Reply-To: CA/Browser Forum Public Discussion List <public at cabforum.org<mailto:public at cabforum.org>>
Date: Thursday, April 27, 2017 at 3:35 PM
To: Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>>, CA/Browser Forum Public Discussion List <public at cabforum.org<mailto:public at cabforum.org>>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>
Subject: Re: [cabfpub] Ballot 190

Sorry – that was pretty confusing.  I revised the questions in way that I think answers most of your question:

  1.  If we include the validation WG proposed language in Section 3.2.2.4, does that adequately address the concerns with the previous version of ballot 190?
  2.  If there are still concerns, should we drop the reuse language altogether? Note that this will require revalidation of all information prior to issuance of new certificates if the original validation was not in accordance with one of these ten sections.
  3.  If we add the language to Section 3.2.2.4, would you vote against the ballot because of the document reuse?
  4.  If the reuse language proposed was dropped altogether and re-validation became required, would you vote against the ballot?
  5.  If you’d vote against the ballot, is there some middle ground that we can reach? For example, could we say that all previous validation information not complaint with the 10 methods must expire 13 months from the date of the ballot? Alternatively, everything under section 7 expires immediately while documents affected by a modification to 1-6 will remain valid for 825 days? Other proposals.
Basically, we’re at an impasse on the ballot, and I’m not sure which way the vote would go.

A couple of comments:

“I think the general language proposal is a bit awkward - I would rather see it pegged to an explicit minimum version (for example, BRs 1.4.1) and explicitly forbid using a previous "any other method" validation. Is that problematic?”

This seems reasonable to me, but I’ll let others chime in.

“I think if we're still unable to agree on a timeline such as that - requiring revalidation consistent with the current-3.2.2.4 for anything that was validated under a previous-3.2.2.4 that is no longer permitted - my only other suggestion would be to require an explicit expression within the certificate that it complies with the current version of 3.2.2.4 at the time of issuance. This would help give Relying Parties the necessary assurances that the CA is committed to security.”

This seems reasonable to me as well.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170428/5a6fc7a0/attachment-0003.html>