DKG, Thanks for the review and detailed comments.
In response to your comments I made the fallowing changes: - added reference to the gossip doc in the introduction - removed all use of the term "doppelganger"- adopted the terminology you used in your example: CA-A and CA-B (same name, same key pair) and bogus cert X.
- revised text to note that the two CA instances that appear as issuer of the bogus EE cert need not have different trust anchor ancestors.
- revised text to include a scenario in which one CA is compromised and caused to issue the bogus cert (which is logged and, maybe revoked) while the second instance of the CA is malicious and has a parent that may be malicious or may have been tricked or attacked, etc.
- revised the title of 3.3 to reflect the broader range of scenarios as per your example
I did not explore the potential for logs to discriminate wrt the certs they log. I also did not discuss possible enhancements to the Monitor function to detect AIA manipulation and the like.
I did not discuss in greater detail the non-standard mechanisms that may be used by browsers to deal with revocation. I think it suffices to note that such mechanisms may use cert hashes or keys to identify revoked certs, and that such approaches are not path-specific.
I retained the discussion of how OCSP or CRLs and AIA extensions might be used to prevent a browser from learning about the true revocation status of a bogus cert. Yes, these are not vulnerabilities of CT per se, but they are part of the standards-based ecosystem in which CT operates.
I have attached a PDF showing the revised text in 3.3, where most of the changes were made.
Steve
threat analysis 3.3 revisions.pdf
Description: Adobe PDF document
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
