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

From: "core issue tracker" <[email-masked]>
Date: Thu, 06 Dec 2012 17:15:16 -0000

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

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 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.

-- 
--------------------------------+---------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  other technical     |      Status:  closed
 Priority:  minor               |   Milestone:  post-WGLC-1
Component:  coap                |     Version:  coap-12
 Severity:  In WG Last Call     |  Resolution:  fixed
 Keywords:                      |
--------------------------------+---------------------------------

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

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 7 Dec 2012 10:49:14 +0000

>  The certificate part of this is a good candidate to move it into a

Quick question: how is the suggested EUI64 going to fit into the
"host" URI production ?

---

From: Zach Shelby <[email-masked]>
Date: Fri, 7 Dec 2012 13:11:07 +0200

Hi,

> Quick question: how is the suggested EUI64 going to fit into the

That is not the intention. 

Instead, what the text is (trying) to say is that constrained endpoints in CoRE often times don't have a DNS based host name (which would be the host URI production) to use in a Certificate, and in those cases use a stable application layer identifier such as an EUI64 as the authority name in a certificate. Such an identifier is not part of the URI production. Then it goes on to say that this identifier is included in the Subject CN field of the X.509 and how it is used for verification. 

We will still need do more editorial work on that section. 

Zach 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Dec 2012 12:31:49 +0100

> We will still need do more editorial work on that section. 

Indeed.  I wonder whether we should be doing what I wrote in the commit comment:
Extract the cert-based section and develop it on a separate axis.  
It will be more unstable than the base document until we have found all the right places to connect to and caused any necessary updates.

To Thomas' question: If you need to fit it into DNS, one way to put an EUI-64 into a DNS context is to do, say, a base32 encode of the identifier and use it as a DNS label.
In a DNS-based system, it's up to the provisioning mechanisms to come up with these names, so there may not even be a need to standardize such a mapping.
For more general applications, draft-farrell-decade-ni is a good source of (URI-based) names (too bad that it will be stuck in the RFC editor queue for another year or so).

It is the lack of clarity about the range of provisioning mechanisms that cause us most of the trouble here.
Reminds me that I still have a SOLACE draft to write...

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 7 Dec 2012 12:27:40 +0000

> It will be more unstable than the base document until we have found all the right places to connect to and caused any necessary updates.

Fully agree with Carsten here.  I think this part is not mature enough
to be included into the main spec.

---

From: Zach Shelby <[email-masked]>
Date: Fri, 7 Dec 2012 21:05:06 +0200

> to be included into the main spec.

As long as this is not required by the IESG security folks for completeness, then I would have no problem doing that.  

I would point out that the way a CoAP client making a request to a coaps:// URI and then verifying that the authority it thinks it is talking to using SubjectAltName is standard practice. This should be left in the specification.

The part that is new is describing how to carry other application layer identifiers in the X.509 and then how to verify those (EUI-64, RD endpoint name etc.). For this it would be useful to have a separate specification. 

Zach

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 7 Dec 2012 20:17:33 +0000

> I would point out that the way a CoAP client making a request to a coaps:// URI and then verifying that the authority it thinks it is talking to using SubjectAltName is standard practice. This shou…

Right.

Another quick question: current text (-13) has rules just for
subjectAltName of type URI.  What should be the behaviour in case of a
DNS name ?

> The part that is new is describing how to carry other application layer identifiers in the X.509 and then how to verify those (EUI-64, RD endpoint name etc.). For this it would be useful to have a…

Yep.  There we could define an OtherName format that is suitable for
that kind of identifiers, and perhaps update 6066 with a companion
NameType for SNI.

---

From: Zach Shelby <[email-masked]>
Date: Fri, 7 Dec 2012 22:32:50 +0200

> subjectAltName of type URI.  What should be the behaviour in case of a

Good eye. That text is still not correct, as I don't see any reason why type URI would be useful here. Instead, we should simply define the use of type DNS as defined in RFC 6025. We also still leave the hole open for using CN if no SubjectAltName exists. I think we should require the use of SubjectAltName for CoAPS, with the use of the DNS type (and/or optionally IP type) as recommended in http://tools.ietf.org/html/rfc6125#section-4. I don't see a reason to define the use of either URI or SRV for CoAPS - neither does HTTPS. 

Looks like we already identified the first WGLC comment :-) Do others agree we should clarify this as described (of course needs work on actual text)?

> that kind of identifiers, and perhaps update 6066 with a companion

Exactly. And using otherName requires us to request our own OID for the purpose, and that will probably need its own specification. Requesting a new NameType is an interesting idea, a longer route but maybe the right thing in the long term. We probably need to talk to the PKIX folks.

Zach

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 8 Dec 2012 21:31:25 +0000

> Good eye. That text is still not correct, as I don't see any reason why type URI would be useful here. Instead, we should simply define the use of type DNS as defined in RFC 6025. We also still lea…

Zach, let me recap to check whether I got your idea correctly:
(a) require SubjectAltName with dNSName
(b) allow a dNSName in CN as a fall back

Is that what you mean ?  If so, I'd support it, as I think it's the
kind of choice that would provide us with a reasonable playground for
implementations, and at the same time would let CoAP-base go smoothly
through WGLC and IESG.

(I think that allowing a SubjectAltName with iPAddress in CoAP-base
has the same problem as EUI-64 or other kind of non-DNS identifiers
for SNI.  So, I'd left this up to be defined in the "coaps/cert"
draft.)

> Exactly. And using otherName requires us to request our own OID for the purpose, and that will probably need its own specification. Requesting a new NameType is an interesting idea, a longer route…

I'm not familiar with the process, but couldn't we just bundle the two
requests in to the same doc ?

---

From: Zach Shelby <[email-masked]>
Date: Sun, 9 Dec 2012 14:17:53 +0200

> (b) allow a dNSName in CN as a fall back

Isn't the general trend in PKIX the depreciation for this use of CN? If that is not the case, then happy to keep it as a backup.

(c) allow SubjectAltName with iPAddress in addition to dNSName

Constrained CoAP endpoints will not make heavy use of DNS names in URIs (which requires DNS resolution), thus the dNSName (or CN) alone are not useful for verifying the Certificate of who you are doing a DTLS handshake with. In cases where an IP address is used in the URI (the common case) then the iPAddress field should be used for verification. Obviously the iPAddress needs to be optional in a Certificate as it is only practical on endpoints with a stable IP address (for example a backend Resource Directory).

> implementations, and at the same time would let CoAP-base go smoothly

Agreed, that should be our goal.

> for SNI.  So, I'd left this up to be defined in the "coaps/cert"

The use of iPAddress is well defined, and in current use today. As it doesn't require any new specification work or identifier requests, thus it should go in the base spec. Especially as this will be a common case of verification. 

> requests in to the same doc ?

I would rather not have multiple ways of doing this. We should either decide to go for otherName with OIDs, or a new field like nameType. But yes, the request should be part of that doc either way. Looks like we need a volunteer to start writing a new I-D on the use of application identifiers in X.509v3 Certificates for CoRE. Anyone?

Zach