All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: Vitaly Chikunov <vt@altlinux.org>
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: Mon, 3 May 2021 10:44:12 -0400	[thread overview]
Message-ID: <c34ae010-6287-24c9-da5b-46cce2c41fe7@linux.ibm.com> (raw)
In-Reply-To: <20210430183308.mfdffqq2osbrqm5e@altlinux.org>


On 4/30/21 2:33 PM, Vitaly Chikunov wrote:
> Stefan,
> .
>> I have been using evmctl successfully with RSA and ECDSA keys now and
>> certificates created by **OpenSSL**. Problems may occur if the
>> certificate-generating tool uses something else than a sha1 to calculate the
>> subject key identifier (skid) and therefore the key id calculated by evmctl
>> (with a sha1) does not match. For the non-working case one could pass in a
>> keyidv2 that the user would have to determine from the certificate's subject
>> key identifier's last 4 bytes.
>>
>> It would be interesting to know which tools do not use a sha1 to calculate
>> the subject key identifier or what types of keys those are so that one could
>> give recommendations for tools to use. GnuTLS's certtool for example does
>> not seem to use the same algorithm to calculate the skid, so I would not
>> recommend using it for generating the certs to be used in conjunction with
>> evmctl and IMA signatures.
> You can also reproduce non-sha1 skid with openssl using subjectKeyIdentifier=
> config option, see x509v3_config(5).

"Subject Key Identifier.

This is really a string extension and can take two possible values. 
Either the word hash which will automatically follow the guidelines in 
RFC3280 or a hex string giving the extension value to include. The use 
of the hex string is strongly discouraged.

Example:

subjectKeyIdentifier=hash"

 From what I know it offers also the possibility of 'none'. It doesn't 
seem to be all that bad when using OpenSSL.

    Stefan



      reply	other threads:[~2021-05-03 14:44 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
2021-04-30 17:19       ` Stefan Berger
2021-04-30 18:33         ` Vitaly Chikunov
2021-05-03 14:44           ` Stefan Berger [this message]

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=c34ae010-6287-24c9-da5b-46cce2c41fe7@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.