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
