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

[Richard Levitte]

In message <1479889418.8937.54.camel at infradead.org> on Wed, 23 Nov 2016 08:23:38 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Tue, 2016-11-22 at 18:06 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > Actually, I agree with this, and that goes along with how our PEM
dwmw2> > routines work (specifically, PEM_X509_INFO_read_bio()), it just
dwmw2> > treats the data as an octet string and hands it down to a d2i routine
dwmw2> > of choice, with a pointer to where to place the result.
dwmw2> > 
dwmw2> > It's not very hard to imagine adding the possibility for external
dwmw2> > handlers for specific PEM content types, which could be handed an
dwmw2> > octet string and a pointer to a X509_INFO (which is the structure used
dwmw2> > to collect the data in), or something like that (I can also imagine
dwmw2> > having one separate handler for each type of data that can be
dwmw2> > returned, so one for a EVP_KEY, one for a X509, one for a X509_CRL,
dwmw2> > and so on and so forth).  That would make it possible for an engine to
dwmw2> > declare its own handler during the binding call, along with all other
dwmw2> > information it feeds back to libcrypto.
dwmw2> 
dwmw2> Yeah, something like that.
dwmw2> 
dwmw2> It's worth noting that the 'PEM content types' are just the same as the
dwmw2> 'DER content types'. It's just that if you have a PEM header, you know
dwmw2> precisely *which* DER content type you have after base64-decoding (and
dwmw2> decryption in some cases), and you don't have to do what
dwmw2> d2i_AutoPrivateKey() does to infer it from the ASN.1 structure.

True.

dwmw2> So maybe it's just "content types" that we have handlers for, each with
dwmw2> an optional PEM tag for matching, *and* an optional match function
dwmw2> which is given the parsed ASN.1 and checks if it's a match.

I'm not sure what you mean with a match function...  but going off on
a limb, how about a reference to an OpenSSL style ASN1 description?
So basically, for an imaginary TSS KEY BLOB (one that actually would
use that TssBlob definition we talked about earlier), these three
items would be specified:

    "TSS KEY BLOB",
    ASN1_ITEM_rptr(TSS_BLOB),	/* TSS_BLOB ASN1 stuff defined in engine */
    handler			/* Essentially a d2i function */

Or did you mean that the matching would also involve checking the
contents of the OCTET_STRING that TSS KEY BLOBs currently are, to see
if they correspond to your structures?  If that's what you mean, my
gut feeling tells me - and I haven't had my morning coffee yet - we're
now moving into a territory where I fully expect dragons...  not to
mention the worries Rich expressed.

Cheers,
Richard ( coffee.  Now! )

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/