IPv6 address encoding in commonName

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

IPv6 address encoding in commonName

Robert Moskowitz
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.

Thank for any reference(s).


Reply | Threaded
Open this post in threaded view
|

Re: IPv6 address encoding in commonName

OpenSSL - User mailing list
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" .

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?

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.

Examples of boundaries where hierarchical divisions would be practical
(if making a new design, it should be useful outside the HIT/HIP
standards):

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.





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

Reply | Threaded
Open this post in threaded view
|

Re: IPv6 address encoding in commonName

OpenSSL - User mailing list
In reply to this post by Robert Moskowitz
    RFC 8002 (with a null subjectName), but a CA cert MUST have a non-empty
    subjectName.

Non-empty subjectName or non-empty commonName within the subject name?

Shrug.  Doesn't matter, I guess.  Just populate it with the string version of the HIT name, something like
        CN=IP Address 2001:27:dcfc:cb8:d53g:5364:48bj
?

>    My searches today have come up empty.
 
I tried crt.sh and also came up empty; https://crt.sh/?CAName=%25%3A%25  This is not surprising since I would not expect any public CA's to have this kind of thing.

 

Reply | Threaded
Open this post in threaded view
|

Re: IPv6 address encoding in commonName

Robert Moskowitz
In reply to this post by OpenSSL - User mailing list


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


Reply | Threaded
Open this post in threaded view
|

Re: IPv6 address encoding in commonName

Robert Moskowitz
In reply to this post by OpenSSL - User mailing list


On 8/14/19 3:26 PM, Salz, Rich wrote:
>      RFC 8002 (with a null subjectName), but a CA cert MUST have a non-empty
>      subjectName.
>
> Non-empty subjectName or non-empty commonName within the subject name?
>
> Shrug.  Doesn't matter, I guess.  Just populate it with the string version of the HIT name, something like
> CN=IP Address 2001:27:dcfc:cb8:d53g:5364:48bj
> ?

That is what I am coming to see.  Always 'nice' to follow existing
practice.  But given now, set the precedence!

>
>>     My searches today have come up empty.
>    
> I tried crt.sh and also came up empty; https://crt.sh/?CAName=%25%3A%25  This is not surprising since I would not expect any public CA's to have this kind of thing.
>
>    
>

Reply | Threaded
Open this post in threaded view
|

Re: IPv6 address encoding in commonName

Michael Richardson
In reply to this post by Robert Moskowitz

Robert Moskowitz <[hidden email]> 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 <[hidden email]> 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

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

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [




signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 address encoding in commonName

Richard Levitte - VMS Whacker-2
On Thu, 15 Aug 2019 00:47:41 +0200,
Michael Richardson wrote:

>
>
> Robert Moskowitz <[hidden email]> 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)

OpenSSL does support that extension...  crypto/x509v3/v3_addr.c (moved
to crypto/x509/v3_addr.c in next major version) is all about that as
far as I can see.

Thanks for bringing that up.  Trying to infer some kind of meaning
into commonName would be a mistake (isn't previous such hacks the very
reason we have the subjectAltName extension?)

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

"hack" would be the operative word here.  While it's true that this
would fulfill the objective, I frankly wouldn't like to see such a
cert.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 address encoding in commonName

Michael Richardson

Richard Levitte <[hidden email]> wrote:
    > On Thu, 15 Aug 2019 00:47:41 +0200, Michael Richardson wrote:
    >>
    >>
    >> Robert Moskowitz <[hidden email]> 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)

    > OpenSSL does support that extension...  crypto/x509v3/v3_addr.c (moved
    > to crypto/x509/v3_addr.c in next major version) is all about that as
    > far as I can see.

    > Thanks for bringing that up.  Trying to infer some kind of meaning into
    > commonName would be a mistake (isn't previous such hacks the very
    > reason we have the subjectAltName extension?)

Yes, but we didn't let (intermediate) CAs have an empty subject DN, SAN-only,
because we don't have an IssuerAltName for the next level.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 address encoding in commonName

Robert Moskowitz
In reply to this post by Michael Richardson


On 8/14/19 6:47 PM, Michael Richardson wrote:

> Robert Moskowitz <[hidden email]> 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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: IPv6 address encoding in commonName

OpenSSL - User mailing list
[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 <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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