Subject: [core] CoAP certificate Id's scope (was: Re: #255: Authority Name issues with SNI and X.509 certificate)

From: Thomas Fossati <[email-masked]>
Date: Mon, 10 Dec 2012 13:50:54 +0000

> 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?

I'd volunteer for the task, but it's not clear to me what the scope of
this doc would be (and it seems to me that it has the potential to
become pretty wide).

The base need is to define some _stable_ identifier to be associated
to the certificates that CoAP nodes pass around for the sake of
authenticating each other.

(Because we've decided to go with the PKIX model, which implies a
trusted third party issuing the identity proofs, the stability
attribute of the identifier is key to avoid that a new certificate is
issued each time the identifier moves -- an unbearable cost, both
operational and financial.)

And we seem to have to handle two slightly different kind of identifiers:
(a) those used for server identities, whose expressiveness should be
able to match (only) the served URIs;
(b) those used for requesting identities (clients), which should be
able to identify a node as a requesting application: using the node
name (EUI-64, DNS name), and optionally a source port.

On top of that, we'd probably need a companion syntax to express
identifiers when used for authority selection in SNI, because current
SNI syntax is tailored for the DNS name scenario only.

So, what types of identifiers are there, and which of those could be
used for (a) and (b) ?

At least:
(1) DNS names: common practice, but need DNS which is not mandated in
CoAP base (maybe a problem?);
(2) EUI-64: same as (1) for non DNS deployments, but need another
entity for resolving (RD?);
(3) IP addresses: a poor fallback for (1) and (2) that is subject to
renumbering, dynamic addressing, etc. -- clearly too fragile to be
considered as a source of stable identities;
(4) URIs: nonsensical for (b), but perfect for (a) modulo the
possibility to provide the whole subset of URIs served by the CoAP
end-point in a single (regular) expression.

My feeling is that we should:
- definitely avoid (3); and
- probably require (4) for servers; and
- require (2) or (1) for clients, depending on the availability of DNS.

Further point to think carefully about is the fact that we probably
want to express URI authorities with names like (2) (i.e. with non
regname/IPaddr syntax), and so we may need to extend the syntax of
coap/coaps URIs with the ABNF that is able to express them.

Enough material for the cert draft :-)