idnits 2.17.00 (12 Aug 2021) /tmp/idnits46751/draft-bhjl-x509-srv-01.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 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 (July 19, 2016) is 2132 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: 0 errors (**), 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: January 20, 2017 Taughannock Networks 6 July 19, 2016 8 Using a DNS SRV Record to Locate an X.509 Certificate Store 9 draft-bhjl-x509-srv-01 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 January 20, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Certificate Validation . . . . . . . . . . . . . . . . . . . 4 59 6. Certificate use and cacheing . . . . . . . . . . . . . . . . 4 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Certificates service . . . . . . . . . . . . . . . . . . 5 63 8.2. Smimeca service . . . . . . . . . . . . . . . . . . . . . 6 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 X.509 and PGP public keys can be used to encrypt or sign e-mail 71 messages. In order to verify a sender's signature or encrypt an 72 e-mail, the e-mail client needs to locate the appropriate public key. 73 The X.509-based Public Key Infrastructure (PKI) [RFC5280] provides 74 the necessary services to allow for the retrieval of certificates and 75 certificate revocation lists, but lacks the discovery mechanism 76 needed to associate e-mail domains with specific PKI servers. 78 This document specifies an approach that uses a Domain Name System 79 (DNS) Service Record (SRV) that allows mail service providers to 80 advertise the X.509 or PGP certificate store [RFC4387] that contains 81 certificates and certificate revocation lists for their e-mail users. 82 Additionally, this document specifies the appropriate query strings 83 to use when accessing the certificate store. 85 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 86 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in 88 [RFC2119]. 90 2. Service Record Format 92 The general format of a DNS SRV record is documented in [RFC2782] as: 94 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 96 To support the advertisement of an X.509 certificate store, service 97 providers will construct an SRV record with the appropriate 98 parameters, as described in [RFC4387], section 3.2. An example of 99 such an SRV record is: 101 _certificates._tcp 86400 IN SRV 0 0 443 certs.example.com 103 The parameters of the DNS SRV record are set based on the operational 104 needs of the service provider. The DNS SRV record SHOULD be signed 105 via DNSSEC [RFC4033][RFC4034]. The server MUST be an https server 106 and will typically use port 443. The certificate of the https server 107 SHOULD be validated by a DNSSEC signed TLSA record, and MAY also be 108 validated by a certificate authority. 110 3. Certificate Store Queries 112 To retrieve an X.509 S/MIME certificate, the attribute type is "uri", 113 and the URI is constructed using the path described in [RFC4387], 114 Section 3.3, specifically "/certificates/search.cgi". Using the SRV 115 record above to look up a certificate for bob@example.com, the URI 116 would be: 118 https://certs.example.com/certificates/search.cgi?uri=bob%40example.com 120 X.509 certificate stores MUST support the uri attribute MAY support 121 other attributes. 123 To retrieve a PGP certificate, the attribute type is "email", and the 124 URI is constructed using the path described in [RFC4387], 125 Section 3.3, specifically "/pgpkeys/search.cgi". Using the SRV 126 record above to look up a certificate for bob@example.com, the URI 127 would be: 129 https://certs.example.com/pgpkeys/search.cgi?email=bob%40example.com 131 PGP certificate stores MUST support the email attribute and MAY 132 support other attributes. 134 4. Name Matching 136 SMTP [RFC5321] specifies that the local part of a mailbox is 137 interpreted only by the mailbox domain itself. This document does 138 not update or modify that RFC. 140 If a certificate store has no certificate with an e-mail address that 141 matches the uri or email attribute in a retrieval request, but it 142 does have a certificate with an e-mail address that the mailbox 143 domain treats similarly to the requested address, the server MAY 144 return that certificate. The definition of what is sufficiently 145 similar is a matter of local policy, but the intention is that a 146 human correspondent would consider the same person or entity to 147 receive mail at the two addresses. 149 5. Certificate Validation 151 The certificate is returned as a blob of binary data. If multiple 152 certificates are returned, the response is encoded as multipart/ 153 mixed. 155 X509 S/MIME certificates are validated by checking for a signature by 156 a Certificate Authority (CA) that is acceptable to the validating 157 party. This specification defines an additional validation 158 technique. The domain MAY publish validation certificates using TLSA 159 records at the name _smimeca._tcp. The TLSA records MUST have PKIX- 160 TA or DANE-TA usage[RFC7218]. 162 Since the relationship between a domain and its mailbox users is in 163 general unknown to correspondents, a client MUST apply a local policy 164 to decide whether to use a S/MIME certificate validated only by a 165 signing certificate published by the domain. 167 PGP certificates are validated by the PGP web of trust. A domain may 168 endorse the certificates it publishes by signing them with a 169 signature of postmaster@. Since the relationship between a 170 domain and its mailbox users is in general unknown to correspondents. 171 a client MUST apply a local policy to decide whether to use a PGP 172 certificate retrieved from a certificate server. This policy would 173 typically be the same one used to decide whether to use a certificate 174 retrieved from a traditional PGP key server. 176 6. Certificate use and cacheing 178 Clients SHOULD cache responses to queries as advised by http cache 179 headers. This includes both returned certificates, and 404 failures 180 saying that an address (or other search key) has no certificate. 182 S/MIME keys retrieved from the certificate store SHOULD NOT be used 183 for validation of signatures on incoming mail without further 184 validation of the certificate. S/MIME signed mail includes a copy of 185 the signing certificate which, if it can be validated, typically 186 should be used instead. 188 7. Security Considerations 190 DNSSEC signatures on the SRV record and the https server certificate 191 ensure that any keys retrieved by the technique described in this 192 document are the ones published by the domain's management. But 193 since the relationship between a domain and its mailbox users is in 194 general unknown to correspondents, it would be imprudent to assume 195 that such certificates are in fact ones issued to or used by mailbox 196 recipients or to assume that mail encrypted using the certificates 197 will be readable only by the intended recipient. 199 A domain could publish man-in-the-middle certificates that allowed it 200 to decode and read mail, and perhaps re-encrypt it using different 201 certificates used by the recipients. In some cases this would be 202 entirely legitimate, e.g., a financial institution that is required 203 to log all of its employees's correspondence. In other cases, it 204 could be improper surveillance of the contents of users' mail. 205 Identifying or describing the relationship between a domain and its 206 mail users is beyond the scope of this document. 208 8. IANA Considerations 210 [Note to IANA, to be removed prior to publication.] 212 IANA is requested to add two entries to the Service Name and 213 Transport Protocol Port Number Registry. 215 8.1. Certificates service 217 Service Name: certificates 219 Transport Protocol(s): tcp 221 Assignee: IESG 223 Contact: 225 Description: Server for S/MIME and PGP certificates 227 Reference: [this document] 229 Port Number: none 230 Service Code: none 232 Known Unauthorized Uses: none 234 8.2. Smimeca service 236 Service Name: simeca 238 Transport Protocol(s): tcp 240 Assignee: IESG 242 Contact: 244 Description: Authority certificate for S/MIME certificates 246 Reference: [this document] 248 Port Number: none 250 Service Code: none 252 Known Unauthorized Uses: none 254 9. Acknowledgements 256 We thank Wei Chuang, Nicolas Lidzborski, and Andreas Schulze for 257 comments and suggestions. 259 10. Normative References 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, 263 DOI 10.17487/RFC2119, March 1997, 264 . 266 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 267 specifying the location of services (DNS SRV)", RFC 2782, 268 DOI 10.17487/RFC2782, February 2000, 269 . 271 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 272 Rose, "DNS Security Introduction and Requirements", 273 RFC 4033, DOI 10.17487/RFC4033, March 2005, 274 . 276 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 277 Rose, "Resource Records for the DNS Security Extensions", 278 RFC 4034, DOI 10.17487/RFC4034, March 2005, 279 . 281 [RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key 282 Infrastructure Operational Protocols: Certificate Store 283 Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February 284 2006, . 286 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 287 Housley, R., and W. Polk, "Internet X.509 Public Key 288 Infrastructure Certificate and Certificate Revocation List 289 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 290 . 292 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 293 DOI 10.17487/RFC5321, October 2008, 294 . 296 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 297 Conversations about DNS-Based Authentication of Named 298 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 299 2014, . 301 Authors' Addresses 303 Brian Haberman 304 Johns Hopkins University Applied Physics Lab 306 Email: brian@innovationslab.net 308 John Levine 309 Taughannock Networks 310 PO Box 727 311 Trumansburg, NY 14886 313 Phone: +1 831 480 2300 314 Email: standards@taugh.com