[cabfpub] Pre-Ballot: Underscore Characters in SANs

[Ryan Sleevi]

You can only issue certificates for hostnames, so I'm not sure I understand
the question

On Thu, Jun 1, 2017 at 2:33 PM, Ben Wilson <ben.wilson at digicert.com> wrote:

> Does this position have something to do with SRV names vs. host names?
>
>
>
> Thanks,
>
>
>
> Ben
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Thursday, June 1, 2017 12:24 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Peter Bowen <pzb at amzn.com>; Ben Wilson <ben.wilson at digicert.com>
>
> *Subject:* Re: [cabfpub] Pre-Ballot: Underscore Characters in SANs
>
>
>
> Ben,
>
>
>
> I believe you're conflating host records with other forms of records.
>
>
>
> As TLS certificates only apply to host records, Peter's remarks are
> entirely appropriate and correct.
>
>
>
> As Chrome itself is working through security issues resulting from
> misapplication of the RFCs by underlying resolver libraries, I fully
> support a defense in depth approach that reflects CAs obligations and
> expectations to abide by the relative standards and wellformedness.
>
>
>
> On Thu, Jun 1, 2017 at 2:21 PM, Ben Wilson via Public <public at cabforum.org>
> wrote:
>
> Peter,
>
> Respectfully, I don't think we should be so specific as to where an
> underscore can appear in a SAN.
>
> For example, one post I found, https://stackoverflow.com/
> questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it,
> says "It is perfectly legal to have an underscore in a domain name. Let me
> quote the standard, RFC 2181, section 11, 'Name syntax':  The DNS itself
> places only one restriction on the particular labels that can be used to
> identify resource records. That one restriction relates to the length of
> the label and the full name. [...] Implementations of the DNS protocols
> must not place any restrictions on the labels that can be used. In
> particular, DNS servers must not refuse to serve a zone because it contains
> labels that might not be acceptable to some DNS client programs.  See also
> the original DNS specification, RFC 1034, section 3.5 'Preferred name
> syntax' but read it carefully.  Domains with underscores are very common in
> the wild. Check _jabber._tcp.gmail.com or _sip._udp.apnic.net."
>
> As you can see, these names start with an underscore, despite the fact
> that section 3.5 of RFC  1034 says, "The labels must follow the rules for
> ARPANET host names.  They must
> start with a letter, end with a letter or digit, and have as interior
> characters only letters, digits, and hyphen.  There are also some
> restrictions on the length."
>
> My point is, if the position of the underscore works, then let it work,
> and if it doesn't work, let the subscriber and the CA figure that out and
> reissue something that works.  We shouldn't be creating unnecessary
> proscriptions or format validation checks in this area.
>
> Ben
>
>
> -----Original Message-----
> From: Peter Bowen [mailto:pzb at amzn.com]
> Sent: Friday, May 26, 2017 10:12 AM
> To: CA/Browser Forum Public Discussion List <public at cabforum.org>
> Cc: Ben Wilson <ben.wilson at digicert.com>
> Subject: Re: [cabfpub] Pre-Ballot: Underscore Characters in SANs
>
> Ben,
>
> I would suggest a couple of changes:
>
> 1) Underscores should only be allowed where hyphens are allowed.  Notable
> hyphens and underscores cannot start or end a label.  I suggest `one or
> more underscore characters (“_”) may be present in the FQDN in positions
> permitted to contain a hyphen character`
>
> 2) I would suggest adding a definition of Wildcard Domain Name and then
> using it here.  `Wildcard Domain Name: A Domain Name formed by prepending
> "*." to a FQDN`
>
> Thanks,
> Peter
>
> > On May 25, 2017, at 1:08 PM, Ben Wilson via Public <public at cabforum.org>
> wrote:
> >
> > I’m looking for two endorsers for Ballot 202 – Underscore Characters
> > in SANS The current Baseline Requirements do not expressly allow
> underscore characters in Subject Alternative Names. This ballot seeks to
> clarify that one or more underscore characters (“_”) are allowed in FQDNs.
> It also cleans up some of the language in Section 7.1.4.2.1 of the Baseline
> Requirements.
> >
> > The following motion has been proposed by Ben Wilson of DigiCert and
> endorsed by - and - to introduce new Final Maintenance Guidelines for the
> "Baseline Requirements Certificate Policy for the Issuance and Management
> of Publicly-Trusted Certificates" (Baseline Requirements).
> >
> > --Motion Begins--
> >
> > REPLACE Section 7.1.4.2.1 of the Baseline Requirements in its entirety
> with:
> >
> > 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 or iPAddress name.
> >
> > For entries of the type dNSName, the entry MUST containing the
> Fully-Qualified Domain Name that the CA has validated in accordance with
> section 3.2.2.4. The FQDN must comply with RFC 5280, Section 4.2.1.6,
> including that the name be in “preferred name syntax,” with the following
> exceptions: a single wildcard character (“*”) MAY be present as the
> left-most, most subordinate level, if the CA has validated the name
> consistent with Section 3.2.2.6; and one or more underscore characters
> (“_”) may be present in the FQDN, 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 in accordance with Section 3.2.2.5. The entry
> MUST NOT contain a Reserved IP Address.
> >
> > --Motion Ends--
> >
> > Thanks,
> >
> > Ben
> >
> > From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ben
> > Wilson via Public
> > Sent: Thursday, April 20, 2017 12:09 PM
> > To: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Public
> > Discussion List <public at cabforum.org>
> > Cc: Ben Wilson <ben.wilson at digicert.com>
> > Subject: Re: [cabfpub] Pre-Ballot: Underscore Characters in SANs
> >
> > Thanks.  I’ll rework this with the language suggested and re-circulate.
> > Ben
> >
> > From: Ryan Sleevi [mailto:sleevi at google.com]
> > Sent: Thursday, April 20, 2017 11:36 AM
> > To: CA/Browser Forum Public Discussion List <public at cabforum.org>
> > Cc: Ben Wilson <ben.wilson at digicert.com>
> > Subject: Re: [cabfpub] Pre-Ballot: Underscore Characters in SANs
> >
> >
> >
> > 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.
> >
> > <Underscore Characters in
> > SANs.pdf>_______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170601/9bab5e3e/attachment-0001.html>