Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate?

From: Rob Stradling <[email-masked]>
Date: Tue, 1 Mar 2016 11:49:48 +0000

On 29/02/16 19:30, Stephen Kent wrote:
> Rob,
>
> I'm not sure what your proposed resolution for this issue means.
>
> Phases like "a suitably name-constrained intermediate cert" and

This phrase is <xref>'d to the section currently numbered 4.3 (Using a 
Name-Constrained Intermediate CA).

Is that not sufficient?

> "clients may need to used trial and error" are not really appropriate
> for a standard. I'll await publication  of the next rev of 6962-bis to
> see if there is an algorithmic description of how the matching is to be
> performed.

I wrote "MAY need to use trial and error", because a TLS client might 
guess the correct certificate first time (i.e. without any "error").

Also, in the (many) cases where there are zero suitably name-constrained 
intermediates in the chain, the SCT or inclusion proof MUST be valid for 
the end-entity certificate.  No trial and error is required when there 
is only 1 possible choice!

The important point is that a TLS client MUST NOT declare that an SCT or 
inclusion proof is _invalid_ until it has attempted to verify that SCT 
or inclusion proof against the end-entity cert _and_ against each of the 
zero or more suitably name-constrained intermediate cert in the 
certificate chain sent by the TLS server.
Do we need to state this point more explicitly in the document?

It doesn't matter if a TLS client chooses to attempt to validate against 
the end-entity cert first or against a suitably name-constrained 
intermediate first, so I don't think 6962-bis needs to mandate the 
checking order.

> Steve
>> #23: How can TLS clients match an SCT to a certificate?
>>
>> Changes (by [email-masked]):
>>
>>   * milestone:   => review
>>
>>
>> Comment:
>>
>>   Fixed by https://github.com/google/certificate-transparency-
>>   rfcs/commit/d71d7707a3eeb5707cf5048c3849b068e477038c
>>
>>   The !ItemExtension field is gone.  When there's a suitably name-
>>   constrained intermediate in the certificate chain, TLS clients may
>> need to
>>   use trial and error to determine which of the certificates in the
>> chain an
>>   SCT or inclusion proof corresponds to.
>>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Mar 2016 11:07:33 -0500

Rob,

> Name-Constrained Intermediate CA).
Sorry. I misunderstood the constrained context of your comment.
> guess the correct certificate first time (i.e. without any "error").
Guess? That's not exactly an algorithmic characterization for how an 
implementer is
supposed to do this, right?
> Also, in the (many) cases where there are zero suitably 
> name-constrained intermediates in the chain, the SCT or inclusion 
> proof MUST be valid for the end-entity certificate.  No trial and 
> error is required when there is only 1 possible choice!
Agreed, and if the text says this clearly, that will be fine.
> The important point is that a TLS client MUST NOT declare that an SCT 
> or inclusion proof is _invalid_ until it has attempted to verify that 
> SCT or inclusion proof against the end-entity cert _and_ against each 
> of the zero or more suitably name-constrained intermediate cert in the 
I though the focus of this issue was a specification  of how a TLS 
client determines to
which cert an SCT applies if the SCT is not embedded in the cert. 
Looking quickly at
Section 9.2, I still do not see text that specifically addresses this topic.

Steve

---

From: Eran Messeri <[email-masked]>
Date: Mon, 7 Mar 2016 12:40:11 +0000

On Wed, Mar 2, 2016 at 4:07 PM, Stephen Kent <[email-masked]> wrote:

>> the end-entity certificate.  No trial and error is required when there is
>> only 1 possible choice!
>>
>> inclusion proof is _invalid_ until it has attempted to verify that SCT or
>> inclusion proof against the end-entity cert _and_ against each of the zero
>> or more suitably name-constrained intermediate cert in the certificate
>> chain sent by the TLS server.
> I though the focus of this issue was a specification  of how a TLS client
> determines to
> which cert an SCT applies if the SCT is not embedded in the cert. Looking
> quickly at
The requirement to suggest at least one way to do so is captured in
https://trac.tools.ietf.org/wg/trans/trac/ticket/155.