From: Vitaly Chikunov <vt@altlinux.org>
To: Stefan Berger <stefanb@linux.ibm.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>, linux-integrity@vger.kernel.org
Subject: Re: calc_keyid_v2 producing different keyid for non-sha1 SKIDs
Date: Tue, 27 Apr 2021 01:14:33 +0300 [thread overview]
Message-ID: <20210426221433.mqrtmkpw6fletgmh@altlinux.org> (raw)
In-Reply-To: <20210426220148.nqncx5734dfj5qyx@altlinux.org>
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,
> > >
> > >
> > >
next prev parent reply other threads:[~2021-04-26 22:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-26 19:37 calc_keyid_v2 producing different keyid for non-sha1 SKIDs Vitaly Chikunov
2021-04-26 20:21 ` Stefan Berger
2021-04-26 22:01 ` Vitaly Chikunov
2021-04-26 22:14 ` Vitaly Chikunov [this message]
2021-04-30 17:19 ` Stefan Berger
2021-04-30 18:33 ` Vitaly Chikunov
2021-05-03 14:44 ` Stefan Berger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210426221433.mqrtmkpw6fletgmh@altlinux.org \
--to=vt@altlinux.org \
--cc=linux-integrity@vger.kernel.org \
--cc=stefanb@linux.ibm.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).