On Tue, Apr 17, 2012 at 6:57 PM, Eric Covener <cove...@gmail.com> wrote:
For these reasons, the paragraph in question is harmful, and I petition that it be struck from the documentation.How about something to the effect of "optional and optional_no_ca are useful if you want to validate the certificate yourself, and generate your own friendly error response if there's a problem". Or, I'm totally misunderstandng the point.
"optional" means that you can either accept a certificate from a particularly-named CA, or you want to handle the 403 yourself. Various browsers (including Safari) will not let you send a certificate from a CA which hasn't been named in this circumstance, and will provide a blank credential selection dialog with "OK" greyed out and "Cancel" selected. (This feels like "cancel the connection attempt" more than "cancel sending a certificate".) It is related specifically to TLS/1.0 inability to legally send a blank "acceptable CAs" list. optional_no_ca means that you can accept a certificate from any CA, and you want to handle both the situations where there is no certificate and where there is a certificate from an untrusted CA (both 403) in the application. This is useful where you care more about the key than the information directly bound to it. It's also useful when you want to accept self-signed client certificates that contain multiple credential chains, and handle the additional parsing overhead in your application. This requires TLS/1.1+. optional_no_ca is also the only effective means to handle alternate credential formats which can survive basic X.509 parsing, which again requires TLS/1.1+. -Kyle H
Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature
