Opened 10 years ago

Closed 10 years ago

#255 closed other technical (fixed)

Authority Name issues with SNI and X.509 certificate

Reported by: zach@… Owned by: zach@…
Priority: minor Milestone: post-WGLC-1
Component: coap Version: coap-12
Severity: In WG Last Call Keywords:
Cc:

Description

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

  1. 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.

  1. 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.

Change History (2)

comment:1 Changed 10 years ago 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.

comment:2 Changed 10 years ago by cabo@…

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in [1107]:

Clarify the intent of 9.1.3.3.
This isn't solving all the problems listed in #255, but should suffice
to close #255 for now.
The certificate part of this is a good candidate to move it into a
separate draft.

Note: See TracTickets for help on using tickets.