I note the following text from the -07 i-D that seems to specify TLS
client behavior:
Section 1
TLS clients can thus require that all certificates they accept as
valid have been logged.
(doe not use 2918 reserved words, but ...)
Section 3
A certificate not
accompanied by an SCT (either for the end-entity certificate or for a
name-constrained intermediate the end-entity certificate chains to)
*MUST NOT be considered compliant by TLS clients*.
Section 3.4
*TLS clients MUST implement all three mechanisms*.
Section 3.4.1
*TLS clients that support the extension SHOULD *send a ClientHello
extension with the appropriate type and empty "extension_data".
*TLS clients SHOULD include *the extension type in the ClientHello,
Section 5.3
in addition to normal validation of the certificate and its chain,
*TLS**
** clients SHOULD validate the 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.
*A TLS client MAY audit the corresponding log *by requesting, and
verifying, a Merkle audit proof for said certificate.* If the TLS**
** client holds an STH that predates the SCT, it MAY, *in the process of
auditing, request a new STH from the log (Section 4.3), then verify
it by requesting a consistency proof (Section 4.4).
*TLS clients MUST reject SCTs whose timestamp* is in the future.
Section 8.1
*Misissued certificates that have not been publicly logged, and thus**
** do not have a valid SCT, will be rejected by TLS clients.*
#74: normative statement of TLS client behavior in Section 3
Comment (by [email protected]):
Describing how the protocol works from the client's POV is _not_ about
client behaviour, it is about the client's understanding of the situation.
How it behaves as a result of that understanding is behaviour.
I propose this should be closed "wontfix".
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
