IPv6 address encoding in commonName

[Robert Moskowitz]

Jackob,

I thank you for all this.  I will be studying it over the coming week(s).

Bob

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 
> algorithms).
>
> 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 
>>> 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.
>
>
> Enjoy
>
> Jakob
>
> Enjoy
>
> Jakob