This suggestion makes sense to me. Both the SCT and OCSP v2 extension allow for multiple objects in order to cover multiple certificates in a chain, but your suggestion makes the grouping much more explicit and obviates the need for OCSPv2. I'd definitely consider a modification like this.
Nick On Thu, Sep 22, 2016 at 7:17 PM Brian Smith <br...@briansmith.org> wrote: > Nick Sullivan <nicholas.sulli...@gmail.com> wrote: > >> PR: https://github.com/tlswg/tls13-spec/pull/654 >> > >> This change adds a set of extensions to the Certificate message. With >> this change, the Certificate message can now hold all extension messages >> that are certificate-specific (rather than connection-specific). This >> change also resolves the anomaly of OCSP messages appearing before >> certificates in the handshake. >> > > There are two ways that such a thing could be done. How your proposal > suggests: > > opaque ASN1Cert<1..2^24-1>; > struct { > opaque certificate_request_context<0..2^8-1>; > ASN1Cert certificate_list<0..2^24-1>; > Extension extensions<0..2^16-1>; > } Certificate; > > or: > > opaque ASN1CertData<1..2^24-1>; > struct { > ASN1CertData cert_data; > Extension extensions<0..2^16-1>; > } > > struct { > opaque certificate_request_context<0..2^8-1>; > ASN1Cert certificate_list<0..2^24-1>; > } Certificate; > > I think you are right that the SCT and the OCSP response are > per-certificate. In particular, they are not per-certificate-chain, so to > me the latter form, where each certificate in the chain gets its own > extension list, makes more sense to me. Would you consider changing the > proposal to the second form? > > Cheers, > Brian > -- > https://briansmith.org/ > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
