On Tue, Apr 27, 2021 at 01:01:48AM +0300, Vitaly Chikunov wrote: > 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 And, I think all v2 signatures potentially affected. > > > 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. > > > > > > Vitaly, > > > > > > > > >
