On Tue, 2016-11-22 at 18:03 +0000, Salz, Rich wrote: > > > It does this by trying to interpret the blob against known ASN.1 > > > definitions, and will only succeed when there's a complete match. > > > I'm > > > not terribly worried... > > I am. With locales and UTF8, the old simple days of text/binary are > probably long gone. And if any ASN.1 definition has extensibility in > it, then we have to be concerned about things being wrapped, > something like prefix attacks, and so on. > > > And even if you were, you should be *more* worried about making > > *applications* do it for themselves :) > > I cannot control what an application does, and I am not responsible > for any other application's reputation. I do have a strongly vested > stake in OpenSSL's. > > It is already possible to write a utility library that tries > everything in turn, and returns an enumeration that says "seems to be > an X509 certificate" etc. And then another routine that takes that > enumeration and the blob and calls the right decoder. I would be > okay with that, even if it were part of OpenSSL. I am opposed to > guessing and parsing in one step, and would -1 any PR for that, > forcing a team discussion.
That's not the proposal. The proposal is to use PEM form because we can make it uniquely self describing using the guard tags which obviates the problem above. On the larger issue of non-self describing formats like ASN.1: if your theory that there's a security hole by allowing opportunistic format detection is correct, simply making the user specify is palming our bug off on to the user and abdicating responsibility because now when they're tricked into an exploit they can be blamed not openssl. If such a bug exists, doing opportunistic format detection the better guarantor of overall system security because if such a bug is found, it would have to be fixed within openssl to everyone's benefit. James -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
