Melinda,
#76: Normative client behavior specified in Section 3.4
Changes ([email protected]):
* owner:[email protected] =>
[email protected]
* status: reopened => new
Comment:
Propose this ticket be closed (fixed) as we've added the following text
(section 9.2):
"However, specifying the TLS clients' behavior once compliance or non-
compliance has been determined (for example, whether a certificate should
be rejected due to the lack of valid SCTs) is outside the scope of this
document."
I think the wording here is still imprecise. For example, the text in 9.2
says "TLS clientsMUST reject SCTs whose timestamp is in the future." But
this, combined with the text above, does not say that a TLS client SHOULD
treat a cert as invalid is it contains (or is associated with) an SCT that
is "rejected." Is this ambiguity intentional? Also, the term
"compliance" seems
needlessly vague here.
My colleagues plan to post a proposed client requirements spec (focusing on
browsers and browser vendors) later this week. It tries to be more explicit
about this and other client behaviors (required and optional).
I also think that the text on SCT validity is quite clear:
"TLS clients SHOULD validate each SCT by computing the signature input
from the SCT data as well as the certificate and verifying the signature,
using the corresponding log's public key."
So not sure what can be added, unless Steve Kent points to the problematic
wording in draft 10.
The following problematic comments re client behavior (wrt SCTs) appear
in -10
The intent is that eventually clients would refuse to honor
certificates that do not appear in a log, effectively forcing CAs to
add all issued certificates to the logs.
TLS clients can thus requirethat all
certificates they accept as valid are accompanied by signed
timestamps.
Sincecertificates may not be accepted by TLS clients unless logged ...
In addition, if TLS clients will not accept unlogged certificates ...
certificates that have not been publicly logged, and thus
do not have a valid SCT, are not considered compliant (so TLS clients
may decide, for example, to reject them).
------------------------------------------------------------------------
These statements do not literally mandate client behavior, but they
expressing intent which could easily be interpreted as client behavior
specs.
Steve
------------------------------------------------------------------------
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
