I started to review the redaction draft to determine current state, but realized that it isn't clear we have a common baseline from which to start any review. I've put together a few statements that I think are true, but would like to see if others agree.
1) A registered domain is a label plus a registration suffix, which is frequently the TLD. The existence (or non-existence) of a registered domain is public information. Rationale: The zone files for all ICANN gTLDs, are available for download. While some ccTLDs don't offer similar service, the basic registered/registerable domain should not be considered private information. 2) Logging certificates to a CT log is optional. An unlogged certificate may not be accepted by some clients or relying parties, but is not a mis-issued certificate. Rationale: While some might want to see 100% logging, it is clear there is not currently support for making it mandatory. 3) Split horizon DNS exists as does delegation to private name servers. This means that names that are unique in the global namespace might not be resolvable from the public Internet. Rationale: Many TLDs allow DNS name servers to have addresses in reserved IP ranges that are not designated as globally unique (e.g. in 10.0.0.0/8). Even if the TLD does not, subordinate domain of registered domains may have such. Even if using public IP addresses, network ACLs may prevent access. 4) Given a full certificate, it must be possible to deterministically reconstruct the precertificate. Rationale: Without this, it becomes impossible to determine if a signature of a precertificate matches the final certificate. 5) Given a precertificate and full certificate, it should be possible to confirm the full certificate is the only viable match for the precertificate. Rationale: If multiple different full certificates could reasonably match a single precertificate, then it becomes trivial to issue "hidden" certificates. 6) Given a precertificate and full certificate, it should not be possible to (re)construct other full certificates given only their precertificates. Rationale: Leak/discovery of a single full certificate should not cause a system collapse. 7) The only entity that knows if a certificate for their domain was not supposed to be issued is entity who was the domain registrant at the time of issuance. Rationale: While others can guess based on heuristics, only the registrant can say with authority "I think this was unauthorized" 8) The only way to get the content of a full certificate is to have a full certificate. Rationale: An alternative option is to have some sort of escrow key that can "unlock" a precertificate. This quickly turns into 'where do we keep the escrow key?' and 'who gets to access the escrow key?'. If there is no such thing, then these questions don't exist. Do others agree that these are true and can be used as givens for reviewing any proposed designs? Thanks, Peter _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
