Subject Key Identifier hash method

[David von Oheimb]

On Thu, 2023-06-08 at 08:26 -0400, Robert Moskowitz wrote:
> 
> On 6/8/23 01:53, David von Oheimb wrote:
> 
> > 
> > On Wed, 2023-06-07 at 10:46 -0400, Robert Moskowitz wrote:
> > 
> > > thanks all.  It is as I thought.  You have to pretty much know
> > > what the 
> > > CA did.  You can guess, but go read the CP!
> > 
> > I doubt that you'll find such inessential info on SKIDs in a CP.
> > As Tomas wrote, it's just any identifier for the public key that is
> > unique per CA.
> > Since RFC 5280 suggests using the SHA1 hash value of the key and
> > this is a reasonably
> > unique and convenient way to achieve that, this is what most
> > implementations do.
> > There is no need to use anything more involved such as any of the
> > SHA-2 algos.
> 
> Only to look for exceptions to the norm.
> 
> Say that the keying is EdDSA448 which uses SHAKE256 internally.  Why
> require SHA code?  So the SKIDs may be computed with SHAKE.

Of course the cert producer (i.e., the CA) may use also SHAKE or
whatever its implementer may dream up.

> There are other reasonable considerations. 

Yes - for instance, the CA might simply enumerate the public keys that
it certifies and take the bit string of the resulting integer,
which has the advantage that the SKIDs have minimal encoding size.
The spec in https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.5 is
not entirely clear whether the key identification is required to be
injective,
(i.e., whether the same public key, even if contained in different
certificates, must have the same identifier or not),
but looks like this is preferred, such that the CA would need to keep
track of the numbers it assigned to public keys it certified.

>  They will tend to be noteworthy and thus noted accordingly.

There is no need to let certificate users know how the CA came up with
the SKIDs it produces - it's just an implementation detail. 
The only thing that matters is the mentioned uniqueness, since cert path
building procedures (typically) rely on it for efficiency.

 David 

> > > On 6/7/23 10:37, Corey Bonnell wrote:
> > > 
> > > > The hash method isn't explicitly encoded in the certificate, but
> > > > it can be
> > > > derived if you have the SubjectPublicKey(Info). If you have the
> > > > public key,
> > > > then you can calculate the IDs using the various methods and
> > > > seeing which one
> > > > matches the ID encoded in the certificate. The first method
> > > > defined in RFC
> > > > 5280, section
> > > > https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.2
> > > > (SHA-1 of the subjectPublicKey field (not the SPKI as a whole))
> > > > is by far the
> > > > most common method. The two methods in RFC 5280 require only the
> > > > subjectPublicKey, whereas some of the methods defined in RFC
> > > > 7093 use the
> > > > SubjectPublicKeyInfo as a whole.
> > > > 
> > > > Thanks,
> > > > Corey
> > > > 
> > > > -----Original Message-----
> > > > From: openssl-users <openssl-users-bounces at openssl.org> On
> > > > Behalf Of Robert
> > > > Moskowitz
> > > > Sent: Wednesday, June 7, 2023 8:57 AM
> > > > To: openssl-users at openssl.org
> > > > Subject: Subject Key Identifier hash method
> > > > 
> > > > I am trying to figure out if the Subject Key Identifier hash
> > > > method is carried
> > > > in the certificate.  An asn1dump of a "regular" cert shows:
> > > > 
> > > >     276:d=4  hl=2 l=  29 cons:     SEQUENCE
> > > >     278:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3
> > > > Subject Key
> > > > Identifier
> > > >     283:d=5  hl=2 l=  22 prim:      OCTET STRING      [HEX
> > > > DUMP]:04144F0C1A75F4AF13DC67EC18465C020FC22A82616B
> > > >     307:d=4  hl=2 l=  31 cons:     SEQUENCE
> > > >     309:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3
> > > > Authority Key
> > > > Identifier
> > > >     314:d=5  hl=2 l=  24 prim:      OCTET STRING      [HEX
> > > > DUMP]:30168014A8885F91878E4ED6AA2056C535E2212413F96BA2
> > > > 
> > > > 
> > > > I cannot easily see if the hashing method is contained here.  I
> > > > am assuming it
> > > > is a sha2 hash of the EdDSA public keys, but how do I tell?
> > > > 
> > > > Of course I am asking as I want to use the rfc9374 DETs here.
> > > > 
> > > > thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230608/f1216ec7/attachment-0001.htm>