calc_keyid_v2 producing different keyid for non-sha1 SKIDs
Hi,
I am reported that IMA signatures where SKID is not just sha1 of the public key (but something different, for example different hash algo, such as Streebog) have "wrong" keyid in the signature. This is because
a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID) x509 extension, (or if this fails it takes just serial, perhaps, we can disregard this corner case), it never does sha1 over the public key). But, b) evmctl, when signing, uses just private key (not even knowing certificate where SKID should be) and calculating sha1 of public key. Thus, keyids could mismatch each other, and it's even not easy to fix evmctl, because there is no cert at the time of signing.
Perhaps, we should fix this somehow. For example, when signing, introduce new option --cert, where SKID should be extracted. Does it looks reasonable?
Vitaly,
Quoted 8 lines · Vitaly Chikunov
Hi,
I am reported that IMA signatures where SKID is not just sha1 of the public key (but something different, for example different hash algo, such as Streebog) have "wrong" keyid in the signature. This is because
a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID) x509 extension, (or if this fails it takes just serial, perhaps, we can disregard this corner case), it never does sha1 over the public key).
Is it wrong for ecrdsa keys? What is the spec?
Here's the spec that describes using sha1 for the skid which seems to work like this for RSA and ECDSA keys from what I can tell:
https://tools.ietf.org/html/rfc3280#section-4.2.1.2
Quoted 13 lines
But, b) evmctl, when signing, uses just private key (not even knowing certificate where SKID should be) and calculating sha1 of public key. Thus, keyids could mismatch each other, and it's even not easy to fix evmctl, because there is no cert at the time of signing.
Perhaps, we should fix this somehow. For example, when signing, introduce new option --cert, where SKID should be extracted. Does it looks reasonable?
Vitaly,
Stefan,
https://tools.ietf.org/html/rfc7093
Quoted 12 lines · Stefan Berger
Quoted 8 lines · Vitaly Chikunov
Hi,
I am reported that IMA signatures where SKID is not just sha1 of the public key (but something different, for example different hash algo, such as Streebog) have "wrong" keyid in the signature. This is because
a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID) x509 extension, (or if this fails it takes just serial, perhaps, we can disregard this corner case), it never does sha1 over the public key).
Quoted 1 line
Is it wrong for ecrdsa keys? What is the spec?
It seems, some CA provide by default certs with Streebog-256 hash as drop-in replacement for SHA1, so their users forced to (re-)request the certs with a compatible SHA1 SKID.
Quoted 4 lines
Here's the spec that describes using sha1 for the skid which seems to work like this for RSA and ECDSA keys from what I can tell:
Perhaps, you meant https://tools.ietf.org/html/rfc5280#section-4.2.1.2
"Other methods of generating unique numbers are also acceptable."
Also, see https://tools.ietf.org/html/rfc7093
Thanks,
Quoted 15 lines
Quoted 15 lines
But, b) evmctl, when signing, uses just private key (not even knowing certificate where SKID should be) and calculating sha1 of public key. Thus, keyids could mismatch each other, and it's even not easy to fix evmctl, because there is no cert at the time of signing.
Perhaps, we should fix this somehow. For example, when signing, introduce new option --cert, where SKID should be extracted. Does it looks reasonable?
Vitaly,
Quoted 26 lines · Vitaly Chikunov
Stefan,
https://tools.ietf.org/html/rfc7093
Quoted 12 lines · Stefan Berger
Quoted 8 lines · Vitaly Chikunov
Hi,
I am reported that IMA signatures where SKID is not just sha1 of the public key (but something different, for example different hash algo, such as Streebog) have "wrong" keyid in the signature. This is because
a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID) x509 extension, (or if this fails it takes just serial, perhaps, we can disregard this corner case), it never does sha1 over the public key).Quoted 1 line
Is it wrong for ecrdsa keys? What is the spec?
It seems, some CA provide by default certs with Streebog-256 hash as drop-in replacement for SHA1, so their users forced to (re-)request the certs with a compatible SHA1 SKID.
Quoted 3 lines
Here's the spec that describes using sha1 for the skid which seems to work like this for RSA and ECDSA keys from what I can tell:
Quoted 7 lines
Quoted 1 line
Perhaps, you meant https://tools.ietf.org/html/rfc5280#section-4.2.1.2
"Other methods of generating unique numbers are also acceptable."
Also, see https://tools.ietf.org/html/rfc7093
And, I think all v2 signatures potentially affected.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
But, b) evmctl, when signing, uses just private key (not even knowing certificate where SKID should be) and calculating sha1 of public key. Thus, keyids could mismatch each other, and it's even not easy to fix evmctl, because there is no cert at the time of signing.
Perhaps, we should fix this somehow. For example, when signing, introduce new option --cert, where SKID should be extracted. Does it looks reasonable?
Additionally, we could add `--keyid' option, so users could manually set keyid without extracting it from the cert file.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Vitaly,
Quoted 24 lines · Vitaly Chikunov
Quoted 23 lines · Vitaly Chikunov
Stefan,
https://tools.ietf.org/html/rfc7093
Quoted 11 lines · Stefan Berger
Quoted 8 lines · Vitaly Chikunov
Hi,
I am reported that IMA signatures where SKID is not just sha1 of the public key (but something different, for example different hash algo, such as Streebog) have "wrong" keyid in the signature. This is because
a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID) x509 extension, (or if this fails it takes just serial, perhaps, we can disregard this corner case), it never does sha1 over the public key).Is it wrong for ecrdsa keys? What is the spec?
It seems, some CA provide by default certs with Streebog-256 hash as drop-in replacement for SHA1, so their users forced to (re-)request the certs with a compatible SHA1 SKID.
Quoted 3 lines
Here's the spec that describes using sha1 for the skid which seems to work like this for RSA and ECDSA keys from what I can tell:
Quoted 7 lines
Quoted 6 lines
Quoted 1 line
Perhaps, you meant https://tools.ietf.org/html/rfc5280#section-4.2.1.2
"Other methods of generating unique numbers are also acceptable."
Also, see https://tools.ietf.org/html/rfc7093
And, I think all v2 signatures potentially affected.
I have been using evmctl successfully with RSA and ECDSA keys now and certificates created by **OpenSSL**. Problems may occur if the certificate-generating tool uses something else than a sha1 to calculate the subject key identifier (skid) and therefore the key id calculated by evmctl (with a sha1) does not match. For the non-working case one could pass in a keyidv2 that the user would have to determine from the certificate's subject key identifier's last 4 bytes.
It would be interesting to know which tools do not use a sha1 to calculate the subject key identifier or what types of keys those are so that one could give recommendations for tools to use. GnuTLS's certtool for example does not seem to use the same algorithm to calculate the skid, so I would not recommend using it for generating the certs to be used in conjunction with evmctl and IMA signatures.
Also, evmctl could for example use a different hash if for example tools creating certs for ecrdsa keys most often use a streebog hash. This would make it easier for the user not having to determine the keyid.
Quoted 11 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
But, b) evmctl, when signing, uses just private key (not even knowing certificate where SKID should be) and calculating sha1 of public key. Thus, keyids could mismatch each other, and it's even not easy to fix evmctl, because there is no cert at the time of signing.
Perhaps, we should fix this somehow. For example, when signing, introduce new option --cert, where SKID should be extracted. Does it looks reasonable?
Additionally, we could add `--keyid' option, so users could manually set keyid without extracting it from the cert file.
Agreed.
Stefan
Stefan,
Quoted 42 lines · Stefan Berger
Quoted 24 lines · Vitaly Chikunov
Quoted 23 lines · Vitaly Chikunov
Stefan,
https://tools.ietf.org/html/rfc7093
Quoted 11 lines · Stefan Berger
Quoted 8 lines · Vitaly Chikunov
Hi,
I am reported that IMA signatures where SKID is not just sha1 of the public key (but something different, for example different hash algo, such as Streebog) have "wrong" keyid in the signature. This is because
a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID) x509 extension, (or if this fails it takes just serial, perhaps, we can disregard this corner case), it never does sha1 over the public key).Is it wrong for ecrdsa keys? What is the spec?
It seems, some CA provide by default certs with Streebog-256 hash as drop-in replacement for SHA1, so their users forced to (re-)request the certs with a compatible SHA1 SKID.
Quoted 3 lines
Here's the spec that describes using sha1 for the skid which seems to work like this for RSA and ECDSA keys from what I can tell:
Quoted 7 lines
Quoted 6 lines
Quoted 1 line
Perhaps, you meant https://tools.ietf.org/html/rfc5280#section-4.2.1.2
"Other methods of generating unique numbers are also acceptable."
Also, see https://tools.ietf.org/html/rfc7093
And, I think all v2 signatures potentially affected.
I have been using evmctl successfully with RSA and ECDSA keys now and certificates created by **OpenSSL**. Problems may occur if the certificate-generating tool uses something else than a sha1 to calculate the subject key identifier (skid) and therefore the key id calculated by evmctl (with a sha1) does not match. For the non-working case one could pass in a keyidv2 that the user would have to determine from the certificate's subject key identifier's last 4 bytes.
Quoted 6 lines
It would be interesting to know which tools do not use a sha1 to calculate the subject key identifier or what types of keys those are so that one could give recommendations for tools to use. GnuTLS's certtool for example does not seem to use the same algorithm to calculate the skid, so I would not recommend using it for generating the certs to be used in conjunction with evmctl and IMA signatures.
You can also reproduce non-sha1 skid with openssl using subjectKeyIdentifier= config option, see x509v3_config(5).
Thanks,
Quoted 10 lines · Vitaly Chikunov
Stefan,
.Quoted 8 lines
I have been using evmctl successfully with RSA and ECDSA keys now and certificates created by **OpenSSL**. Problems may occur if the certificate-generating tool uses something else than a sha1 to calculate the subject key identifier (skid) and therefore the key id calculated by evmctl (with a sha1) does not match. For the non-working case one could pass in a keyidv2 that the user would have to determine from the certificate's subject key identifier's last 4 bytes.
Quoted 8 lines
Quoted 6 lines
It would be interesting to know which tools do not use a sha1 to calculate the subject key identifier or what types of keys those are so that one could give recommendations for tools to use. GnuTLS's certtool for example does not seem to use the same algorithm to calculate the skid, so I would not recommend using it for generating the certs to be used in conjunction with evmctl and IMA signatures.
You can also reproduce non-sha1 skid with openssl using subjectKeyIdentifier= config option, see
x509v3_config(5).
"Subject Key Identifier.
This is really a string extension and can take two possible values. Either the word hash which will automatically follow the guidelines in RFC3280 or a hex string giving the extension value to include. The use of the hex string is strongly discouraged.
Example:
subjectKeyIdentifier=hash"
From what I know it offers also the possibility of 'none'. It doesn't seem to be all that bad when using OpenSSL.
Stefan