idnits 2.17.00 (12 Aug 2021) /tmp/idnits46434/draft-bhjl-x509-srv-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 29, 2016) is 2273 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Haberman 3 Internet-Draft JHU APL 4 Intended status: Standards Track J. Levine 5 Expires: September 1, 2016 Taughannock Networks 6 February 29, 2016 8 Using a DNS SRV Record to Locate an X.509 Certificate Store 9 draft-bhjl-x509-srv-00.txt 11 Abstract 13 This document describes a method to allow parties to locate X.509 14 certificate stores with Domain Name System Service records in order 15 to retrieve certificates and certificate revocation lists. The 16 primary purpose of such retrievals is to facilitate the association 17 of X.509 and PGP public keys with e-mail addresses to allow for 18 encrypted e-mail exchanges. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 1, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Service Record Format . . . . . . . . . . . . . . . . . . . . 2 56 3. Certificate Store Queries . . . . . . . . . . . . . . . . . . 3 57 4. Name Matching . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Certificate Validation . . . . . . . . . . . . . . . . . . . 4 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 X.509 and PGP public keys can be used to encrypt or sign e-mail 68 messages. In order to verify a sender's signature or encrypt an 69 e-mail, the e-mail client needs to locate the appropriate public key. 70 The Internet Public Key Infrastructure (PKI) provides the necessary 71 services to allow for the retrieval of certificates and certificate 72 revocation lists, but lacks the discovery mechanism needed to 73 associate e-mail domains with specific PKI servers. 75 This document specifies an approach that uses a Domain Name System 76 (DNS) Service Record (SRV) that allows mail service providers to 77 advertise the X.509 certificate store [RFC4387] that contains 78 certificates and certificate revocation lists for their e-mail users. 79 Additionally, this document specifies the appropriate query strings 80 to use when accessing the certificate store. 82 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 83 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described in 85 [RFC2119]. 87 2. Service Record Format 89 The general format of a DNS SRV record is documented in [RFC2782] as: 91 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 93 To support the advertisement of an X.509 certificate store, service 94 providers will construct an SRV record with the appropriate 95 parameters, as described in [RFC4387], section 3.2. An example of 96 such an SRV record is: 98 _certificates._tcp 86400 IN SRV 0 0 443 certs.example.com 100 The parameters of the DNS SRV record are set based on the operational 101 needs of the service provider. The DNS SRV record MUST be signed via 102 DNSSEC [RFC4033][RFC4034]. The server MUST be an https server and 103 will typically use port 443. The certificate of the https server 104 MUST be validated by a DNSSEC signed TLSA record, and MAY also be 105 validated by a certificate authority. 107 3. Certificate Store Queries 109 To retrieve an X.509 S/MIME certificate, the attribute type is "uri", 110 and the URI is constructed using the path described in [RFC4387], 111 Section 3.3, specifically "/certificates/search.cgi". Using the SRV 112 record above to look up a certificate for someuser@example.com, the 113 URI would be: 115 https://certs.example.com/certificates/search.cgi?uri=someuser%40example.com 117 X.509 certificate stores MUST support the uri attribute MAY support 118 other attributes. 120 To retrieve a PGP certificate, the attribute type is "email", and the 121 URI is constructed using the path described in [RFC4387], 122 Section 3.3, specifically "/pgpkeys/search.cgi". Using the SRV 123 record above to look up a certificate for someuser@example.com, the 124 URI would be: 126 https://certs.example.com/pgpkeys/search.cgi?email=someuser%40example.com 128 PGP certificate stores MUST support the email attribute MAY support 129 other attributes. 131 4. Name Matching 133 SMTP [RFC5321] specifies that the local part of a mailbox is 134 interpreted only by the mailbox domain itself. This document does 135 not update or modify that RFC. 137 If a certificate store has no certificate with an e-mail address that 138 matches the uri or email attribute in a retrieval request, but it 139 does have a certificate with an e-mail address that the mailbox 140 domain treats similarly to the requested address, the server MAY 141 return that certificate. The definition of what is sufficiently 142 similar is a matter of local policy, but the intention is that a 143 human correspondent would consider the same person or entity to 144 receive mail at the two addresses. 146 5. Certificate Validation 148 The certificate is returned as a blob of binary data. If multiple 149 certificates are returned, the response MUST be encoded as multipart/ 150 mixed. 152 X509 S/MIME certificates have are validated by checking for a 153 signature by a Certificate Authority (CA) that is acceptable to the 154 validating party. This specification defines an additional 155 validation technique. The domain MAY publish validation certificates 156 using TLSA records at the name _smime._tcp. The TLSA records MUST 157 have PKIX-TA or DANE-TA usage[RFC7218]. 159 Since the relationship between a domain and its mailbox users is in 160 general unknown to correspondents, a client MUST apply a local policy 161 to decide whether to use a S/MIME certificate validated only by a 162 signing certificate published by the domain. 164 PGP certificates are validated by the PGP web of trust. A domain may 165 endorse the certificates it publishes by signing them with a 166 signature of postmaster@. Since the relationship between a 167 domain and its mailbox users is in general unknown to correspondents. 168 a client MUST apply a local policy to decide whether to use a PGP 169 certificate retrieved from a certificate server. This policy would 170 typically be the same one used to decide whether to use a certificate 171 retrieved from a traditional PGP key server. 173 6. Security Considerations 175 DNSSEC signatures on the SRV record and the https server certificate 176 ensure that any keys retrieved by the technique described in this 177 document are the ones published by the domain's management. But 178 since the relationship between a domain and its mailbox users is in 179 general unknown to correspondents, it would be imprudent to assume 180 that such certificates are in fact ones issued to or used by mailbox 181 recipients or to assume that mail encrypted using the certificates 182 will be readable only by the intended recipient. 184 A domain could publish man-in-the-middle certificates that allowed it 185 to decode and read mail, and perhaps re-encrypt it using different 186 certificates used by the recipients. In some cases this would be 187 entirely legitimate, e.g., a financial institution that is required 188 to log all of its employees's correspondence. In other cases, it 189 could be improper surveillance of the contents of users' mail. 190 Identifying or describing the relationship between a domain and its 191 mail users is beyond the scope of this document. 193 7. IANA Considerations 195 [Note to IANA, to be removed prior to publication.] 197 IANA is requested to add one entry to the Service Name and Transport 198 Protocol Port Number Registry. The service name is "smime"", with no 199 associated port numbers. (more here) 201 8. Acknowledgements 203 9. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, 207 DOI 10.17487/RFC2119, March 1997, 208 . 210 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 211 specifying the location of services (DNS SRV)", RFC 2782, 212 DOI 10.17487/RFC2782, February 2000, 213 . 215 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 216 Rose, "DNS Security Introduction and Requirements", 217 RFC 4033, DOI 10.17487/RFC4033, March 2005, 218 . 220 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 221 Rose, "Resource Records for the DNS Security Extensions", 222 RFC 4034, DOI 10.17487/RFC4034, March 2005, 223 . 225 [RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key 226 Infrastructure Operational Protocols: Certificate Store 227 Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February 228 2006, . 230 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 231 DOI 10.17487/RFC5321, October 2008, 232 . 234 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 235 Conversations about DNS-Based Authentication of Named 236 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 237 2014, . 239 Authors' Addresses 241 Brian Haberman 242 Johns Hopkins University Applied Physics Lab 244 Email: brian@innovationslab.net 246 John Levine 247 Taughannock Networks 248 PO Box 727 249 Trumansburg, NY 14886 251 Phone: +1 831 480 2300 252 Email: standards@taugh.com