The documentation for SSL_CTX_add_client_custom_ext() states that "the extension type must not be handled by OpenSSL internally or an error occurs".
This isn't entirely true. In custom_ext_meth_add() we have this comment: /* * 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? -- dwmw2 ¹ https://tools.ietf.org/html/draft-jay-tls-psk-identity-extension-01
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
