Re: [TLS] Proposed Change to Certificate message (#654)

[Nick Sullivan <[e-mail]>]

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 <[e-mail]> wrote:

> Nick Sullivan <[e-mail]> 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/
>
>