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