In message <c5e2f2ebdd9c42be840c34cdbb7bf...@usma1ex-dag1mb1.msg.corp.akamai.com> on Wed, 23 Nov 2016 13:13:05 +0000, "Salz, Rich" <rs...@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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev