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

[Eric Rescorla <[e-mail]>]

This seems like a reasonable direction.

-Ekr


On Thu, Sep 22, 2016 at 7:26 PM, Nick Sullivan <[e-mail]>
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 <[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/
>>
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>