Thanks for the suggestions. I've restructured my PR to include an array of SingleCertificate objects in the Certificate structure.
Ilari: I agree that the post-hanshake auth mechanism as currently described is a bit lacking, but I'd like to sort this out first. Victor: For cached_info, OCSP responses are relatively long-lived and the server should know whether or not a cached OCSP is close to expiration, so cached_info is still useful, but I agree that this makes it less useful. On Fri, Sep 23, 2016 at 2:53 PM Victor Vasiliev <vasi...@google.com> wrote: > The version where each certificate gets its own extension sounds like a > step in the right direction. > > One concern I have is the way this would interact with cached_info > extension. Currently, it allows the entire Certificate message to be > cached -- which just meant the entire chain in 1.2. With the suggested > change, this makes less sense: while you still want to cache SCTs, this > might be much less desirable for OCSP responses. > > On Fri, Sep 23, 2016 at 3:49 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> This seems like a reasonable direction. >> >> -Ekr >> >> >> On Thu, Sep 22, 2016 at 7:26 PM, Nick Sullivan < >> nicholas.sulli...@gmail.com> wrote: >> >>> 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 >>> >>> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
