Re: [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing

[Mimi Zohar <zohar@linux.ibm.com>]

On Thu, 2021-07-01 at 00:10 +0300, Vitaly Chikunov wrote:
> Mimi,
> 
> On Wed, Jun 30, 2021 at 04:47:53PM -0400, Mimi Zohar wrote:
> > On Wed, 2021-06-30 at 22:44 +0300, Vitaly Chikunov wrote:
> > > On Wed, Jun 30, 2021 at 12:39:02PM -0400, Mimi Zohar wrote:
> > > > On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote:
> > > > > On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote:
> > > > > > 
> > > > > > Thank you for the detailed explanation.
> > > > > > 
> > > > > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote:
> > > > > > 
> > > > > > > > Requiring the optarg value to be prefixed with "0x" would
> > > > > > > > simplify the strlen test.
> > > > > > > > (The subsequent patch wouldn't need a contrived prefix.)
> > > > > > > 
> > > > > > > (I do not understand this remark at the moment.)
> > > > > > > 
> > > > > > > Base 16 will let user pass keyid just as a string, copy-pasting from
> > > > > > > somewhere else.
> > > > > > 
> > > > > > strtoul() supports prefixing the ascii-hex string with "0x".  To
> > > > > > differentiate between a keyid and pathname, why not require the keyid
> > > > > > be prefixed with "0x", as opposed to requiring the pathname to be
> > > > > > prefixed with '@', like "--keyid @/path/to/cert.pem".
> > > > > 
> > > > > I wanted to avoid (filename vs keyid) ambiguity of the argument to
> > > > > `--keyid' - if user have file named "0x00112233" they would have hard
> > > > > time passing it to `--keyid'. But, it's impossible to have keyid string
> > > > > starting with "@". So, "@" perfectly distinguish type of `--keyid'
> > > > > argument but "0x" isn't.
> > > > > 
> > > > > Also, in some software (zip, rar) "@" is common prefix meaning value
> > > > > should be taken from the specified file. But, yes, "@" is not common
> > > > > in Unix environments. Do you want me to create separate option like
> > > > > `--keyid-from-file'?
> > > > 
> > > > It's highly unlikely that both the filename and pathname would be
> > > > prefixed with "0x".  Defining a new option might be a good idea. 
> > > > Possibly naming it --extract-cert-keyid,  ---cert-keyid, or --keyid-
> > > > from-cert.  
> > > 
> > > It's not unlikely, because people may want to keep cert files named or
> > > symlinked by keyid. (For example, local cert database keep cert files
> > > symlinked like `f30dd6ad.0'.)
> > > 
> > > I will add an option, most understandable, perhaps, is `--keyid-from-cert'.
> > > 
> > > Also, I will remove base 16 from --keyid argument.
> > 
> > I must be missing something.  "openssl x509", "keyctl show
> > %keyring:<keyring name>", and "getfattr -m security.ima -e hex --dump"  
> > all display the skid in hex.  Why would anyone provide the skid as
> > something other than in hex?
> 
> Ah, I thought you want '0x' prefix mandatory. Will not remove base 16
> then. Also, /proc/keys shows keyid without '0x' prefix.

Why?  One doesn't preclude the other.   "keyid = strtoul(optarg, &eptr,
16);" recognizes an "0x" prefixed string as being ascii-hex.

Mimi