On 7 August 2016 at 03:26, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > Also, how would this be used in applications that need higher-level > coordination above TLS layer (like HTTP/2)?
The companion h2 draft hasn't been updated, but this will need support from the application layer to use. The intent is to take the structure of draft-bishop-httpbis-http2-additional-certs and remove the stream 0 components and replace them with this draft. > Can applications specify and receive the context values used? E.g. > to act as handles to refer to the resulting authority objects > (HTTP/2 absolutely needs to be able to refer to client authority). The API might take one of two forms: 1. an application requests that authentication happen and get the identifier that TLS uses in return 2. an application requests authentication and specifies the identifier (the TLS stack will have to verify that this is unique and conforms to the restrictions) > Also, are all errors (including things like getting extensions > wrong or CA wrong) fatal to the whole connection, or how is error > reporting handled? One can't use alerts for non-fatal reports. Good question. Errors in encoding or otherwise problems following the rules in the spec should result in a connection-level fatal error. But if the certificate isn't trusted, handling that will be up to the application. > Also, are applications expected to be able to specify exactly > where in stream to put an authentication (response)? Especially > so they can immediately follow with appdata coordinating the > usage. Not sure where you are going here. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
