On Mon, Aug 08, 2016 at 11:19:39AM +1000, Martin Thomson wrote: > On 7 August 2016 at 03:26, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > > 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)
In 2, I would imagine the context is probably usually a sequence number of some kind. > > 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. And that should presumably be communicated somehow... > > 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. Being able for application to to wait for certificate/cv/finised message to be sent, so it can do something special in application layer immediately after that. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
