Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1327879

Re: [RFC PATCH 03/20] X.509: Allow X.509 certs to be blacklisted [ver #2]

From Mimi Zohar <zohar@linux.vnet.ibm.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 03/20] X.509: Allow X.509 certs to be blacklisted [ver #2]
Date 2016-02-05 17:20 +0100
Message-ID <qYRh0-2zl-15@gated-at.bofh.it> (permalink)
References <qT7HQ-3eL-15@gated-at.bofh.it> <qSCNI-78i-3@gated-at.bofh.it> <qSCNJ-78i-43@gated-at.bofh.it> <qY7QS-3Om-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi David,

On Wed, 2016-02-03 at 15:46 +0000, David Howells wrote:
> Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > > Allow X.509 certs to be blacklisted based on their TBS hash. 
> > 
> > What is the TBS hash?  This doesn't seem to be the key identifier.
> 
> It's the TBSCertificate hash (I'll change to calling it that in the patch
> description).  "TBS" stands for "To Be Signed".  This is what is hashed for
> the signature to be generated upon - so it's something we have to expend
> resources calculating anyway.
> 
> The reason I'm using this is this is what UEFI puts into its blacklist.  See:
> 
> 	http://uefi.blogspot.co.uk/2013/09/uefi-24-review-part-13-hash-of.html
> 
> To quote:
> 
> 	Now, in the UEFI 2.4 specification, three new types of signatures for
> 	the black list were added. Specifically, the various recommended forms
> 	of the To-Be-Signed hash value (160, 256 and 512-bits) which are
> 	created during the creation of a certificate could be added to the
> 	black list instead of the certificate itself.
> 
> > The cert associated with this key identifier is loaded onto the .ima
> > keyring.
> 
> We could also check that.  There's no requirement that we only check the TBS -
> but the TBS hash is something we must check.

Ok, but before "IMA: Use the system blacklist keyring" patch, this needs
to be addressed.

> I wonder if I should mark the blacklist key as to what the value it holds
> should be checked against.  There's a number of different things we could put
> in there:
> 
>  (1) TBSCertificate hash.
> 
>  (2) Subject Key Identifier content.
> 
>  (3) Authenticode Binary hash (for PE files).
> 
>  (4) PKCS#7 component digest.

Ok

> > eg:  openssl x509 -in <pathname> -inform DER -notext -out
> > 
> > <snip>
> > 
> >         X509v3 extensions:
> >             X509v3 Subject Key Identifier: 
> > 
> > 71:12:39:B3:AB:E6:8D:BF:70:E7:26:DE:C8:4A:3F:5F:17:EF:00:6C
> 
> Note that this isn't a mandatoryy field and if it's not present, we have no way
> to calculate it as there's no one standard-defined method.

The hex string appears when displaying the keys.  For example, 
 keyctl show %keyring:.ima shows:

734429129 --als--v      0     0   \_ asymmetric: : local: signing key:
711239b3abe68dbf70e726dec84a3f5f17ef006c

Mimi

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Re: [RFC PATCH 03/20] X.509: Allow X.509 certs to be blacklisted [ver #2] David Howells <dhowells@redhat.com> - 2016-02-03 16:50 +0100
  Re: [RFC PATCH 03/20] X.509: Allow X.509 certs to be blacklisted  [ver #2] Mimi Zohar <zohar@linux.vnet.ibm.com> - 2016-02-05 17:20 +0100

csiph-web