Ben,
On 6 July 2015 at 15:50, Stephen Kent<[email protected]> wrote:
I note the following text from the -07 draft that appear to specify TLS
client behavior:
Section 1
TLS clients can thus require that all certificates they accept as valid
have been logged.
This doesn't specify anything, just notes that clients can do it (if
they want to, obviously).
the term disingenuous comes to mind here.
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.
Again, no behaviour is specified. The client is required to understand
that the cert is not in conformance with CT. It can do what it wants
with that understanding.
This seems an attempt to have your cake and eat it too. We generally do not
define "compliance" when there is no specified response to non-compliance.
We do sometimes define compliance so that non-compliant data or behavior is
ruled out of scope. But, that doesn't sem to be the intent here.
But, in the spirit of compromise, how about:
A certificate not accompanied by an SCT is not CT compliant.
Section 3.4
TLS clients MUST implement all three mechanisms.
What we ruled out of scope is how clients behave in terms of user
interface, et al. Clearly a protocol document has to describe how the
protocol works. That is not the kind of behaviour we ruled out.
OK. This is describing an extension of functionality for TLS to make use of
CT. As such it updates (pick a version) of TLS. The headers for this
doc need to state that the RFC(s) in question are updated by this doc. It
also is customary to coordinate with the chairs of the WG responsible for
the specs being updated.
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, but if the
session is resumed, the TLS server is not expected to process it or
include the extension in the ServerHello.
See above.
same as my response for 3.4
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.
And again.
How about:
A TLS client claiming conformance with CT MUST be capable of performing
the following
checks on a certificate accompanied by an SCT:
- Matching the SCT to the certificate. This entails <update to
include the hash
that Rob is adding to the SCT>
- Verifying the signature on the SCT. The signature on the SCT is
verified using
the public key for the log identified by the logID SCT.
A TLS client claiming conformance with CT MUST be configurable (by the
user or local
administrator) to perform these checks, or not
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
