[cabfpub] Updated Ballot 190 v5 dated July 6, 2017

Kirk Hall Kirk.Hall at entrustdatacard.com
Thu Jul 6 16:25:22 MST 2017

We have had this same conversation several times now, and yet keep coming back to the same points.

As I and others have said, including on today's call, without the Note there is uncertainty as to whether there is specific authorization for CAs who have validated a domain ("example.com") using Methods 1-7 and 9-10 to then issue certs to the same customer for domains that include additional nodes to the left (www.example.com, mail.example.com) based on the prior validation of example.com.  I think some have even questioned whether or not CAs can do this (a common practice today among CAs and their customers) in the various email strings we have had over the past few months. That's the only reason we have felt the need to add specific provisions like the Note to what was in Ballot 169 - these questions were raised, and the interpretations were offered on existing language.

Some CAs in the past relied on Method 7 "any other method" as authority to issue for an FQDN that was a validated FQDN plus nodes to the left.  The terms Authorization Domain Name and Base Domain may be a good way to go in the future, but they are only found in a few of the ten validation methods - maybe they should be added to the other methods by the Validation Working Group in the follow-up ballot to come, but we can't rely on those terms today.  

If you look at the discussion of the past two weeks alone, we have had multiple formulations of the best language to explicitly allow CAs to do this, and finally I picked the most recent one - Gerv's - because it seemed to be well stated and do what we all want to do.

While you indicated on the call today that the Note at the end of each validation method could introduce uncertainty and also IP risk, you did not elaborate or provide details.  I don't agree with you, but if you have additional details and examples to support your conclusions I'll be happy to review them.  Even better, if you want to draft replacement language that accomplishes what we are trying to accomplish, please do and we can take a look.

For all these reasons (as we have discussed before), we will keep the Note in the Ballot 190 as shown in v5, but if you want to draft an immediate follow-on ballot that addresses your concerns, we can take that up immediately after Ballot 190 passes.  The most important thing now is to try to get this ballot enacted, get the new validation methods in the BRs, and eliminate "any other method" for user security.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Thursday, July 6, 2017 12:29 PM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: [EXTERNAL]Re: [cabfpub] Updated Ballot 190 v5 dated July 6, 2017


Just because it's important to capture for those who were not on the call - since it's likely this ballot will proceed to voting before such minutes are available, a few thoughts from the call to be

1) At least one member highlighted the concern that, by making modifications to this ballot, as proposed, this introduces additional IP risk that the Forum was specifically trying to address with Bylaws 1.6. The best path to address this risk is to remove the "Note"

2) At least one member highlighted that the Validation WG, with the proposal of Ballot 169, spent considerable time trying to address the ambiguity problem that the "Note" is trying to address (but does so incompletely).

3) At least one member highlighted that the "Note", by being non-normative, is neither urgent nor essential to resolve in this version. However, by introducing the currently proposed language, it creates potential issues that there is no guarantee will be able to be resolved easily or in a timely fashion. As the Forum already has methods to address ambiguity - both through the questions@ list and through subsequent ballots - it seems far more appropriate to remove the proposed text, thus aligning with Ballot 169, and thus resolving a significant objection towards forwards progress.

I do not understand, nor agree with, the proposal to force a vote on this, when concerns have been repeatedly raised, and which are trivial to address in a way that allows us to make forward progress on the far more substantive aspect.

Further, I have not seen any attempt to address and/or resolve the concerns highlighted in https://cabforum.org/pipermail/public/2017-July/011492.html

As the ballot proposer, can you please make an effort to address and/or respond to these concerns, which introduce substantially new risk and confusion? I have hopefully provided clear suggestions about ways to resolve, and it's unclear whether your lack of acknowledgement represents a need for additional time to review (in which case, we should stop the discussion period), a disagreement on principle (in which case, I hope you can clearly state so), or if my concerns are unclear (in which case, we should stop the discussion period, and I'm more than happy to work with you to explain them).

I understand and appreciate your eagerness to see this through to conclusion, but believe it at least deserves some response and engagement on the substance of these real and pressing security concerns, rather than dismissing them as fixing them after. After all, it is worth noting that it has taken us nearly a year to get to this point in which we're somewhat close to a ballot, so you can understand why I am quite troubled by the suggestion that we can somehow quickly fix these real security issues after-the-fact.

On Thu, Jul 6, 2017 at 2:39 PM, Kirk Hall via Public <public at cabforum.org> wrote:
> Based on the CABF teleconference discussion today, it’s clear there is 
> still a difference of opinion on the best way to express the ability 
> of a CA to re-use the validation of an FQDN and issue certs for other 
> FQDNs that include additional nodes to the left (except for validation Method 8).
> Jeremy and Ben are collecting all the suggestions for how to express 
> this, and once Ballot 190 is adopted will immediately consider appropriate edits.
> But we need to get Ballot 190 done in order to end the “any other method”
> authorization and meet Mozilla deadlines as well.
> For now, we have this formulation of the rule posted by Gerv last 
> Friday, which looks good to me:
> “Note: Once the FQDN has been validated using this method, the CA MAY 
> also issue Certificates for other FQDNs that end with all the labels 
> of the validated FQDN and have more labels than it.”
> I have dropped in that language in the attached Version 5 of Ballot 
> 190 (and specified this is not true for Method 8).  Otherwise, the 
> ballot is the same as v4 which was previously circulated.
> Ballot 190 v5 (6-30-2017) is now the official Ballot 190 under 
> consideration by the Forum.  The discussion period ends on July 8 at 
> 18:00 UTC, after which voting will start.
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

More information about the Public mailing list