[cabfpub] Ballot 190 v7

Ryan Sleevi sleevi at google.com
Wed Aug 30 07:49:49 MST 2017


On Tue, Aug 29, 2017 at 8:03 PM, Kirk Hall via Public <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?


>
>
> 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?


> 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 :)

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

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.

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/d5f53ab1/attachment.html>


More information about the Public mailing list