[cabfpub] [EXTERNAL]Re: Ballot 190 v7

Doug Beattie doug.beattie at globalsign.com
Wed Aug 30 11:26:39 MST 2017



From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Kirk Hall via Public
Sent: Wednesday, August 30, 2017 10:54 AM
To: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 190 v7

These came from Doug, and as I recall were previously posted to the public list before we stopped working on Ballot 190.  I’ll let Doug respond.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Wednesday, August 30, 2017 7:50 AM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: [EXTERNAL]Re: [cabfpub] Ballot 190 v7



On Tue, Aug 29, 2017 at 8:03 PM, Kirk Hall via Public <public at cabforum.org<mailto:public at cabforum.org>> wrote:
Mads and Doug are still endorsers for the restart of Ballot 190.  Doug reminded me of five changes that we had agreed to make to the last version, v7.  The changes are shown on the attached v7 in yellow, and are also listed below.  When we do the restart on Ballot 190, it will be with this v7 version.

Can you indicate where those v7 changes came from? That is, was this private discussions among the Ballot endorsers, suggestions you made, items from the Validation WG (call or list?), etc?


Yes, Validation WG discussions

Here are the changes from v6 that were made in the attached v7:

1. [In BR 3.2.2.4 introduction]: The CA SHALL confirm that, as of the date the Certificate issues,  <is issued?>

"is issued" would be past-tense, implying it's a post-issuance activity, rather than a (pre-)issuance activity - right?
  Then, perhaps this:
The CA SHALL confirm that prior to issuance as of the date the Certificate issues, either the CA or a Delegated Third Party has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate using at least one of the methods listed below.

2. [In all 10 validation method Notes:] 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 the same or more labels than it.  This method is suitable for validating Wildcard Domain Names.

-          The above note appears in multiple places, all need to be updated.
It reads fairly clunky - more was clearer as a numeric comparison, but 'the same or more labels than it' leaves ambiguity as to whether it's equality of the labels (which is handled by the preceding clause).

Beyond the longstanding concerns about expressing the "Notes" here and their impact on normative expressions, I'm not sure the change is actually necessary - that is, the only FQDN that 'ends with all the labels of the validated FQDN and has the same number of labels in it' is, well, the FQDN. Is that actually necessary to express - you're saying that after the FQDN has been validated, Certificates may also be issued for the FQDN.

The current wording avoids this issue, because 'the current FQDN' will never have more labels in it than the current FQDN :)

The point I was trying to make was that the requested FQDN may be identical to the Validated FQDN, so that it will not have MORE labels, they will be identical labels.  The final “it” is not clear

Let’s change this:
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 the same or more labels than it



3. [In BR 3.2.2.4.6]: The presence of Required Website Content contained in the content of a file or on a web page in the form of a meta tag. <we agreed that a web page is a file, so no need>

4. [In BR 3.2.2.4.6]: Missing “T”: “This method is suitable for validating Wildcard Domain Names.”

5. [In BR 3.2.2.4.7]: I’ve commented on this multiple times and I think as written it’s not clear:
From this:
Confirming the Applicant’s control over the FQDN by confirming the presence of a Random Value or Request Token in a DNS CNAME, TXT or CAA record for an Authorization Domain Name or an Authorization Domain Name that is prefixed with a label that begins with an underscore character.
To this:
Confirming the Applicant’s control over the FQDN by confirming the presence of a Random Value or Request Token in either 1) a DNS CNAME, TXT or CAA record for an Authorization Domain Name or 2) an Authorization Domain Name that is prefixed with a label that begins with an underscore character.


Kirk,

Could you highlight where you’ve commented on 3.2.2.4.7 in the past? I want to make sure I better understand your concerns here.
This was me making comments to the other ballot authors.

I highlight this because the choice of where to place your either/or is significant. You've placed 1) before the "CNAME, TXT, or CAA record" - which means that 2) can be expressed in any way (for example, an MX record would be sufficient, it would seem). That certainly doesn't sound correct, but I want to make sure I'm understanding your concerns.

The alternative way to express this would be reworded as:

or Request Token in a DNS CNAME, TXT, or CAA record for either:
   1) an Authorization Domain Name; or,
   2) an Authorization Domain Name that is prefixed with a label that begins with an underscore character.
You’re totally right, that is where I meant to put this.  There are just too many “or” statements in that requirement to understand it, thus the need to split it out.  I agree with your wording.

In this case, we make it clear that the Request Token or Random Value still must appear within those record types.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170830/c58e331c/attachment-0001.html>


More information about the Public mailing list