Confirm
298
edits
Changes
no edit summary
If there is a mechanism for the client to say what keys have already been validated (thus decreasing the length of the chain a server must send), there may be privacy implications. For instance, if a only small number of sites have their DS records signed by a specific key from .com and the client indicates they have already validated that specific key, another server knows the client has visited one of those sites. There may be a way for a client to instead indicate they have all of the keys for a zone as of a certain time (i.e. "now"), thus eliminating a privacy leak.
== Policies ==
=== Self-signed Certificates ===
For self-signed certificates, the policy is "The certificate chain must contain one self-signed certificate and the DNSSEC chain must be valid and correspond to data in the certificate." A TLSA certificate type of CA must not be used in this case.
=== Untrusted Roots ===
For certificates with a root of trust unknown to the client, a policy could be "The certificate chain must be valid up to the untrusted root and the DNSSEC chain must be valid and correspond to data in the untrusted root." A TLSA certificate type of CA or Public Key must be used in this case. In theory, this policy could be combined with that of self-signed certificates. It may be desirable to separate them for the sake of fine-grained policy control, however.
=== Trusted Roots and DNSSEC ===
For certificates with a known root of trust, the policy is "The certificate chain must be valid and (the DNSSEC chain must be valid or the domain does not require such additional validation)". Currently there is no mechanism to specify whether or not a domain requires DNSSEC validation. In This case any TLSA certificate type may be used.
== DNSSEC Libraries ==
