AuthorityKeyIdentifier and SubjectKeyIdentifier in DRIP X.509 certs

Robert Moskowitz <[email protected]> Sun, 14 May 2023 18:34:42 -0400
Newsgroups gmane.ietf.x509
Message-ID <[email protected]>
https://datatracker.ietf.org/doc/draft-ietf-drip-registries/

defines special, very small, Endorsements that look like X.509 
certificates, and provide what we see needing for DRIP and working over 
very constrained links (like 136-byte size).

See Appendix B for details, but this missive is directed to a PKI 
structure behind the main "DKI" structure.

There are a number of reasons to provide X.509 objects behind the DRIP 
Broadcast Endorsements.  Not the point here now, other than I see 3 
levels of hierarchy in this PKI with the lowest being where the UA 
Endorsemetns live:

Apex Authentication Endorsement (self-signed)
     RAA Authentication Endorsement
         HDA Authentication Endorsement
             HDA Endorsing (signing) Endorsement
                 UA (and other entities) Endorsement

Public keys at all levels have DETs (rfc9374) that are well defined 
(ORCHID) keyIdentifiers of the Public Keys (HI).  These DETs will have 
DNS FQDN

e.g.: 
e.d.c.a.b.0.b.e.0.6.8.2.e.0.b.9.5.0.8.f.f.3.e.f.f.3.0.0.1.0.0.2.ip6.arpa.

With HIP, TLSA, and CERT private OIDs.  You can see our testing now 
under driptesting.org.

So back to X.509 and the nature of the question.

I would like to use the DETs as the SubjectKeyIdentifier and that seems 
to work in my testing with openSSL:

         X509v3 extensions:
             X509v3 Subject Key Identifier:
                 20:01:00:30:00:00:00:05:2A:EB:9A:DC:1C:E8:B1:EC

As you can take this SKI and go right to the DNS to get more about it.

The challenge I am having is with AuthorityKeyIdentifier:

    AuthorityKeyIdentifier ::= SEQUENCE {
       keyIdentifier             [0] KeyIdentifier OPTIONAL,
       authorityCertIssuer       [1] GeneralNames OPTIONAL,
       authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

I SHOULD be able to use the DETS in keyIdentifier as I do with 
SubjectKeyIdentifier, but openSSL is resisting my efforts.  So far.

Plus it is one thing with SubjectKeyIdentifier having DETs, but with 
AuthorityKeyIdentifier I was wondering if there is something I could do 
with authorityCertIssuer?  I am also working on DETs and Endorsements 
having an OID structure under ICAO's arc.  One proposal is:

1.3.27.16.2 is the DRIP arc.

1 is for DETs
1.2 is for Authentication DETs
1.3 is for Endorsing DETs

2 is for Endorsements
2.2 is for Authentication Endorsements
2.3 is for Endorsing Endorsements

So if with authorityCertIssuer I could include the OID 1.3.27.16.2.1.2 I 
would be flagging that this is an Authorization DET.  I don't know if 
this will be of value, as once you get the the DNS structure, you can 
discover this info.  But still is this possible?

Base question is using DETs rather than 'traditional' key hashs for 
AuthorityKeyIdentifier and SubjectKeyIdentifier (and why is openSSL 
fight with AuthorityKeyIdentifier, though that is more a question for 
openSSL developers).

Second question is putting more information into the 
AuthorityKeyIdentifier to identify the type of DET via an OID.

thank you for any insight(s) you can share.

Bob

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix