IPv6 address encoding in commonName
rgm at htt-consult.com
Thu Aug 15 22:00:48 UTC 2019
I thank you for all this. I will be studying it over the coming week(s).
On 8/15/19 5:39 PM, Jakob Bohm via openssl-users wrote:
> [Top posting to match]
> Note that the actual DC name element is still used for actual domains
> when interacting with Microsoft Active Directory authentication,
> including associated X.509 certificates. So it shouldn't be used for
> something contrary.
> The shortest useful form in terms of certificate size would probably be:
> Put an informal (but fixed format) description of the address scope in
> the user readable CN in certificates at all levels (rootCA, itemCA and
> end cert). Put appropriate human readable organization name or
> equivalent in the O name element in rootCA and itemCA. Make the end
> cert DN as short as possible.
> For example "CN=HIT CA 2 example corp,O=example corp,C=TH" -> "CN=HIT
> factory CA xy,O=Example Chon Buri plant,C=TH" -> "CN=HIT CA for
> [...],O=In your device,C=XX" -> "CN=[2001:db8:a:b::],C=XX" (Using "XX"
> to represent the device might be in any country).
> Put the actual address in the appropriate SAN in the end cert (this
> will be a binary address).
> Put name restrictions in the all the CAs (intermediary and special
> purpose root), these will be a binary address and length for the
> allowed type and the appropriate "nothing" notation for all the other
> defined name restriction types except the distinguished name type.
> Do not include ID number fields except the certificate serial number,
> which also protects the signature hash algorithm via randomization
> (since SHA-1 phase out began, but potentially useful for modern
> Use a short offline-compatible revocation URL such as "ex.th/xy.crl"
> for hierarchies run by the hypothetical EXample conglomerate in
> THailand, where the xy part is a very short name assigned by that
> conglomerate to the issuing central CA or factory intermCA.
> On 15/08/2019 18:49, Robert Moskowitz wrote:
>> 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
>>> > 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
>>> (I was surprised that RFC3779 was not in the SIDR WG's list of
>>> I guess it preceeded the SIDR working group, and occured in PKIX)
>>> In ANIMA's ACP document, we have an abomination that leverages
>>> 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:
>>> Jakob Bohm via openssl-users <openssl-users at openssl.org> wrote:
>>> > As the author of a proposal in this area, could you define a
>>> > 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
>>> > distinguished name restrictions to work correctly.
>>> Yes, we could abuse the DC component.
>>> Were you thinking about:
>> 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
>> So I will research this more, but for this early stage in the
>> development I will use:
>> 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:
>>> > However for the CN in the end cert you could perhaps use the
>>> > DNS reverse IPv6 name
>>> > or the URL/Mail notation
>>> > 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.
More information about the openssl-users