IPv6 address encoding in commonName

[Robert Moskowitz]

On 8/14/19 11:21 AM, Jakob Bohm via openssl-users wrote:
> On 14/08/2019 04:55, Robert Moskowitz 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.
>>
>> My searches today have come up empty.
>>
> If no one comes up with good established practice examples, here are
> some ideas you may work on.
>
> For CA certificates that are not self-signed end certs, it would be
> practical to use a CN that is intentionally different from the end
> certs, such as "Example corp HIP CA for 2001:db8::/48" .

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

This would be for a HHIT HDA 20 in RRA 10 that is using HIT Suite 4.  
Makes perfect sense.  :)

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

The challenge with this is there is an ASSuMption that it looks like an 
IPv6 prefix so that is what is intended.  It might have to be more 
explicit like:

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

Or something close to that.

> 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.
>
> In practice you could follow the nibble notation as already used
> for delegation of IPv6 reverse lookups in DNS.
>
> 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.

I am striving for smallness so that the client issuerName is small. This 
is scary long.  The routing prefix style is probably best for my purpose.

>
> Examples of boundaries where hierarchical divisions would be practical
> (if making a new design, it should be useful outside the HIT/HIP
> standards):

That is why the standard IPv6 prefix notation is best.  People are use 
to it.

>
> 1. After the 1st nibble to cater for IANA design assignments (0 is
>   special, 2 and 3 used for current live assignments, f used for
>   special transmission modes such as multicast and local segment).
>
> 2. After the 2nd to 4th nibble to reflect assignments to continents
>   (RIRs).  Different continents may operate under conflicting legal
>   regimes for internal purposes, such as certificate privacy.
>
> 3. After the 4th to 6th nibble to reflect typical operator (LIR)
>   assignments.
>
> 4. After the 6th to 8th nibble to reflect customer or other specific
>   net assignments.
>
> 5. After the 14th nibble to reflect a single IEEE assigned MAC prefix
>   (For example fe80:0:0:0:3a94:ed00::/88 would match the net local
>   addresses of NETGEAR hardware using the 38-94-ED OUI block).
>
> 6. After the 18th nibble to reflect a single IEEE assigned MAC
>   prefix excluding similar-looking non-MAC addresses (For example
>   fe80:0:0:0:3a94:edff:fe00:/104 for that same block).
>
> 7. Even later nibbles to reflect assignment of part of an OUI block
>   to a factory or production line that generates certificates for
>   devices as they are manufactured.

The CA goes as long in the prefix as needed.  Parsing it follows the 
'known' rules.

> Enjoy
>
> Jakob

Oh, I am.  ;)