linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: Vitaly Chikunov <vt@altlinux.org>,
	Mimi Zohar <zohar@linux.ibm.com>,
	linux-integrity@vger.kernel.org
Subject: Re: calc_keyid_v2 producing different keyid for non-sha1 SKIDs
Date: Mon, 26 Apr 2021 16:21:26 -0400	[thread overview]
Message-ID: <738bff9b-5cde-4f06-3e54-4d6eebcf9383@linux.ibm.com> (raw)
In-Reply-To: <20210426193723.rfar32ft3iptorii@altlinux.org>


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?

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


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

  reply	other threads:[~2021-04-26 20:21 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 [this message]
2021-04-26 22:01   ` Vitaly Chikunov
2021-04-26 22:14     ` Vitaly Chikunov
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=738bff9b-5cde-4f06-3e54-4d6eebcf9383@linux.ibm.com \
    --to=stefanb@linux.ibm.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=vt@altlinux.org \
    --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).