Re: IPv6 address encoding in commonName

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux