idnits 2.17.1 draft-bhjl-x509-srv-03.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 (January 16, 2017) is 2657 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: July 20, 2017 Taughannock Networks 6 January 16, 2017 8 Using a DNS SRV Record to Locate an X.509 Certificate Store 9 draft-bhjl-x509-srv-03 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 July 20, 2017. 37 Copyright Notice 39 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Certificates service . . . . . . . . . . . . . . . . . . 6 63 8.2. Smimeca service . . . . . . . . . . . . . . . . . . . . . 6 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 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 publish an SRV record for the certificates service with the 98 appropriate parameters, as described in [RFC4387], section 3.2. An 99 example of 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 and MAY 121 support 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 document. 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/mixed 153 as described in [RFC4387] section 2. 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]. A validation certificate published by 161 a domain MUST NOT be used to validate certificates other than those 162 with e-mail addresses in that domain. 164 Since the relationship between a domain and its mailbox users is in 165 general unknown to correspondents, a client applies a local policy to 166 decide whether to use a S/MIME certificate validated only by a 167 signing certificate published by the domain. 169 PGP certificates are validated by the PGP web of trust. A domain can 170 endorse the certificates it publishes by signing them with a 171 signature of postmaster@. Since the relationship between a 172 domain and its mailbox users is in general unknown to correspondents. 173 a client applies a local policy to decide whether to use a PGP 174 certificate retrieved from a certificate server. This policy would 175 typically be the same one used to decide whether to use a certificate 176 retrieved from a traditional PGP key server. 178 6. Certificate use and cacheing 180 Clients SHOULD cache responses to queries as advised by http cache 181 headers. This includes both returned certificates, and 404 failures 182 saying that an address (or other search key) has no certificate. 184 S/MIME keys retrieved from the certificate store SHOULD NOT be used 185 for validation of signatures on incoming mail without further 186 validation of the certificate. S/MIME signed mail includes a copy of 187 the signing certificate which, if it can be validated, typically 188 would be used instead. 190 7. Security Considerations 192 Certificate queries could be used to try to validate lists of e-mail 193 addresses. This is essentially the same problem that mail servers 194 face with VRFY, EXPN, and RCPT TO probes, and the same 195 countermeasures would apply, such as rate limiting, blacklisting 196 abusive clients, and returning fake results for non-existent 197 addresses. 199 DNSSEC signatures on the SRV record and the https server certificate 200 ensure that any keys retrieved by the technique described in this 201 document are the ones published by the domain's management. But 202 since correspondents often do not know the relationship between a 203 domain and its mailbox users, it would be imprudent to assume that 204 such certificates are in fact ones issued to or used by mailbox 205 recipients or to assume that mail encrypted using the certificates 206 will be readable only by the intended recipient. 208 A domain could publish man-in-the-middle certificates that allowed it 209 to decode and read mail, and perhaps re-encrypt it using different 210 certificates used by the recipients. In some cases this would be 211 entirely legitimate, e.g., a financial institution that is required 212 to log all of its employees' correspondence. In other cases, it 213 could be intrusive or improper surveillance of the contents of users' 214 mail. Identifying or describing the relationship between a domain 215 and its mail users is beyond the scope of this document. 217 8. IANA Considerations 219 IANA is requested to update two entries in the Service Name and 220 Transport Protocol Port Number Registry. 222 8.1. Certificates service 224 Service Name: certificates 226 Transport Protocol(s): tcp 228 Assignee: IESG 230 Contact: 232 Description: Server for S/MIME and PGP certificates 234 Reference: [this document] 236 Port Number: none 238 Service Code: none 240 Known Unauthorized Uses: none 242 8.2. Smimeca service 244 Service Name: simeca 246 Transport Protocol(s): tcp 248 Assignee: IESG 250 Contact: 252 Description: Per-domain authority certificate for S/MIME certificates 254 Reference: [this document] 256 Port Number: none 258 Service Code: none 260 Known Unauthorized Uses: none 262 9. Acknowledgements 264 We thank Wei Chuang, Nicolas Lidzborski, and Andreas Schulze for 265 comments and suggestions. 267 10. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, 271 DOI 10.17487/RFC2119, March 1997, 272 . 274 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 275 specifying the location of services (DNS SRV)", RFC 2782, 276 DOI 10.17487/RFC2782, February 2000, 277 . 279 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 280 Rose, "DNS Security Introduction and Requirements", 281 RFC 4033, DOI 10.17487/RFC4033, March 2005, 282 . 284 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 285 Rose, "Resource Records for the DNS Security Extensions", 286 RFC 4034, DOI 10.17487/RFC4034, March 2005, 287 . 289 [RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key 290 Infrastructure Operational Protocols: Certificate Store 291 Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February 292 2006, . 294 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 295 Housley, R., and W. Polk, "Internet X.509 Public Key 296 Infrastructure Certificate and Certificate Revocation List 297 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 298 . 300 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 301 DOI 10.17487/RFC5321, October 2008, 302 . 304 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 305 Conversations about DNS-Based Authentication of Named 306 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 307 2014, . 309 Authors' Addresses 311 Brian Haberman 312 Johns Hopkins University Applied Physics Lab 314 Email: brian@innovationslab.net 315 John Levine 316 Taughannock Networks 317 PO Box 727 318 Trumansburg, NY 14886 320 Phone: +1 831 480 2300 321 Email: standards@taugh.com