DNS-centric PKI

1. DNS-centric PKI Sean Turner Russ Housley Tim Polk

2. Problem Space • Peers participating in store and forward protocols (e.g., S/MIME) may not have necessary certificates, or any clue where to obtain them • But they do know about the appropriate host names! So they already rely on the DNS… • Even where protocols supply certificates in-band (e.g., TLS), additional information may be needed to make a trust decision

3. Solution Space • Leverage protections afforded by DNSSEC • Assumes acceptance of theICANN trust anchor for DNSSEC • Otherwise, no simpler than current PKI solution • Assumes a complete chain from the authoritative root zone to the domain of interest • Client interpretation based on policy • As in PKIX, allow relying party to apply its own validation requirements

4. Potential Contents of DNSSEC Entry • Self-Signed CA Certificate • CA certificate issued by a third party • End Entity Certificate

5. Client retrieved a CA certificate • If a Certification Authority (CA) certificate is returned, rather than an end-entity (EE) certificate, use to construct a certification path. • It is a matter of local policy whether the CA certificate can be accepted as a trust anchor (TA) directly, or MUST chain to a currently configured TA. • This implies Self-Signed CA certificates can be used, but clients are NOT required to accept them as a trust anchor. (Depends on local policy.) • Appropriate where protocols provide EE certificate or where end certificates can be looked up by name.

6. Policy Dependent Validation(CA Certificate) • Accept as trust anchor • Configured trust anchor dnssec CA-1 TA dnssec CA-1 EE EE

7. Client retrieves an EE Certificate • If an EE certificate is returned, the certificate is intended for direct use with some application. • It is a matter of local policy whether this EE certificate is accepted as trusted directly, or MUST chain to a currently configured TA.

8. Policy Dependent Validation(EE Certificate) • Use Directly • Configured trust anchor dnssec TA EE CA-1 dnssec EE

9. Augmented 5280 Validation process • Verify that the dNSName in the end certificate'ssubject alternative name extension [RFC5280] is consistent with the expected host name. • If the certificate contains a critical External Key Usage (EKU) or Key Usage (KU) extension [RFC5280], verify that the key usages are consistent with this application.

10. TLS Example • The TLS client request the CERT RR as it looks up the IP address in the DNS • If the certificate that is provided in the TLS handshake matches the one retrieved from DNSSEC • Depending on local policy, client can accept the certificate as a trusted certificate for that site or build a chain to a configured trust anchor. • If a CA certificate is returned in the TLS handshake, the TLS client verifies that the TLS server certificate was issued under that CA • Whether the CA certificate is accepted as a trust anchor or an intermediate certificate is a local policy decision.

11. S/MIME Example • Want to send encrypted email to john.doe@example.com • Request DNS records for example.com • Receives a CA certificate which includes an SIA asserting id-ad-caRepositoryquery for certificates issued to john.doe@example,com protocol implied by the accessLocationURL • Validate • Use as trust anchor or validate to configured TA • Encrypt & send

12. 问题 ?