On St, 2016-11-23 at 00:03 +0100, Richard Levitte wrote: > In message <021a5d5b885845f5ab79c4420232e...@usma1ex-dag1mb1.msg.corp > .akamai.com> on Tue, 22 Nov 2016 18:03:31 +0000, "Salz, Rich" <rsalz@ > akamai.com> said: > > rsalz> It is already possible to write a utility library that tries > rsalz> everything in turn, and returns an enumeration that says > "seems > rsalz> to be an X509 certificate" etc. And then another routine that > rsalz> takes that enumeration and the blob and calls the right > rsalz> decoder. I would be okay with that, even if it were part of > rsalz> OpenSSL. I am opposed to guessing and parsing in one step, > and > rsalz> would -1 any PR for that, forcing a team discussion. > > Uhmmmm... the d2i functions are already both in one. Are you saying > they should be split in two, one part that does all the checking and > the other that just decodes, trusting that all checks are already > done? What you're gonna do there is double part of the work. > > But, what I get from you is "what if a octet stream matches two > different ASN.1 types? Is that it?
I also would not be too much worried - the API call should not be completely universal - the application should know whether it is loading a certificate or private key. It should just be able to use a single call to load a certificate in PEM, DER, or whatever other possible data format. The same for private keys, etc. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev