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

[Richard Levitte]

In message <c5e2f2ebdd9c42be840c34cdbb7bf3bb at usma1ex-dag1mb1.msg.corp.akamai.com> on Wed, 23 Nov 2016 13:13:05 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> 
rsalz> > Uhmmmm...  the d2i functions are already both in one.  Are you saying they
rsalz> > should be split in two, one part that does all the checking and the other that
rsalz> > just decodes, trusting that all checks are already done?  What you're gonna
rsalz> > do there is double part of the work.
rsalz> 
rsalz> Well, not double, but first do the cascade then return an
rsalz> indicator of which specific one worked.  Then the application
rsalz> can call a routine to again do the decode.

Why is it different if we do exactly that in libcrypto?

rsalz> If it bothers you, return the size as an output parameter.
rsalz> That fits with our i2d model.

Dunno about you, but I'm talking d2i, not i2d.  Different beast.

rsalz> > But, what I get from you is "what if a octet stream matches two different
rsalz> > ASN.1 types?  Is that it?
rsalz> 
rsalz> Yes among others.  How do you know it will *never* happen?

I don't, and in some cases (such as the TSS KEY BLOB), there will most
likely ONLY be a PEM decoder, which is a much easier ballgame.

Quite frankly, that's a though that should go back to David and his
demand of automatic detection.  If anyone would *ever* create a raw
DER file holding a tss OCTET STRING, then the file spec *will* have to
have an indication of what type of content it is.
If we're thinking in URI terms, I could think of a contraption like
file:whatever.pem?t=tsskeyblob ...  or dare I say it,
tpmkey:file=whatever.pem  (David is so going to hate me ;-) ...)


Cheers,
Richard

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