[openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 16:07 +0100, Richard Levitte wrote:
> In message <da958b9e865a4268b95fd3e0b07742ff at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 22 Nov 2016 14:42:35 +0000, "Salz, Rich" <rsalz at akamai.com> said:
> 
> rsalz> > dwmw2> It should work out what the contents are for *itself*. Whether
> rsalz> > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
> rsalz> 
> rsalz> I disagree with this approach, but that's just my opinion.  I am worried about "keep trying something until it works" because you'll get strange errors you can't decode, 'only allow N tries' devices will lock you out, and the order in which you try things could result in needless long delays.
> rsalz> 
> rsalz> But don't let that stop you.
> 
> I *think* the guessing part is just about the step of loading the file
> content and transparently understanding what type of content it is.
> That's basically looking at a bunch of bytes and recognising it for
> what it is.  When that's done, the trial and error phase is over, and
> for stuff that libcrypto has support for, libcrypto will be able to
> act, deterministically.
> 
> From the application point of view, this would be just one call, but
> we are talking OpenSSL internals now, aren't we?
> 
> David, correct me if I got you wrong.

You have it entirely correct. Rich has a valid concern for the general
case, but it doesn't apply *here* because we're just talking about
interpreting files. No hardware token is going to get upset and lock
you out, just because you actually look inside the file and work out
what type it is, then treat it as that — instead of forcing the
*application* to look inside the file first, then invoke the crypto
library differently for each type of file (or URI), as shown at 
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl.c#l827

Basically, for every line in that load_certificate() function and the
subfunctions it calls, I hate you :)

When it comes to talking to real hardware, Rich is absolutely right.
You don't just keep trying there. So if you look at the 'Locating
objects in PKCS#11' section of my best practice draft¹ you'll see that
you're only supposed to log into a given token if you *know* that's the
one you need — either because you're looking for a key and you've
already found the corresponding certificate in that token without
having to log in, or because the PKCS#11 URI actually *specified* the
token unambiguously. But that's a separate issue.

-- 
dwmw2

¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/6b18e92f/attachment.bin>