Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?

Hi Henry, Extension_data field can be zero-length: opaque extension_data<0..2^16-1>; The TLS 1.3 draft specifies matching rules for two extensions: KU and EKU and then says: "Separate specifications may define matching rules for other certificate extensions." Which means that you should be

Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?

> On 8 Mar 2016, at 09:30, Eric Rescorla wrote: > > CertificateRequest already allows you to pass an arbitrary number of > extensions by OID. > > http://tlswg.github.io/tls13-spec/#certificate-request > > > What more do

Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?

> On 8 Mar 2016, at 08:30, Eric Rescorla wrote: > > CertificateRequest already allows you to pass an arbitrary number of > extensions by OID. > > http://tlswg.github.io/tls13-spec/#certificate-request > > > What more do

Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?

CertificateRequest already allows you to pass an arbitrary number of extensions by OID. http://tlswg.github.io/tls13-spec/#certificate-request What more do you think you need? -Ekr On Tue, Mar 8, 2016 at 12:22 AM, Henry Story wrote: > Hi, > > > I was reading with

[TLS] Generalising DN's to SAN and IAN in TLS1.3?

Hi, I was reading with interest M. Thomson and M. Bishop's "Reactive Certificate-Based Client Authentication" draft RFC [1]. In the section 2.3 "The CERTIFICATE_REQUEST Frame" [[ CA-Count and Certificate-Authorities: "Certificate-Authorities" is a series of distinguished names