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 protected]):
* 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 protected]
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.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
