On Fri, Oct 21, 2016 at 08:14:50AM -0700, Eric Rescorla wrote: > On Fri, Oct 21, 2016 at 8:06 AM, Ilari Liusvaara <[email protected]> > wrote: > > > On Fri, Oct 21, 2016 at 08:00:33AM -0700, Eric Rescorla wrote: > > > On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara < > > [email protected]> > > > wrote: > > > > > > > On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote: > > > > > On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara < > > > > [email protected]> > > > > > wrote: > > > > > > > > > > And since that implementation supports RFC7250 (for the server > > > > > > certificate), here is my interpretation of it: > > > > > > > > > > > > The certificate type is sent in extensions of EE certificate, > > > > > > via the usual server_certificate_type extension (using the > > server-side > > > > > > syntax from RFC7250). > > > > > > > > > > > > > > > > I think this probably should go in Encrypted Extensions. > > > > > > > > It is definitely related to the certificate chain, > > > > > > > > > My argument would be that it doesn't belong in "individual certificates" > > > because it applies to certificates as a whole. It's not like it would be > > > legal to have a 7250 cert followed by an X.509 cert, one hopes > > > > Well, there can't be two server certificate "chains". But if there > > could, I would expect the type to per-chain. > > > > Sorry, I'm not sure I am following. > > What I am concerned about is the case where ServerCertificate = > > [ > { > Extensions : [ server_certificate_type = RawPublicKey], > Certificate : <some SPKI> > } , > { > Extensions : [], > Certificate : <some X.509 cert> > } > ] > > What is the other side supposed to do with that?
Well, my implementation treats it the same as TLS 1.2 handshake with server_certificate_type=RPK and a two certificates in the chain). Which apparently means just ignoring the second certificate. But if it had certificate type that could use multiple slots, there could only be one chain type (server_certificate_type can only appear once per chain, in the first slot). -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
