On 05:03 pm, martin at v.loewis.de wrote: >>I really don't understand why you would not expose all data in the >>certificate. > >You mean, providing the entire certificate as a blob? That is planned >(although perhaps not implemented). > >Or do you mean "expose all data in a structured manner". BECAUSE >IT'S NOT POSSIBLE. Sorry for shouting, but people don't ever get the >notion of "extension". "structure" is a relative term. A typical way to deal with extensions unknown to the implementation is to provide ways to deal with the *extension-specific* parts of the data in question, c.f. http://java.sun.com/j2se/1.4.2/docs/api/java/security/cert/X509Extension.html Exposing the entire certificate object as a blob so that some *other* library could parse it *again* seems like just giving up. However, as to the specific issue of subjectAltName which Chris first mentioned: if HTTPS isn't an important specification to take into account while designing an SSL layer for Python, then I can't imagine what is. subjectAltName should be directly supported regardless of how it deals with unknown extensions. >>It seems totally obvious. The data is there for a reason. >>I want the subjectAltName. Probably other people want other stuff. Why >>cripple it? Please include it all. >That's not possible. You can get the whole thing as a blob, and then >you have to decode it yourself if something you want is not decoded. Something very much like that is certainly possible, and has been done in numerous other places (including the Java implementation linked above). Providing a semantically rich interface to every possible X509 extension is of course ridiculous, but I don't think that's what anyone is actually proposing here.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4