Re: calc_keyid_v2 producing different keyid for non-sha1 SKIDs

[Vitaly Chikunov <vt@altlinux.org>]

Stefan,

https://tools.ietf.org/html/rfc7093

On Mon, Apr 26, 2021 at 04:21:26PM -0400, Stefan Berger wrote:
> 
> On 4/26/21 3:37 PM, Vitaly Chikunov wrote:
> > 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.

> 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

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,

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