IPv6 address encoding in commonName

[Robert Moskowitz]

On 8/14/19 6:47 PM, Michael Richardson wrote:
> Robert Moskowitz <rgm at htt-consult.com> wrote:
>      > I am fiddling around with an intermediate CA signing cert that the CA's
>      > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually a
>      > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised soon).
>
>      > For a client cert, it would be easy to put the HIT in subjectAltName per RFC
>      > 8002 (with a null subjectName), but a CA cert MUST have a non-empty
>      > subjectName.
>
>      > Thus all I want in this subjectName is commonName with the HIT.
>      > I am looking for examples of IPv6 addresses in commonName.
>
> I thought that RFC3779 did exactly what you want, but it does not define new
> Subject DN, but rather a new extension that will be bound to the Subject.
> (I was surprised that RFC3779 was not in the SIDR WG's list of documents,but
> I guess it preceeded the SIDR working group, and occured in PKIX)
>
> In ANIMA's ACP document, we have an abomination that leverages rfc822Name,
> mostly because we figure the odds of getting anything else through
> off-the-shelf CAs is nil.
> Note to consumed with things in your stomach:
>    https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2
>
> Jakob Bohm via openssl-users <openssl-users at openssl.org> wrote:
>      > As the author of a proposal in this area, could you define a notation
>      > for IPv6 DNs, perhaps one that actually reflects the hierarchical nature
>      > of IPv6 addresses?
>
> RFC3779 does some of that, but not in the DN itself.
>
>      > You could take inspiration from the (unfortunately rarely used)
>      > hierarchical DN representation of DNS names (this used the DNS
>      > specific DC name components).  Overall the goal is to allow X.500
>      > distinguished name restrictions to work correctly.
>
> Yes, we could abuse the DC component.
> Were you thinking about:
>       DC=2001/DC=0db8

This looks closest to what is needed here, as the prefix for HHITs is 
currently proposed at /64.

So it would be DC=2001/DC=0024/DC=0028/DC=0014

But the OID for DC is bigggg: 0.9.2342.19200300.100.1.25

Ouch.

So I will research this more, but for this early stage in the 
development I will use:

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

Thanks for all the comments here.

>
>      > In practice you could follow the nibble notation as already used
>      > for delegation of IPv6 reverse lookups in DNS.
>
> so more correctly:
>       DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8
>
>      > However for the CN in the end cert you could perhaps use the full
>      > DNS reverse IPv6 name
>      > "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa"
>      > or the URL/Mail notation "[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]"
>      > where the hex notation shall be the shortest form permitted by the
>      > IPv6 notation spec.
>
> Bob, this seems like the best immediate hack to me.