--On Tuesday, January 24, 2017 02:01 +0000 John Levine <johnl@xxxxxxxxx> wrote: > In article <14A8995E-D7BF-4994-98F8-875CCED02085@xxxxxxxxxx> > you write: >>> I think this needs to be discussed a bit more in the LAMPS >>> WG, but you have a good point here. >> >> I would extend to 'starting in "XX--" where X can be any >> ascii character" because who knows whether we need a >> completely different prefix one day. > > I hope you mean X can be any ascii letter or digit. After > all, Ctrl/C is an ASCII character. Let me made the suggestion differently. The restriction is in 2.3.1 of RFC 5890. This document should either incorporate that restriction by reference and say as little as possible itself or be sure that whatever it does say is _exactly_ consistent with the definition there. In doing that, note that Figure 1 is a little bit confusing about R-LDH because there is no box for, or formal name assigned to, non-XN R-LDH labels. That said, if X and Y are letters or digits, "XY--" is prohibited because it is an R-LDH label that is not an A-label. If X and/or Y are something else (an ASCII graphic that is neither a letter nor a digits, or even some C0 control) then whether it is prohibited because the third and fourth characters are hyphens or prohibited because the characters are not letters or digits is of the most pedantic interest only because it is prohibited nonetheless. It is actually important to not get wrapped around that axle because "----foo" is prohibited too and that string consists entirely of so-called LDH characters. >> Or you should explicitly note that ascii-only mailboxes do >> imply the literal value and those strings MUST NOT be >> interpreted as A-Labels. > > Urrgh. As far as I know, this is an entirely valid ASCII > address: > > fred@xxxxxxxxxxxxxxxxxx > > That domain name happens to be the A-label for ex᭰le.com but > so what? Have you read the spec, or are you just responding to my notes and/or Patrik's? The LAMPS WG apparently decided that it wanted to insist on U-labels when IDN labels were concerned and that doing so would make comparison rules easier. I wasn't part of their discussions, but believe the issue was that they concluded that certificates should contain one form or the other, but not both (or either on a per-cert basis), and then selected the U-label form. Doing that avoids their having to decide whether fred@xxxxxxxxxxxxxxxxxx and fred@ex᭰le.com were equal and, I assume, a whole set of even more complex issues about hashes and signatures over certificates. I can argue for the choice of A-labels rather than U-labels (or vice versa), but the choice is a matter of taste and I'm happy to accept the WG's analysis and decision. What started the discussion about how to state the prohibition on A-labels is that, unless there is a good reason not to, one needs a rule that does not allow what RFC 5890 calls "Fake A-labels" to be treated as valid strings even while valid A-labels are not. The stronger restriction, i.e., "nothing with '--' in the third or fourth positions", is actually somewhat easier to state and far easier to implement in practice than splitting hairs. Again, unless someone can think of a good reason to allow a Fake A-label in a cert while valid A-labels are not allowed. best, john