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
