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

[Robert Moskowitz <[e-mail]>]

On 8/14/19 8:03 PM, Michael Richardson wrote:
> {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,

Given the HHIT prefix as in the example above, the reverse DNS for the 
HDA/RRA can be calculated (first attempt in 
draft-moskowitz-hierarchical-hip, but I am revising it) and additional 
information learned.

In raw HHIT mode, you have the device's HHIT and thus the /64 prefix.  
That gets you to services to learn the HI to validate sigs, for example 
and see if the HHIT revocated and such.

In fact, I am leaning toward a simple DNS structure:

hda.rra.hhit.tld    PTR    foo.com

and foo.com has lots of SRV RR for all the various services it 
provides.  Why go through the allusion of rDNS in this case?

In client x.509 cert mode the issuerName is the CN like above.  But 
again, the subjectName is empty and the SAN is the client HHIT. Well the 
client HHIT prefix MUST be the same as that in the issuerName, so why 
bother with that, other than x.509 says there is an issuerName...

Hope this helps in sharing my thoughts.