[openssl-dev] [TrouSerS-tech] [tpmdd-devel] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[James Bottomley]

On Tue, 2017-01-03 at 16:40 -0700, Jason Gunthorpe wrote:
> On Tue, Jan 03, 2017 at 03:22:56PM -0800, James Bottomley wrote:
> > > I think it is very important to natively support the sign-only 
> > > key usage restriction. TPM1.2 goes so far as to declare keys that 
> > > can be used for arbitary decrypt as 'legacy do not use'.
> > > 
> > > IMHO the best way to do this is to look at the sign operation 
> > > openssl is trying to do and see if it can be sent down the sign 
> > > path to the TPM. Only if that fails should the decrypt path be
> > > used.
> > 
> > The problem is the MD5-SHA1 signature of SSL and TLS < v1.2.   This
> > cannot be performed by the TPM because it's not listed as a 
> > supported signature, so the choice is either to deprecate these 
> > protocols (not really viable since they're in wide use in old 
> > websites) or use decrypt to do the signatures.  Once we get to the 
> > point of having to use decrypt, there's no reason to preserve the 
> > signing distinction since we never know when a key will be used to
> > decrypt or sign.
> 
> I'm not disputing your analysis, just remarking that it seem very
> undesirable to ban *all* sign-only keys just to support a single
> legacy SSL configuration.

It's not just a single situation.  MD5-SHA1 is where it will fall apart
on backwards compatibility but my current TPM doesn't understand
anything other than sha1 or sha256, so it wouldn't allow more state of
the art algorithms like sha224, sha384 or sha512 either.

> This is why I suggest looking at the sign being requested and using
> the sign path if it is *possible*, otherwise requiring a key with the
> broader key usage.

It's a trade off: the user configuration nightmare: how does an
ordinary user know what type of TPM key they need ... they'll need to
know what their TPM is capable of and what signatures they're likely to
need.  VS the benefits of having single use keys.

I'm just not sure I see enough benefits to trying to preserve the
decrypt vs sign distinction, whereas I do see the floods of complaints
from users who got it wrong or think it should work as advertised.

> Not everything is SSL - openssh uses these routines too and it should
> be able to use the sign only key type without a limitation?

Agreed that openssh only has forward compatibility problems, but it
still has them thanks to the newer algorithm problem.

Actually, the next problem would be gnome-keyring.  It does openssl
signatures and fishing the algorithm type out by the time 

James