#99: Clearer definition of when a certificate is CT-compliant needed
Changes ([email protected]):
* status: new => closed
* resolution: => needs-review
Comment:
Propose this ticket be closed (Fixed) as the term 'compliant' is now used
consistently throughout the text to mean 'compliant with the RFC'.
For example, seehttps://tools.ietf.org/html/draft-ietf-trans-
rfc6962-bis-10#section-9.2:
"By validating SCTs, TLS clients can thus determine whether
certificates are compliant. A certificate not accompanied by a valid
SCT MUST NOT be considered compliant by TLS clients.".
I find the term "complaint" to not be helpful. As I noted in my reply to
Melinda re issue #79, the use of this term in the description
of some aspects of client behavior seems ambiguous. Adding
this new term does not clarify client behavior options. What is needed
is a statement about what a client is required to do, e.g., when a
TLS server provides an SCT, but the SCT is invalid (e.g., sig fails
or a timestamp in the future). Also, if there are multiple SCTs, there
needs to be a statement about whether a client SHOULD require all to be
valid
(presumably not a good idea), or if a client is expected to accept the
cert if any SCT can be validated, or what. This may be beyond the scope of
issue 99, but it illustrates the gaps that need to be addressed if we are
to avoid ambiguity in the specs. I suggest this is best handled by moving
the description of client requirements to a separate doc, so that this doc
can focus on the log and avoid problems of the sort noted here.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
