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

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 <ekr@rtfm.com> wrote:

> This seems like a reasonable direction.
>
> -Ekr
>
>
> On Thu, Sep 22, 2016 at 7:26 PM, Nick Sullivan <
> nicholas.sullivan@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 <brian@briansmith.org> wrote:
>>
>>> Nick Sullivan <nicholas.sullivan@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
>
>