Network Working Group S. Josefsson Internet-Draft RSA Security Expires: October 18, 2001 April 19, 2001 Internet X.509 Public Key Infrastructure Operational Protocols - DNS draft-josefsson-pkix-dns-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 18, 2001. Distribution of this document is unlimited. Comments and suggestions on this document are encouraged. Comments may be sent to the IETF PKIX mailing list at . Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Domain Name System (DNS) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Josefsson Expires October 18, 2001 [Page 1] Internet-Draft PKIX Operational Protocols - DNS April 2001 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. Table of Contents 1. Introduction and background . . . . . . . . . . . . . . . . 3 1.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Certificate and CRL Repository . . . . . . . . . . . . . . . 4 1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.1 Automatic locating of PKI material for entities . . . . . . 4 1.3.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . 5 2. DNS Conventions . . . . . . . . . . . . . . . . . . . . . . 5 3. Implementation requirements . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . 9 Josefsson Expires October 18, 2001 [Page 2] Internet-Draft PKIX Operational Protocols - DNS April 2001 1. Introduction and background This document specifies the conventions for using the Domain Name System (DNS) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories within the Internet X.509 Public Key Infrastructre. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. 1.1 Model Following is a simplified view of the architectural model assumed by the PKIX specifications. +---+ | C | +------------+ | e | <-------------------->| End entity | | r | Operational +------------+ | t | transactions ^ | | and management | Management | / | transactions | transactions | | | PKI users | C | v | R | -------------------+--+-----------+---------------- | L | ^ ^ | | | | PKI management | | v | entities | R | +------+ | | e | <---------------------| RA | <---+ | | p | Publish certificate +------+ | | | o | | | | s | | | | I | v v | t | +------------+ | o | <------------------------------| CA | | r | Publish certificate +------------+ | y | Publish CRL ^ | | | +---+ Management | transactions | v +------+ | CA | +------+ The components in this model are: End Entity: user of PKI certificates and/or end user system that is the subject of a certificate; Josefsson Expires October 18, 2001 [Page 3] Internet-Draft PKIX Operational Protocols - DNS April 2001 CA: certification authority; RA: registration authority, i.e., an optional system to which a CA delegates certain management functions; 1.2 Certificate and CRL Repository Some CAs mandate the use of on-line validation services, while others distribute CRLs to allow certificate users to perform certificate validation themselves. In general, CAs make CRLs available to certificate users by publishing them in the Directory. The Directory is also the normal distribution mechanism for certificates. However, Directory Services are not available in many parts of the Internet today, and sometimes a full-blown directory service is not necessery or required. The Domain Name System (DNS) (defined in RFC 1034 [1] and RFC 1035 [2]) is a lookup mechanism frequently used on the Internet to look up IP addresses. In RFC 2538 [6] a framework for storing certificates in DNS is specified using the CERT record. 1.3 Motivation Why do we want another PKIX Operational Protocol? 1.3.1 Automatic locating of PKI material for entities Many uses of PKI today are by entities with a name that is equivalent or easily transcribed into a DNS domain name. Examples include server hostnames, server IP addresses and email addresses. Thus clients using this operational protocol will be able to, without pre-configuring, to locate PKI data for entities of whom they have no prior knowledge of. This is important in at least one major application of PKI, secure mail using S/MIME. The FTP and HTTP operational protocols [7] does not address this concern. The FTP and HTTP operational protocols suggests that the URI form of GeneralName should be put on business cards, which is unlikely to be manually entered by a user. It may also open up for a man-in-the-middle attack where a certificate may be replaced in transit, unless security measures are taken in the FTP or HTTP connection and in the domain name resolution. While the LDAP protocol [5] technically is capable of searching for email addresses, the question of how to locate the LDAP server has not been resolved. Several attempts have been made to address this point, though. Some of these attempts are using DNS as well. Josefsson Expires October 18, 2001 [Page 4] Internet-Draft PKIX Operational Protocols - DNS April 2001 1.3.2 Performance DNS queries are typically smaller and require less number of round-trips to transfer a certificate compared to LDAP or FTP/HTTP. This is a concern in mobile and wireless applications. 2. DNS Conventions PKIX Certificates and CRLs stored in DNS CERT records should use the "PKIX" certificate type, as per RFC 2538. However, the DNS "owner name" guidelines for PKIX certificates and CRLs described in RFC 2538 are, for several applications, not adequate. Below we suggest a scheme that may be used in these applications. It should be noted that the RFC 2538 guideliness MAY still be used, and that one of these names MAY be CNAMEs to the other. The RFC 2538 owner name guidelines is not adequate because they (as well as other, similar guidelines) focus on the content of a certificate to determine how it should be stored. This imposes a dilemma for a third party that wishes to locate a certificate for an remote entity (e.g. identified with an mail address) -- they need to know parts of, or all of, the DN of the certificate they want to retrieve. In several PKIX application, with the major example of S/MIME, communicating parties can in general only be assumed to know a limited set of information about the other entity. Such as the mail address or hostname. They do not know apriori the DN of the remote entity. This discussion leads to a new DNS owner name guideline that focus on the entity that will perform lookups of the certificate, rather than the publisher. It is acknowledged that this limits the general usefulness of a certificate directory because a publisher will need to know how a certificate will be used in order to publish it. However, many PKIX applications are in environments when a publisher knows the intent of certificates, e.g. S/MIME, SSL, or IPSEC certificates, and it will be possible to properly select a DNS owner name that matches what a remote entity would query for. This document suggest that the following owner names should be used in the following situations: Josefsson Expires October 18, 2001 [Page 5] Internet-Draft PKIX Operational Protocols - DNS April 2001 Scenario Owner name ------------------------------------------------------------------- S/MIME Certificate Standard translation of RFC 822 email address. Example: A S/MIME certificate for "postmaster@example.org" will use a standard hostname translation of the owner name, i.e. "postmaster.example.org". SSL Certificate Hostname of the SSL server. IPSEC Certificate Hostname of the IPSEC machine, and/or for the in-addr.arpa reverse lookup IP address. CRLs Hostname of the issuing CA. Again, since this is not a generic approach it requires and assumes that the publisher knows the intent of the certificate. In situations where this does not apply, the owner name guidelines of RFC 2538 still apply and SHOULD be used. 3. Implementation requirements A DNS server that is used as a Certificate and/or CRL distribution point within PKIX MUST at least implement the basic DNS protocol from RFC 1035 and the Certificate in DNS (RFC 2538) extension. While the Certificate in DNS extension is part of the Secure DNS suite, Secure DNS is NOT required. Since Certificates and CRLs often are larger than the minimum UDP packet size, servers SHOULD implement EDNS0 (RFC 2671) as discussed in draft-ietf-dnsext-message-size. Servers supporting addition and deletion of certificates or CRLs with Dynamic Updates (RFC 2136) MUST use it together with a suitable authentication mechanism, such as Secure DNS Dynamic Update (RFC 3007). Secure DNS [4] provides trust for data stored in DNS. While certificates and CRLs are signed data, additional trust is normally not required. However, to protect for malicious insertion of still current but superceeded data a client MAY use Secure DNS together with contacting the authoritative server. 4. Security Considerations Since certificates and CRLs are digitally signed, no additional integrity service is necessary. Neither certificates nor CRLs need be kept secret, and anonymous access to certificates and CRLs is generally acceptable. Thus, no privacy service is necessary. Josefsson Expires October 18, 2001 [Page 6] Internet-Draft PKIX Operational Protocols - DNS April 2001 However, clients that retrieve CRLs without some way of verifying the server run the risk of being sent a still current but superceded CRL. DNS caching affects recency of data, and while the time data are retained in DNS caches usually are lower than interval of CRL issuing, a malicious or incorrectly configured DNS server may send a still current but superceded CRL. A client may chose to contact one of the authoritative servers instead of using local DNS caches. Operators of DNS servers should authenticate end entities, CAs and RAs who publish certificates CRLs. However, authentication is not necessary to retrieve certificates and CRLs. Acknowledgement This document have borrowed some text from other PKIX Operational Protocols documents, as well as the PKIX model from the base PKIX document. References [1] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [2] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [4] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [6] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999. [7] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999. Josefsson Expires October 18, 2001 [Page 7] Internet-Draft PKIX Operational Protocols - DNS April 2001 Author's Address Simon Josefsson RSA Security Arenav„gen 29 Stockholm 121 29 Sweden Phone: +46 8 7250914 EMail: sjosefsson@rsasecurity.com Josefsson Expires October 18, 2001 [Page 8] Internet-Draft PKIX Operational Protocols - DNS April 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Josefsson Expires October 18, 2001 [Page 9]