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. ;)
