Re: [Tm-rid] IPv6 address encoding in commonName

[Michael Richardson <[e-mail]>]

{Bob, replying to tm-rid list from openssl list, since this is not about openssl}

Robert Moskowitz <[e-mail]> wrote:
    > I am working with a 2-tier pki.  The root CA cert will have some sort of
    > standard DN for subjectName, naming the owner of the pki. The intermediate
    > signing CA certs are for the agencies that actually register and, to some
    > degree, manage these devices.  All these agencies will be 'named' by the HHIT
    > (draft-moskowitz-hierarchical-hip) derived from the ed25519 key of their
    > signing cert.  Well they are named by their /64 per the draft.   And perhaps
    > that is better, as over the years there will be new signing certs with
    > different keys, but the same HHIT prefix. Hmmm.

    > Also size of the DN is important as it is the issuerName in the client cert
    > which may get transmitted over a very constrained (e.g. BT4) link.  The
    > intermediate CA cert has ITS issuerName of the root cert that identifies the
    > pki for this purpose.  So the CN could simply be:

    > CN=2001:24:28:24/64

In the 6tisch 802.15.4 space, where we are hoping to do EDHOC,
we are trying to find a way to send the IDevID (which may be largish due to
various extensions) by reference rather than value.

It seems that you have the same problem with the intermediate CAs as we do.
draft-hallambaker-mesh-udf-05
is one thing I've looked at, but it isn't clear how much of a win it is.

As your intermediates will be identified by HITT, could you store them in
reverse DNS?

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-