[cabfpub] Pre-Ballot: Underscore Characters in SANs

Thu Jun 1 19:14:16 UTC 2017

In order for otherName:srvNames to be permitted? Yeah. Peter had a draft
ballot for that, and Jeremy continued that draft. Our (Google's) problem
had been that it was coupled to this ballot, when they're really separate
things.

We (Google) are super-excited for SRVNames - it'll actually be a good step
forward for the Web PKI - but think it should be disconnected from this
correctness ballot - which is about loosening the requirements of RFC5280,
like we did for nameConstraints, because CAs have not been widely adhering
to the BRs and RFC5280 and we're going to retroactively grant indulgences :)

On Thu, Jun 1, 2017 at 3:11 PM, Ben Wilson via Public <public at cabforum.org>
wrote:

> So, in order for this to happen, another ballot would subsequently be
> required that specifies the contents and validation for service names,
> correct?
>
>
>
> *From:* Peter Bowen [mailto:pzb at amzn.com]
> *Sent:* Thursday, June 1, 2017 12:54 PM
> *To:* Ben Wilson <ben.wilson at digicert.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] Pre-Ballot: Underscore Characters in SANs
>
>
>
> The _*jabber.*_tcp.gmail.com form is a service name.  This would be
> represented in certificates using the c where the content would be _
> jabber.gmail.com (the protocol, such as _tcp isn’t included in the
> certificate). Anything starting with underscore isn’t a hostname and can’t
> go in a dNSName.
>
>
>
>
>
> On Jun 1, 2017, at 11:21 AM, Ben Wilson <ben.wilson at digicert.com> 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 <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
> <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 <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://lists.cabforum.org/pipermail/public/attachments/20170601/e6a7d573/attachment-0003.html>