Subject: [core] draft-ietf-core-coap-09 - Authority Name issues with SNI and X.509 certificate

From: Thomas Fossati <[email-masked]>
Date: Sat, 14 Apr 2012 20:18:51 +0200

Section 10.1.3. says:

"The Authority Name in the certificate is the name that would be used in the Authority part of a CoAP URI."

So it seems that a 'host [":" port]' syntax is to be assumed as Authority Name, which  gets quickly furry, both WRT the use of it in a certificate <a/>, and in the SNI extension <b/>.

<a>
The Authority Name should go into the subjectAltName in the X.509 certificate, typically one of 'dNSName' or 'iPAddress' is used when certificates are bound to hosts.  But there is no room for the '[":" port]' there, so none of them can be used in the general case.  One could then fall back on 'otherName', but then an OID needs to be registered to allow a minimum degree of interop.

The same, or worse, applies to the case where EUI-64 is used.
</a>

<b>
RFC 6066 imposes the following restrictions on the server name format:
- "the only server names supported are DNS hostnames"
- "Literal IPv4 and IPv6 addresses are not permitted in HostName

so, the claim "Devices SHOULD support the Server Name Indication (SNI) to indicate their Authority Name in the SNI HostName" seems not completely consistent with RFC 6066.

Luckily "other name types may be added in the future (by an RFC that updates this document)" but then we have to provide this new name format for use in SNI for CoAP endpoints.
</b>

As a side note, the text in 10.1.3.:
"It is worth noting that this [the authority part of a CoAP URI] would typically not be either an IP address or DNS name but would instead be a long term unique identifier for the device such as the EUI-64"
is not consistent with the host production in RFC 3986 (i.e. host = IP-literal / IPv4address / reg-name), unless we want to go all the way to IPvFuture :-)