On Mon, Oct 31, 2016 at 09:29:19PM +0000, Nick Sullivan wrote:
> <https://tools.ietf.org/html/
> <https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>
> draft-sullivan-tls-exported-authenticator-00>
> <https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>
> 
> I just posted a new Internet-Draft called "Exported Authenticators in TLS"
> in the TLS working group.
> 
> The intent of this draft is to enable participants in a TLS connection to
> prove ownership of additional certificates. This differs from previous
> proposals (https://tools.ietf.org/html/draft
> -sullivan-tls-post-handshake-auth-00) in that these proofs are not sent as
> part of the TLS connection, but instead exported so that they can be sent
> out of band (as part of an application layer message, for example).
> 
> This proposal should enable a radical simplification of the Secondary
> Certificate Authentication in HTTP/2 proposal (
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01),
> and should generally be a useful tool for binding a certificate ownership
> proof to a TLS connection.

This looks A LOT saner than the current post-handshake stuff in TLS 1.3
draft. Looks implementable even.

One comment about API: There should be a method to query the TLS library
capabilities with CertificateVerify algorithm verification.

The result could e.g. be list of algorithm numbers (e.g. 0403, 0503,
0603, 0804, 0805, 0806, 0807, 0808).

Also one bit unclear thing: Is RSA-PKCS1#v1.5 allowed if negotiated
TLS version is 1.2?


-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to