The _jabber._tcp.gmail.com form is a service name. This would be represented in certificates using the id-on-dnsSRV type of otherName 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 <[email protected]> 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:[email protected]] > Sent: Friday, May 26, 2017 10:12 AM > To: CA/Browser Forum Public Discussion List <[email protected]> > Cc: Ben Wilson <[email protected]> > 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 <[email protected]> >> 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:[email protected]] On Behalf Of Ben >> Wilson via Public >> Sent: Thursday, April 20, 2017 12:09 PM >> To: Ryan Sleevi <[email protected]>; CA/Browser Forum Public >> Discussion List <[email protected]> >> Cc: Ben Wilson <[email protected]> >> 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:[email protected]] >> Sent: Thursday, April 20, 2017 11:36 AM >> To: CA/Browser Forum Public Discussion List <[email protected]> >> Cc: Ben Wilson <[email protected]> >> Subject: Re: [cabfpub] Pre-Ballot: Underscore Characters in SANs >> >> >> >> On Thu, Apr 20, 2017 at 1:07 PM, Ben Wilson via Public <[email protected]> >> 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 >> [email protected] >> https://cabforum.org/mailman/listinfo/public >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
