Subject: [core] #255: Authority Name issues with SNI and X.509 certificate

From: "core issue tracker" <[email-masked]>
Date: Tue, 06 Nov 2012 01:22:07 -0000

#255: Authority Name issues with SNI and X.509 certificate

 Thomas Fossati notes (msg03022):

 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.

 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.

 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 :-)

 Solution:

 Define how CoAP uses SNI in Certificates as per RFC6125.

-- 
-----------------------------+-------------------------
 Reporter:  zach@…           |      Owner:  zach@…
     Type:  other technical  |     Status:  new
 Priority:  minor            |  Milestone:  post-WGLC-1
Component:  coap             |    Version:  coap-12
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/255>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Tue, 06 Nov 2012 01:23:06 -0000

Comment (by zach@…):

 (nit12d)

 Esko Dijk notes:

 Section 9.1.3.3

     The Authority Name in the certificate is the name that would be used
 in the Authority part of a CoAP URI. It is worth noting that this 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

 Don't understand this part. The authority of a CoAP URI would typically be
 an IP address or DNS name. Or is this mentioning another type of CoAP URI
 than are normally used.

-- 
-----------------------------+--------------------------
 Reporter:  zach@…           |       Owner:  zach@…
     Type:  other technical  |      Status:  new
 Priority:  minor            |   Milestone:  post-WGLC-1
Component:  coap             |     Version:  coap-12
 Severity:  In WG Last Call  |  Resolution:
 Keywords:                   |
-----------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/255#comment:1>
core <http://tools.ietf.org/core/>