[subject change] In message <3d837eb338bb47a68938676967ed1...@usma1ex-dag1mb1.msg.corp.akamai.com> on Wed, 23 Nov 2016 14:41:14 +0000, "Salz, Rich" <rs...@akamai.com> said:
rsalz> rsalz> > Essentially, you're suggesting that we split out the matching part of the d2i rsalz> > functions and put that to good use. Or do you have some other idea, along rsalz> > the lines if magic? rsalz> rsalz> NO. I am suggesting add one new routine that tries varies rsalz> "convert to native" and returns which conversion worked. And rsalz> then another new routine that takes that return value and calls rsalz> that conversion routine directly. The cost of doing this is rsalz> one extra d2i. By the application. And that first routine rsalz> should ideally return a bitmask of all functions that succeeded rsalz> so that handling ambiguities are built-in to the API. Ok, I hear you, and this can be done. However, since this is in STORE terms, it will have to be a STORE API thing. Not all URIs will give you a DER blob to fiddle with at your heart's content, some of them will just give you a key referense (which is best stored in a EVP_PKEY). Engine keys stored in the engine device are the prime example. rsalz> > rsalz> Security libraries *should not guess.* rsalz> > rsalz> > Isn't telling the application "we think it's a FOO" guessing? What's the rsalz> > application going to do, go "naaaah, methinks it's a BAR" and try to decode rsalz> > the blob as that (and most probably fail) rather than FOO? rsalz> rsalz> It might. Or it might throw up its hands and give up. Or it rsalz> might check to see if the file is ambiguous and do something. rsalz> The point is, it is not openssl that is doing that. Speaking of ambiguity, I was thinking of having my 'file' scheme loader try all d2i's and having it "throw up its hands" if it found more than one matching. STOREerr(..., STORE_R_MABIGUOUS_CONTENT) type of thing... The application or users would be left to give some extra information in the URI. 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
