This document appears to be in pretty good shape. I noted a few minor areas for improvement, mostly editorial.
S 1. A relying party (e.g., browser) benefits from CT if it rejects a bogus certificate, i.e., treats it as invalid. An RP is protected from accepting a bogus certificate if that certificate is revoked, and if the RP checks the revocation status of the certificate. (An I would add "directly" after benefits, because, as you note later in this section, it also benefits of CT leads to revocation of a bogus cert. Figure 1: In this diagram, all the left <s are missing. I expect you have a failure to escape. S 2. To make use of forged web site certificates, an adversary must be able to direct a TLS client to a spoofed web site, so that it can present the forged certificate during a TLS handshake. An adversary may achieve this in various ways, e.g., by manipulation of the DNS response sent to a TLS client or via a man-in-the-middle attack. The I'm not sure I would characterize this as a MITM attack, but rather as an active attack on the TLS connection itself. Maybe "by manipulation of the DNS response... or, in the case of an on-path attacker, directly intercepting the TLS connection" "malicious" CA. A nation state also might compromise a CA in another country, to effect issuance of bogus certificates. In this case the Why limit this to "in another country"? This form of attack is also available in the same country. S 3.2.1.1.1. The fact that CT doesn't ensure revocation is a really good point. I think it would be worthwhile to make this point earlier, perhaps in Section 1 where you discuss the basic theory of CT. I'd also expand on this in two ways: - A CA can use OCSP stapling to indefinitely extend the lifetime of a revoked certificate (you observe this in S 3.5) - If a CA is able to pass off deliberate missisuance as accidental misissuance, it can in effect issue a completely bogus cert and keep it live permanently without consequence. S 3.2.2.1. Although there is nothing in IETF, Chrome has announced plans to require CT for certificates with issuance dates after a certain flag day, thus resulting in a gradual phase in, so it's probably worth noting that at least in some cases people are working on this. S 3.3. discussions in Section 3.2 are applicable. Section 3.3 explored the undetected compromise of a CA in the context of attacks designed to issue a bogus certificate that might avoid revocation (because the certificate would appear on distinct certificate paths). As this phrase appears in S 3.3, I think you have a mistake here of some kind. S 4.1.1.1. You seem to have some sort of rendering error where you repeatedly have "(pre )certificate" rather than "(pre-)certificate") S 4.2.1.1. Please expand CCID on first user here. -Ekr
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
