IPv6 address encoding in commonName

[Jakob Bohm]

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