On 27 May 2017 at 15:05, James Bottomley <[email protected]> wrote: > Added by > > commit 436529562df2748fd9918f578205b22cf8ced277 > Author: David Howells <[email protected]> > Date: Mon Apr 3 16:07:25 2017 +0100 > > X.509: Allow X.509 certs to be blacklisted > > Ironically it duplicates a UEFI bug we've been struggling with for a > while in the pkcs11 handlers: namely if you have a blacklist based on > certificate hashes, an interface which only takes a hash cannot > definitively tell you if the certificate is on the blacklist or not > because the hash the cert is blacklisted by may be a different > algorithm from the hash you feed in to is_hash_blacklisted(). This > means that the only safe way to use the interface is to construct every > possible hash of the cert and feed them one at a time into > is_hash_blacklisted(). This makes it an almost unusable API. > > I suggest you deprecate this interface immediately and introduce an > is_cert_blacklisted() one which takes a pointer to the TBS data. Then > the implementation can loop over the blacklists, see the hash type and > construct the hash of the TBS data for comparison (caching the hashes > for efficiency). That way you'll be assured of a definitive answer and > an easy API. > > It might be reasonable to cc linux-efi on future kernel keyring stuff, > because some of the other issues may have also come up in the UEFI > keyrings. >
Hi James, Thanks for highlighting this. I agree that this should be addressed asap, given that this code has not appeared in a release yet (it was added this cycle) Perhaps redundantly, I'd like to emphasize that this is really not a UEFI specific issue, it applies to any application of X.509 that does not restrict the set of permitted hash algorithms to a single one. Regards, Ard.
