Re: [PATCH v4 3/3] ima-evm-utils: Read keyid from the cert appended to the key file

[Vitaly Chikunov <vt@altlinux.org>]

Stefan,

On Wed, May 05, 2021 at 07:29:17PM -0400, Stefan Berger wrote:
> 
> On 5/5/21 2:48 AM, Vitaly Chikunov wrote:
> > Allow to have certificate appended to the private key of `--key'
> > specified (PEM) file (for v2 signing) to facilitate reading of keyid
> > from the associated cert. This will allow users to have private and
> > public key as a single file. There is no check that public key form the
> > cert matches associated private key.
> > 
> > Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
> > ---
> >   README          | 3 +++
> >   src/libimaevm.c | 8 +++++---
> >   2 files changed, 8 insertions(+), 3 deletions(-)
> > 
> > diff --git a/README b/README
> > index 0e1f6ba..ea11bde 100644
> > --- a/README
> > +++ b/README
> > @@ -127,6 +127,9 @@ for signing and importing the key.
> >   Second key format uses X509 DER encoded public key certificates and uses asymmetric key support
> >   in the kernel (since kernel 3.9). CONFIG_INTEGRITY_ASYMMETRIC_KEYS must be enabled (default).
> > +For v2 signatures x509 certificate with the public key could be appended to the private
> > +key (both are in PEM format) to properly determine its Subject Key Identifier (SKID).
> > +
> >   Integrity keyrings
> >   ----------------
> > diff --git a/src/libimaevm.c b/src/libimaevm.c
> > index a22d9bb..ac4bb46 100644
> > --- a/src/libimaevm.c
> > +++ b/src/libimaevm.c
> > @@ -1017,10 +1017,12 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash,
> >   		return -1;
> >   	}
> > -	if (imaevm_params.keyid)
> > +	if (imaevm_params.keyid) {
> >   		hdr->keyid = htonl(imaevm_params.keyid);
> > -	else
> > -		calc_keyid_v2(&hdr->keyid, name, pkey);
> > +	} else {
> > +		if (_ima_read_keyid(keyfile, &hdr->keyid, KEYID_FILE_PEM_KEY) == ULONG_MAX)
> > +			calc_keyid_v2(&hdr->keyid, name, pkey);
> > +	}
> 
> It might be convenient here to just write the result in network byte order
> into the header but for a library API I find it not so nice, but then
> there's calc_keyid_v2 that does that already... I just wouldn't expect that
> these parameter are in big endian order already, I would expect them in
> native order. 

I expect them in network order, similar to how calc_keyid_v2() already
writes it one line below. So, why should we mix orders? Both functions
write keyids, so it's not like completely different parts of API. Also,
it's documented that ima_read_keyid() writes to the pointer in network
order (and returns integer in host order), so I don't see the
problem. Thus, I would prefer not to follow this suggestion.

Thanks,

> So maybe ima_read_keyid should just return ULONG_MAX or the
> keyid in host order and it call _ima_read_keyid() with a NULL pointer or a
> dummy variable as keyid that the library API caller doesn't see.
> 
>    Stefan
> 
> 
> >   	st = "EVP_PKEY_CTX_new";
> >   	if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL)))