Ah, but this hits at the crux of the openssl docs. Of course, it is silly to presume a fixed library will handle open-ended verification. And, indeed, I handle CRLs and OCSP in my own verify function.
The problem is when I read a vague admonishment to not supply my own verification function because the default one probably "does the right thing". Well, OK, but WHAT exactly is that? So that I can decide if I NEED to do more. This is compounded when I see openssl functions to manage CRL and OCSP objects in ASN1 and internal coded forms. So, I put two and two together and ask myself, "Self, to what degree is there support for some kind of 'default' handling of CRL retrieval or OCSP lookup in the 'built in' verification function?" I can see arguments for "none at all -- openssl does not make TCP connections behind your back" to "well, something arbitrary that we thought was a good idea". What I want to see from the docs is WHICH of these is true. It looks like the openssl verification function is provided for "convenience" to do the most basic of verification (validation against internally loaded trusted certs) and serves as a sample of what to do. In that case, it should be in a separate section of code, at a different "level", if you will, provided as an application "convenience" or "starting point", almost part of an apps library rather than openssl proper code. Now, given that many openssl users will WANT to do CRL checking, or OCSP retrieval, (and, heck, if there is a stapled OCSP response, lets have at it in a callback), it stands to reason that a "convenience" library above openssl is the next "level" of abstraction and sophistication. But, the current docs do not hint at these kind of strata within the existing library, or that the user is expected to provide them. I see a need to break functions up according to 1) object manipulation 2) state manipulation 3) protocol handling 4) higher level validation and verification. Some of these may not belong in openssl, but if there is a decision of what the scope of the project is, it should be made clear. To provide some perspective, I am using openssl in a proxying configuration, generally carrying HTTP traffic. (We decrypt, and reencrypt traffic with certs resigned by CAs the downstream client trusts). So, I have to mimic all the stuff a browser does: CRL checking, OCSP lookup, etc. It is confusing when, at a glance, I see that openssl has "CRL support" and "OCSP support. The question that screams in my mind is, "O.K. To WHAT degree?" What is the reasoning behind the SCOPE of support to provide for these higher level security aspects in the openssl project? Object manipulation? Callback functions? (TLS extensions in Hello messages are nice, but I'd like to see functions to let me set encoded versions on Hellos I want to send -- is that in scope or not? Implemented yet, or not? If you give me something that is received, I'd like to be able to send that same something) I am not suggesting that this has to be implemented to satisfy my need. But, it is not clear from the documentation in it present form what the scope of supporting things like this is, and confusing when I see that version such and such now "supports foo". -----Original Message----- From: owner-openssl-us...@openssl.org on behalf of Patrick Patterson Sent: Wed 12/2/2009 12:33 PM To: openssl-users@openssl.org Subject: Re: General question about documentation Hi Rene: Rene Hollan wrote: > > 2) Things like OCSP, CRLs, and other SSL "extensions" have always > stumped me. Is it something the user of the library is responsible > for, when validating a cert, or can the library do it itself when I > try to establish an SSL connection, and to what degree can I control > this? It always struck me that the cert validation callback is the > place to do this, but I take heed of the fact that openssl is > supposed to have a reasonable default cert validation routine and not > to replace it without good reason. > This really has nothing to do with OpenSSL - or at least, only tangentially - If you don't understand the basics of how the IETF and ITU have defined X.509 and the Internet profiles, then no amount of OpenSSL documentation is going to save you. If you read the specifications, you can very easily see that not only does OpenSSL not do every kind of validation under the sun, you probably wouldn't want it to (do you really want OpenSSL implementing a full HTTP stack in the crypto library just so that it can chase AIA, OCSP and CRLDP?) - So until one has a fuller understanding of exactly how the X.509 path discovery and validation process works, then it is very difficult to see where OpenSSL should fit in this. The current documentation, I think, for X509_verify and friends is, while not perfect, certainly adequate for anyone that knows exactly what they are doing to "do the right thing" (it was certainly fine for us when writing Pathfinder and WvStreams). Please don't confuse "OpenSSL needs more documentation", with "The IETF and others should work harder to ensure that there are better examples and tutorials out there so that people implement PKI (and by extension TLS/SSL) properly". And I agree with Victor - unless someone from the core OpenSSL team steps up, or someone volunteers to set up some sort of Wiki and pay for someone to spend a lot of time writing documentation, then I think this thread has gotten about as far as it can. Patrick. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
<<winmail.dat>>
