[cabfpub] Pre-Ballot: Underscore Characters in SANs

[Ryan Sleevi]

On Thu, Apr 20, 2017 at 1:07 PM, Ben Wilson via Public <public at cabforum.org>
wrote:

> All,
>
>
>
> I’m looking for two endorsers for a proposed amendment to section
> 7.1.4.2.1 of the Baseline Requirements--to be modified to allow the
> underscore character (“_”) in SANs and to remove the sunset language in
> that section related to internal names and reserved IP addresses.  The
> revised section 7.1.4.2.1 would read as follows:
>
>
>
> 7.1.4.2.1.             Subject Alternative Name Extension
>
> Certificate Field: extensions:subjectAltName
>
> Required/Optional:  Required
>
> Contents:  This extension MUST contain at least one entry.  Each entry
> MUST be either a dNSName containing the Fully-Qualified Domain Name or an
> iPAddress containing the IP address of a server.  The CA MUST confirm that
> the Applicant controls the Fully-Qualified Domain Name or IP address or has
> been granted the right to use it by the Domain Name Registrant or IP
> address assignee, as appropriate.
>
> Wildcard FQDNs and underscores in FQDNs (encoded as IA5 strings) are
> permitted.
>
> CAs SHALL NOT issue a certificate with a subjectAlternativeName extension
> or Subject commonName field containing a Reserved IP Address or Internal
> Name.
>

Ben,

Some suggested edits that may help resolve any future ambiguities,
capturing the discussions from the Raleigh F2F.

"""
7.1.4.2.1 Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Required/Optional: Required
Contents: This extension MUST contain at least one entry. The entry MUST be
either a dNSName or iPAddress name.

For entries of the type dNSName, the entry MUST contain the Fully-Qualified
Domain Name that CA has validated the Applicant's control or ownership of.
The Fully-Qualified Domain Name must comply with RFC 5280, Section 4.2.1.6,
including that of requiring the name be in the "preferred name syntax,"
with the following exceptions: A single wildcard ('*') character may be
present as the left-most, most subordinate label, if the CA has validated
the name consistent with Section 3.2.2.6. One or more underscore ('_')
characters may be present within the Fully-Qualified Domain Name, in
deviation from the "preferred name syntax." The entry MUST NOT contain an
Internal Name.

For entries of the type iPAddress, the entry MUST contain an IP address
that the CA has validated the Applicant's control of. The entry MUST NOT
contain a Reserved IP Address.
"""

Here's a bit of explanation for the edits and why I made them:
- Split the rules regarding dNSName and iPAddress into two separate
sections, to make it unambiguous the contents they can contain
- Clarify that wildcards and underscores are NOT permitted for the type
iPAddress
- Clarify that domain names MUST follow the rules of RFC 5280, particularly
that of preferred name syntax. This includes the prohibition of the " "
label or that of e-mail addresses in the domain form (both examples given
in RFC 5280). It clarifies that the exceptions to this rule are limited to
the presence of wildcard characters and underscores.
  * There's one issue which I debated trying to tackle in this, which is
that it's possible for an applicant to register the literal "*.domain.com"
(e.g. the actual wildcard character). The current and proposed wording fail
to address this in 3.2.2.6, even though the intent is clearly that in the
case of a *, the CA MUST validate the Applicant's control of the Domain
Namespace indicated by removing the '*' label.
  * Happy to suggest wording if it's clear the concern here
- Reuse the language from 3.2.2.4 and 3.2.2.5, specifically the
"Applicant's control or ownership of" a domain name and "control of" an IP
address.
  - The existing wording, "granted the right to use", is ambiguous, because
no process is defined within the BRs as to how an Applicant can demonstrate
such a grant, or how the CA can verify such a grant.
  - I believe the intent is with respect to reusing the validation methods
of 3.2.2.4, but if CAs feel that this is an intentional loophole to permit
some activity that would otherwise be prohibited or underspecified, I'm
happy to see what we can figure out
- Lays out a framework for permitting additional name types in the future,
as discussed. This section could be tightened up further to support that
future growth, but I tried to keep it mostly minimal for now, so that we
could incrementally improve.

Do let me know what you think of those edits, and whether they bring the
necessary clarity of intent and execution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170420/6b3e85c7/attachment-0003.html>