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 the ICANN 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 EE TA EE CA-1

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 EE TA EE CA-1

9. Augmented 5280 Validation process Verify that the dNSName in the end certificate's subject 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 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 accessLocation URL Validate – Use as trust anchor or validate to configured TA Encrypt & send

12. 问题 ?