idnits 2.17.00 (12 Aug 2021) /tmp/idnits54850/draft-turner-dnssec-centric-pki-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2010) is 4226 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5750 (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Housley 2 Internet Draft Vigil Security 3 Intended Status: Standards Track T. Polk 4 Expires: April 18, 2011 NIST 5 S. Turner 6 IECA 7 October 18, 2010 9 DNSSEC-centric PKI 10 draft-turner-dnssec-centric-pki-00.txt 12 Abstract 14 This draft is input to the KIDNS discussion. The procedures defined 15 herein provide a general Public Key Infrastructure (PKI) mechanism 16 that leverages DNSSEC. This is compatible with RFC 5280. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may contain material 22 from IETF Documents or IETF Contributions published or made publicly 23 available before November 10, 2008. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 18, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 1. Introduction 60 This draft is not to be construed as direction from I*. It is the 61 output of an actual "interim" Bar BoF held at conference room H 62 located in Fairfax, Virginia after the IAB/IESG OAM workshop on 2010- 63 10-13. 65 Certification Authorities (CAs) take great care to ensure that the 66 private key holder is associated with the domain name contained in 67 the certificate. DNSSEC [RFC4033][RFC4034][RFC4035] offers an 68 opportunity to eliminate complicated off-line processes. This 69 relationship can be easily demonstrated by having the zone 70 administrator for the domain name in question post the certificate 71 [RFC5280] in the DNS and digitally sign the resulting zone. 73 With the following hierarchy: 75 +-------------+ 76 | example.com | 77 +-------------+ 78 / \ 79 +-----------------+ +-----------------+ 80 | foo.example.com | | bar.example.com | 81 +-----------------+ +-----------------+ 83 Administrators of foo.example.com and bar.example.com can choose to 84 either trust the root (i.e., the signer of example.com) or another 85 entity that they have included in the DNS entry they control. 87 1.1. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Procedures 95 Perform a DNSSEC retrieval on the domain name, verifying the chain of 96 trust to a locally configured DNSSEC trust anchor. 98 If a Certification Authority (CA) certificate is returned, rather 99 than an end-entity (EE) certificate, construct a certification path. 100 It is a matter of local policy whether the CA certificate is accepted 101 as a trust anchor (TA) directly, or MUST chain to a currently 102 configured TA. To differentiate CA certificates from EE 103 certificates, the CA certificate MUST include basic constraints 104 extension and the cA boolean MUST be set to true [RFC5280]. 106 If the application provides an EE certificate (e.g., Transport Layer 107 Security (TLS)) issued by this CA certificate, this means only 108 obtaining a Certificate Revocation List (CRL). If no EE certificate 109 is available (e.g., Secure Multipurpose Internet Mail Extensions 110 (S/MIME)), then follow the Subject Information Access (SIA) extension 111 to obtain other certificates. SHOULD be no more than one hop to the 112 EE certificate. 114 If an EE certificate is returned, the certificate is intended for 115 direct use with some application. As above, it is a matter of local 116 policy whether this EE certificate is accepted as trusted directly, 117 or MUST chain to a currently configured TA. 119 Verify that the dNSName in the certificate's subject alternative name 120 extension [RFC5280] is consistent with the expected host name. 122 If the certificate contains a critical External Key Usage (EKU) or 123 Key Usage (KU) extension [RFC5280], verify that the key usages are 124 consistent with this application. 126 3. Examples 128 For S/MIME [RFC5750][RFC5751], the originator wants to send to a 129 signed and encrypted email. (For signatures, the originator does not 130 need the recipient's certificate.) To encrypt the message, the 131 originator needs the recipient's key agreement or key transport 132 certificate. To obtain the recipients certificate, the originator 133 composes the email, selects sign and encrypt, and hit send. The mail 134 client/DNSSEC client reviews the local store and determines that no 135 certificate is available. The mail client then queries the DNS to 136 determine whether certificates are available for that domain. 138 If a CERT resource record (RR) [RFC4398] is available, the mail 139 client examines the certificate to determine if it is a CA 140 certificate or end certificate. For domains with multiple users, the 141 certificate would be a CA certificate and would include a SIA 142 extension [RFC5280]. The mail client follows the URL in an access 143 description that asserts id-ad-caRepository, using the protocol 144 implied by the accessLocation URL. For example, the mail client can 145 query the repository for certificates issued to john.doe@example.com. 146 If an appropriate certificate is available (and validates according 147 to local policy), the client can encrypt the message. The originator 148 includes their own certificates in the message, so this process is 149 not required to validate or decrypt the original message or for a 150 response. 152 For TLS [RFC5246], when the TLS looks up the IP address in the DNS it 153 can also request the CERT RR. If the certificate that is provided in 154 the TLS handshake matches the one retrieved from DNSSEC, then the 155 client can accept it as a trusted certificate for that site, provided 156 local policy allows this. If the CA certificate is returned in the 157 TLS handshake, the TLS client can verify that the TLS server 158 certificate was issued under that CA. 160 For IPsec [RFC4301], the model is similar to TLS. 162 4. Security Considerations 164 Like [RFC5280], trust and revocation configuration decisions will 165 affect the security of the system. 167 When CA certificates are returned, the proposed solution assumes that 168 the entire CA certificate is returned. For EE certificates, a hash 169 could be returned instead of the entire certificate. 171 Need to say something caching versus revocation for optimization. 173 5. IANA Considerations 175 None 177 6. Acknowledgements 179 We'd like to thank the lovely Carly for bringing the libations during 180 the "interim" Bar BoF. In addition, we'd like to thank Yuengling, 181 Anheuser-Busch, and Samuel Adams for all of their efforts. 183 7. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1997. 188 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 189 Rose, "DNS Security Introduction and Requirements", RFC 4033, March 190 2005. 192 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 193 Rose, "Resource Records for the DNS Security Extensions", RFC 4034, 194 March 2005. 196 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 197 Rose, "Protocol Modifications for the DNS Security Extensions", RFC 198 4035, March 2005. 200 [RFC4301] Kent, S., and K. Seo, " Security Architecture for the 201 Internet Protocol", RFC 4301, December 2005. 203 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 204 System (DNS)", RFC 4398, March 2006. 206 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 207 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 209 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. Housley, 210 R., and W. Polk, "Internet X.509 Public Key Infrastructure 211 Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, 212 May 2008. 214 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 215 Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, 216 January 2010. 218 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 219 Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 220 5751, January 2010. 222 Authors' Addresses 224 Russell Housley 225 Vigil Security, LLC 226 918 Spring Knoll Drive 227 Herndon, VA 20170 228 USA 230 EMail: housley@vigilsec.com 232 Tim Polk 233 National Institute of Standards and Technology 234 100 Bureau Drive, Mail Stop 8930 235 Gaithersburg, MD 20899-8930 236 USA 238 Email: tim.polk@nist.gov 240 Sean Turner 241 IECA, Inc. 242 3057 Nutley Street, Suite 106 243 Fairfax, VA 22031 244 USA 246 EMail: turners@ieca.com