Subject: [dnsext] IANA considerations for DNSCurve?

From: Matthew Dempsky <[email-masked]>
Date: Wed, 7 Apr 2010 10:58:50 -0700

I was curious if anyone has thoughts on what (if any) IANA
considerations are required for DNSCurve.  In my draft, I claim no
action is needed, because it doesn't request reservation of any new
resource types, option codes, etc.

However, after reading RFC 3490 and seeing that the "xn--" prefix was
IANA assigned, perhaps it's appropriate to request IANA formally
assign "54-byte case-insensitive, alphanumeric (but excluding aeio)
labels starting with uz5" to DNSCurve?  Also, to support alternate
cryptosystems, does anyone have suggestions on how that should be
constructed?

E.g., one thought I have is for NIST P-256 public keys to use (say)
uz6 and uz7 followed by 51-bytes of public key info.  Since a P-256
key is a full 256-bit key (unlike Curve25519 which uses 255-bit public
keys), the two separate prefixes are used to avoid adding an extra
byte to the label.

Another possibility is to just use uz6 followed by 52-bytes of public
key.  Slightly simpler encoding, slightly longer labels.

Another possibility is to use uz6 followed by some (encoded) integer
value to indicate it's a P-256 public key and then followed by the
public key itself.  Slightly easier IANA assignment of new codes, but
even longer labels.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Apr 2010 12:04:09 -0700

At 10:58 AM -0700 4/7/10, Matthew Dempsky wrote:
>labels starting with uz5" to DNSCurve? 

Rat-hole alert. Not that what you ask for is wrong: I think it is exactly right. But it might be incredibly contentious. (Disclaimer: I'm the one who came up with the "xn--" hack.)

>Also, to support alternate

The above rule is fine; other signature algorithms can use a different three letters. Note that you are *not* prohibiting the use of uz5<51other> for other legitimate uses. There is no issue with what the user sees, which was the case with the IDNA prefix.

>key.  Slightly simpler encoding, slightly longer labels.

That can be determined later.

>public key itself.  Slightly easier IANA assignment of new codes, but

Again, that can be decided later. For now, it suffices to hint to other signature algorithm designers that doing it similar to the way you have done is a good idea.

--Paul Hoffman, Director
--VPN Consortium