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

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 <vasilvv@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 <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
>>
>>
>