Given that we require entry in global DNS (e.g. no unqualified names), that the longest TLD is 24 characters (xn--vermgensberatung-pwb), and the longest allowed label is 63 characters, and in wire format each character is one octet, the longest allowable SAN is:
<36 characters>.<63 chars>.<63 chars>.<63 chars>.<24 chars> which is 249 characters and four dots, for 253 total characters. This matches what is described here: https://blogs.msdn.microsoft.com/oldnewthing/20120412-00/?p=7873 <https://blogs.msdn.microsoft.com/oldnewthing/20120412-00/?p=7873> > On Aug 1, 2017, at 11:50 AM, Erwann Abalea via Public <[email protected]> > wrote: > > Bonsoir, > > I personally think the new definition is clear and unambiguous; a label is > composed of arbitrary octets, and can even be empty (which is the case for > the root). But for the new definition to fit our purpose, we may need to also > include a mention to the « Global DNS » (a new addition in 7719bis), which > clarifies the label lengths, global length, common root, and other things. > > One question for Paul: at Global DNS/Composition of names, it is said that a > domain name has a max length of 255 octets in wire format, and the root > represents one octet. Does that octet account for the leading dot, or in > addition to the leading dot? In other words, should an FQDN expressed in a > SAN:dNSName be limited to 254 octets, or 253 octets? > > Cordialement, > Erwann Abalea > >> Le 1 août 2017 à 17:33, Rich Smith via Public <[email protected]> a écrit : >> >> Thanks for the info, Paul. That new definition, at least to me, seems less >> clear for our purposes than the current one. That really illustrates my >> point well though. I don't think we want to tie critical definitions to an >> outside source that could be changed by groups who likely are not >> considering TLS/WebPKI domain verification in their changes. They may well >> make changes that for their purposes clarifies things, but for our purposes >> has the potential to introduce ambiguities, or otherwise change the >> understood, accepted procedures. >> >> -Rich >> >> -----Original Message----- >> From: Public [mailto:[email protected]] On Behalf Of Paul Hoffman >> via Public >> Sent: Monday, July 31, 2017 1:20 PM >> To: CA/Browser Forum Public Discussion List <[email protected]> >> Subject: Re: [cabfpub] [Ext] Ballot 202 - Underscore and Wildcard Characters >> >> On Jul 31, 2017, at 10:45 AM, Rich Smith via Public <[email protected]> >> wrote: >>> >>> Hi Peter, >>> Overall, I like your suggestions, but could I ask that in definitions where >>> you refer to outside RFC definitions that you include those outside >>> definitions verbatim so that someone reading the BRs does not have to go >>> scouring through all the various RFCs? For example: >>> Change: >>> Domain Label: A “label” as defined in RFC 7719 >>> >>> To: >>> Domain Label: A “Label” as defined in RFC 7719: The identifier of an >>> individual node in the sequence of nodes identified by a fully qualified >>> domain name. >>> >>> This will make it much easier to parse the BRs on their own. Also, I know >>> in general that as a best practice simply pointing to the reference is >>> better so that if the reference definition changes, so would our >>> definitions w/out having to take further action. However in this >>> situation, I would consider that a bug rather than a feature. I don’t >>> think we should allow changes to externally referenced definition to >>> automatically change our definitions, at least in this case, without >>> discussion and voting. >> >> To (apologetically) throw a spanner into the works here: RFC 7719 is being >> revised, and this very definition is changing to be clearer. The current >> draft says: >> >> Label: An ordered list of zero or more octets and which makes up a >> portion of a domain name. Using graph theory, a label identifies >> one node in a portion of the graph of all possible domain names. >> >> >> --Paul Hoffman >> _______________________________________________ >> 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
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
