idnits 2.17.1 draft-bhjl-x509-srv-04.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 16, 2018) is 2083 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 17, 2019 Taughannock Networks 6 July 16, 2018 8 Using a DNS SRV Record to Locate an X.509 Certificate Store 9 draft-bhjl-x509-srv-04 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 https://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 17, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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 (https://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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in BCP 88 14 [RFC8174] when, and only when, they appear in all capitals, as 89 shown here. 91 2. Service Record Format 93 The general format of a DNS SRV record is documented in [RFC2782] as: 95 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 97 To support the advertisement of an X.509 certificate store, service 98 providers publish an SRV record for the certificates service with the 99 appropriate parameters, as described in [RFC4387], section 3.2. An 100 example of such an SRV record is: 102 _certificates._tcp 86400 IN SRV 0 0 443 certs.example.com 104 The parameters of the DNS SRV record are set based on the operational 105 needs of the service provider. The DNS SRV record SHOULD be signed 106 via DNSSEC [RFC4033][RFC4034]. The server MUST be an https server 107 and will typically use port 443. The certificate of the https server 108 SHOULD be validated by a DNSSEC signed TLSA record, and MAY also be 109 validated by a certificate authority. 111 3. Certificate Store Queries 113 To retrieve an X.509 S/MIME certificate, the attribute type is "uri", 114 and the URI is constructed using the path described in [RFC4387], 115 Section 3.3, specifically "/certificates/search.cgi". Using the SRV 116 record above to look up a certificate for bob@example.com, the URI 117 would be: 119 https://certs.example.com/certificates/search.cgi?uri=bob%40example.com 121 X.509 certificate stores MUST support the uri attribute and MAY 122 support other attributes. 124 To retrieve a PGP certificate, the attribute type is "email", and the 125 URI is constructed using the path described in [RFC4387], 126 Section 3.3, specifically "/pgpkeys/search.cgi". Using the SRV 127 record above to look up a certificate for bob@example.com, the URI 128 would be: 130 https://certs.example.com/pgpkeys/search.cgi?email=bob%40example.com 132 PGP certificate stores MUST support the email attribute and MAY 133 support other attributes. 135 4. Name Matching 137 SMTP [RFC5321] specifies that the local part of a mailbox is 138 interpreted only by the mailbox domain itself. This document does 139 not update or modify that document. 141 If a certificate store has no certificate with an e-mail address that 142 matches the uri or email attribute in a retrieval request, but it 143 does have a certificate with an e-mail address that the mailbox 144 domain treats similarly to the requested address, the server MAY 145 return that certificate. The definition of what is sufficiently 146 similar is a matter of local policy, but the intention is that a 147 human correspondent would consider the the two addresses to deliver 148 mail to the same person or entity. 150 5. Certificate Validation 152 The certificate is returned as a blob of binary data. If multiple 153 certificates are returned, the response is encoded as multipart/mixed 154 as described in [RFC4387] section 2. 156 X509 S/MIME certificates are validated by checking for a signature by 157 a Certificate Authority (CA) that is acceptable to the validating 158 party. This specification defines an additional validation 159 technique. The domain MAY publish validation certificates using TLSA 160 records at the name _smimeca._tcp. The TLSA records MUST have PKIX- 161 TA or DANE-TA usage[RFC7218]. A validation certificate published by 162 a domain MUST NOT be used to validate certificates other than those 163 with e-mail addresses in that domain. 165 Since the relationship between a domain and its mailbox users is in 166 general unknown to correspondents, a client applies a local policy to 167 decide whether to use a S/MIME certificate validated only by a 168 signing certificate published by the domain. 170 PGP certificates are validated by the PGP web of trust. A domain can 171 endorse the certificates it publishes by signing them with a 172 signature of postmaster@. Since the relationship between a 173 domain and its mailbox users is in general unknown to correspondents. 174 a client applies a local policy to decide whether to use a PGP 175 certificate retrieved from a certificate server. This policy would 176 typically be the same one used to decide whether to use a certificate 177 retrieved from a traditional PGP key server. 179 6. Certificate use and cacheing 181 Clients SHOULD cache responses to queries as advised by http cache 182 headers. This includes both returned certificates, and 404 failures 183 saying that an address (or other search key) has no certificate. 185 S/MIME keys retrieved from the certificate store SHOULD NOT be used 186 for validation of signatures on incoming mail without further 187 validation of the certificate. S/MIME signed mail includes a copy of 188 the signing certificate which, if it can be validated, typically 189 would be used instead. 191 7. Security Considerations 193 Certificate queries could be used to try to validate lists of e-mail 194 addresses. This is essentially the same problem that mail servers 195 face with VRFY, EXPN, and RCPT TO probes, and the same 196 countermeasures would apply, such as rate limiting, blacklisting 197 abusive clients, and returning fake results for non-existent 198 addresses. 200 DNSSEC signatures on the SRV record and the https server certificate 201 ensure that any keys retrieved by the technique described in this 202 document are the ones published by the domain's management. But 203 since correspondents often do not know the relationship between a 204 domain and its mailbox users, it would be imprudent to assume that 205 such certificates are in fact ones issued to or used by mailbox 206 recipients or to assume that mail encrypted using the certificates 207 will be readable only by the intended recipient without further 208 information about the certificates. 210 A domain could publish man-in-the-middle certificates that allowed it 211 to decode and read mail, and perhaps re-encrypt it using different 212 certificates used by the recipients. In some cases this would be 213 entirely legitimate, e.g., a financial institution that is required 214 to log all of its employees' correspondence. In other cases, it 215 could be intrusive or improper surveillance of the contents of users' 216 mail. Identifying or describing the relationship between a domain 217 and its mail users is beyond the scope of this document. 219 8. IANA Considerations 221 IANA is requested to update two entries in the Service Name and 222 Transport Protocol Port Number Registry. 224 8.1. Certificates service 226 Service Name: certificates 228 Transport Protocol(s): tcp 230 Assignee: IESG 232 Contact: 234 Description: Server for S/MIME and PGP certificates 236 Reference: [this document] 238 Port Number: none 240 Service Code: none 242 Known Unauthorized Uses: none 244 8.2. Smimeca service 246 Service Name: simeca 248 Transport Protocol(s): tcp 250 Assignee: IESG 252 Contact: 254 Description: Per-domain authority certificate for S/MIME certificates 256 Reference: [this document] 258 Port Number: none 260 Service Code: none 262 Known Unauthorized Uses: none 264 9. Acknowledgements 266 We thank Wei Chuang, Nicolas Lidzborski, and Andreas Schulze for 267 comments and suggestions. 269 10. Normative References 271 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 272 specifying the location of services (DNS SRV)", RFC 2782, 273 DOI 10.17487/RFC2782, February 2000, 274 . 276 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 277 Rose, "DNS Security Introduction and Requirements", 278 RFC 4033, DOI 10.17487/RFC4033, March 2005, 279 . 281 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 282 Rose, "Resource Records for the DNS Security Extensions", 283 RFC 4034, DOI 10.17487/RFC4034, March 2005, 284 . 286 [RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key 287 Infrastructure Operational Protocols: Certificate Store 288 Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February 289 2006, . 291 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 292 Housley, R., and W. Polk, "Internet X.509 Public Key 293 Infrastructure Certificate and Certificate Revocation List 294 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 295 . 297 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 298 DOI 10.17487/RFC5321, October 2008, 299 . 301 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 302 Conversations about DNS-Based Authentication of Named 303 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 304 2014, . 306 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 307 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 308 May 2017, . 310 Authors' Addresses 312 Brian Haberman 313 Johns Hopkins University Applied Physics Lab 315 Email: brian@innovationslab.net 316 John Levine 317 Taughannock Networks 318 PO Box 727 319 Trumansburg, NY 14886 321 Phone: +1 831 480 2300 322 Email: standards@taugh.com