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

[David Woodhouse]

On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote:
> 
> 
> 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.

Oh $DEITY no,  not looking in the contents of the OCTET_STRING.
Basically I'm thinking of doing precisely what d2i_AutoPrivateKey()
already does, just with expanded coverage and slightly less hard-coded
stuff.

The "match" part there is a little simplistic; we basically parse the
ASN.1 into a STACK_OF(ASN1_TYPE), then 

 if (sk_ASN1_TYPE_num(inkey) == 6)
   /* it's DSA in OpenSSL's format */
 if (sk_ASN1_TYPE_num(inkey) == 4)
   /* it's ECDSA according to RFC5915 */
 if (sk_ASN1_TYPE_num(unkey) == 3)
   /* Unencrypted PKCS#8 */

... etc.

Those checks could possibly stand to be a *little* more discerning, and
 each one might live in a specific format-handler's "ASN.1 match"
function. But that's the general idea. And we *do* already have the
"decide, then parse" model that Rich was talking about.

And yes, if we're going to make the checks slightly more discerning
then instead of just counting the items in the sequence, we could see
if it matches the ASN.1 description. And as you say, it doesn't have to
be a match *function* for each handler; just the ASN.1 description. 

Doing it like that would prevent any implementations (like the one in
the TPM engine) from being *tempted* to go prodding around in the
contents of OCTET STRINGs. Which is probably a feature :)

-- 
dwmw2
-------------- 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/20161123/bf3b1d72/attachment-0001.bin>