Rob,
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?
Sorry. I misunderstood the constrained context of your comment.
"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").
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
certificate chain sent by the TLS server.
Do we need to state this point more explicitly in the document?
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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
