The documentation for SSL_CTX_add_client_custom_ext() states that "the
extension type must not be handled by OpenSSL internally or an error

This isn't entirely true. In custom_ext_meth_add() we have this

     * Don't add if extension supported internally, but make exception
     * for extension types that previously were not supported, but now are.

The code that follows this comment just has an explicit exception for
TLSEXT_TYPE_signed_certificate_timestamp, so an application is allowed
to register its own handler for that even when OpenSSL does support it.

(With another hard-coded check in SSL_CTX_add_client_custom_ext() so
that you can only do so if you either don't *enable* OpenSSL's own SCT
support.... or do so *after* registering your custom handler. The
latter probably isn't intentional.)

I'm interested in what interpretation exists of "extension types that
previously were not supported, but now are" that isn't a tautology.

But mostly I'd like to know how it would relate to the PSK identity
support in draft-jay-tls-psk-identity-extension¹.

I'd like to use that extension for OpenConnect VPN, but I'm concerned
that when the RFC is published and OpenSSL starts to support it, my
call to SSL_CTX_add_client_custom_ext() would suddenly start failing.

Would it?



Attachment: smime.p7s
Description: S/MIME cryptographic signature

openssl-dev mailing list
To unsubscribe:

Reply via email to