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 <[email protected]> wrote: > Does this position have something to do with SRV names vs. host names? > > > > Thanks, > > > > Ben > > > > *From:* Ryan Sleevi [mailto:[email protected]] > *Sent:* Thursday, June 1, 2017 12:24 PM > *To:* CA/Browser Forum Public Discussion List <[email protected]> > *Cc:* Peter Bowen <[email protected]>; Ben Wilson <[email protected]> > > *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 <[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 > > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
