IPv6 address encoding in commonName

[Jakob Bohm]

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" .

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?

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.

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

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.





Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded