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 theCA 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.
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.
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 bederived 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 onematches the ID encoded in the certificate. The first method defined in RFC(SHA-1 of the subjectPublicKey field (not the SPKI as a whole)) is by far themost common method. The two methods in RFC 5280 require only thesubjectPublicKey, whereas some of the methods defined in RFC 7093 use theSubjectPublicKeyInfo as a whole.Thanks,Corey-----Original Message-----From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of RobertMoskowitzSent: Wednesday, June 7, 2023 8:57 AMSubject: Subject Key Identifier hash methodI am trying to figure out if the Subject Key Identifier hash method is carriedin the certificate. An asn1dump of a "regular" cert shows:276:d=4 hl=2 l= 29 cons: SEQUENCE278:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Subject KeyIdentifier283:d=5 hl=2 l= 22 prim: OCTET STRING [HEXDUMP]:04144F0C1A75F4AF13DC67EC18465C020FC22A82616B307:d=4 hl=2 l= 31 cons: SEQUENCE309:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Authority KeyIdentifier314:d=5 hl=2 l= 24 prim: OCTET STRING [HEXDUMP]:30168014A8885F91878E4ED6AA2056C535E2212413F96BA2I cannot easily see if the hashing method is contained here. I am assuming itis 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
