idnits 2.17.00 (12 Aug 2021) /tmp/idnits45145/draft-bhjl-x509-srv-02.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 22, 2016) is 2129 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 23, 2017 Taughannock Networks 6 July 22, 2016 8 Using a DNS SRV Record to Locate an X.509 Certificate Store 9 draft-bhjl-x509-srv-02 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 23, 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 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/ 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 applies a local policy to 164 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 can 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 applies 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 would be used instead. 188 7. Security Considerations 190 Certificate queries could be used to try to validate lists of e-mail 191 addresses. This is essentially the same problem that mail servers 192 face with RCPT TO probes, and the same countermeasures would apply, 193 such as rate limiting, blacklisting abusive clients, and returning 194 fake results for non-existent addresses. 196 DNSSEC signatures on the SRV record and the https server certificate 197 ensure that any keys retrieved by the technique described in this 198 document are the ones published by the domain's management. But 199 since correspondents often do not know the relationship between a 200 domain and its mailbox users, it would be imprudent to assume that 201 such certificates are in fact ones issued to or used by mailbox 202 recipients or to assume that mail encrypted using the certificates 203 will be readable only by the intended recipient. 205 A domain could publish man-in-the-middle certificates that allowed it 206 to decode and read mail, and perhaps re-encrypt it using different 207 certificates used by the recipients. In some cases this would be 208 entirely legitimate, e.g., a financial institution that is required 209 to log all of its employees's correspondence. In other cases, it 210 could be improper surveillance of the contents of users' mail. 211 Identifying or describing the relationship between a domain and its 212 mail users is beyond the scope of this document. 214 8. IANA Considerations 216 [Note to IANA, to be removed prior to publication.] 218 IANA is requested to add two entries to the Service Name and 219 Transport Protocol Port Number Registry. 221 8.1. Certificates service 223 Service Name: certificates 225 Transport Protocol(s): tcp 227 Assignee: IESG 229 Contact: 230 Description: Server for S/MIME and PGP certificates 232 Reference: [this document] 234 Port Number: none 236 Service Code: none 238 Known Unauthorized Uses: none 240 8.2. Smimeca service 242 Service Name: simeca 244 Transport Protocol(s): tcp 246 Assignee: IESG 248 Contact: 250 Description: Authority certificate for S/MIME certificates 252 Reference: [this document] 254 Port Number: none 256 Service Code: none 258 Known Unauthorized Uses: none 260 9. Acknowledgements 262 We thank Wei Chuang, Nicolas Lidzborski, and Andreas Schulze for 263 comments and suggestions. 265 10. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, 269 DOI 10.17487/RFC2119, March 1997, 270 . 272 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 273 specifying the location of services (DNS SRV)", RFC 2782, 274 DOI 10.17487/RFC2782, February 2000, 275 . 277 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 278 Rose, "DNS Security Introduction and Requirements", 279 RFC 4033, DOI 10.17487/RFC4033, March 2005, 280 . 282 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 283 Rose, "Resource Records for the DNS Security Extensions", 284 RFC 4034, DOI 10.17487/RFC4034, March 2005, 285 . 287 [RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key 288 Infrastructure Operational Protocols: Certificate Store 289 Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February 290 2006, . 292 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 293 Housley, R., and W. Polk, "Internet X.509 Public Key 294 Infrastructure Certificate and Certificate Revocation List 295 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 296 . 298 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 299 DOI 10.17487/RFC5321, October 2008, 300 . 302 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 303 Conversations about DNS-Based Authentication of Named 304 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 305 2014, . 307 Authors' Addresses 309 Brian Haberman 310 Johns Hopkins University Applied Physics Lab 312 Email: brian@innovationslab.net 314 John Levine 315 Taughannock Networks 316 PO Box 727 317 Trumansburg, NY 14886 319 Phone: +1 831 480 2300 320 Email: standards@taugh.com