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 <ietf-pkix@imc.com>.
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
Arenavgen 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]