draft-ietf-dnsext-rfc2538bis.txt   rfc4398.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Request for Comments: 4398 March 2006
Obsoletes: 2538 (if approved) Obsoletes: 2538
Expires: September 2, 2006 Category: Standards Track
Storing Certificates in the Domain Name System (DNS) Storing Certificates in the Domain Name System (DNS)
draft-ietf-dnsext-rfc2538bis-10
Status of this Memo
By submitting this Internet-Draft, each author represents that any Status of This Memo
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 September 2, 2006. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Cryptographic public keys are frequently published, and their Cryptographic public keys are frequently published, and their
authenticity is demonstrated by certificates. A CERT resource record authenticity is demonstrated by certificates. A CERT resource record
(RR) is defined so that such certificates and related certificate (RR) is defined so that such certificates and related certificate
revocation lists can be stored in the Domain Name System (DNS). revocation lists can be stored in the Domain Name System (DNS).
This document obsoletes RFC 2538. This document obsoletes RFC 2538.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3 2. The CERT Resource Record ........................................3
2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4 2.1. Certificate Type Values ....................................4
2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 6 2.2. Text Representation of CERT RRs ............................6
2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. X.509 OIDs .................................................6
3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 7 3. Appropriate Owner Names for CERT RRs ............................7
3.1. Content-Based X.509 CERT RR Names . . . . . . . . . . . . 8 3.1. Content-Based X.509 CERT RR Names ..........................8
3.2. Purpose-Based X.509 CERT RR Names . . . . . . . . . . . . 9 3.2. Purpose-Based X.509 CERT RR Names ..........................9
3.3. Content-Based OpenPGP CERT RR Names . . . . . . . . . . . 9 3.3. Content-Based OpenPGP CERT RR Names ........................9
3.4. Purpose-Based OpenPGP CERT RR Names . . . . . . . . . . . 10 3.4. Purpose-Based OpenPGP CERT RR Names .......................10
3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX . . . . . 10 3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
4. Performance Considerations . . . . . . . . . . . . . . . . . . 10 4. Performance Considerations .....................................11
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Contributors ...................................................11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements ...............................................11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations ........................................12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations ............................................12
9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 13 9. Changes since RFC 2538 .........................................13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References ....................................................14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References .....................................14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References ...................................15
Appendix A. Copying Conditions . . . . . . . . . . . . . . . . . 15 Appendix A. Copying Conditions ...................................16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
Public keys are frequently published in the form of a certificate, Public keys are frequently published in the form of a certificate,
and their authenticity is commonly demonstrated by certificates and and their authenticity is commonly demonstrated by certificates and
related certificate revocation lists (CRLs). A certificate is a related certificate revocation lists (CRLs). A certificate is a
binding, through a cryptographic digital signature, of a public key, binding, through a cryptographic digital signature, of a public key,
a validity interval and/or conditions, and identity, authorization, a validity interval and/or conditions, and identity, authorization,
or other information. A certificate revocation list is a list of or other information. A certificate revocation list is a list of
certificates that are revoked, and of incidental information, all certificates that are revoked, and of incidental information, all
skipping to change at page 5, line 42 skipping to change at page 5, line 43
and a zero-length URL are meaningless and invalid. and a zero-length URL are meaningless and invalid.
The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect". The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".
These types MUST be used when the content is too large to fit in the These types MUST be used when the content is too large to fit in the
CERT RR and MAY be used at the implementer's discretion. They SHOULD CERT RR and MAY be used at the implementer's discretion. They SHOULD
NOT be used where the DNS message is 512 octets or smaller and could NOT be used where the DNS message is 512 octets or smaller and could
thus be expected to fit a UDP packet. thus be expected to fit a UDP packet.
The URI private type indicates a certificate format defined by an The URI private type indicates a certificate format defined by an
absolute URI. The certificate portion of the CERT RR MUST begin with absolute URI. The certificate portion of the CERT RR MUST begin with
a NUL-terminated URI [10] and the data after the NUL is the private a null-terminated URI [10], and the data after the null is the
format certificate itself. The URI SHOULD be such that a retrieval private format certificate itself. The URI SHOULD be such that a
from it will lead to documentation on the format of the certificate. retrieval from it will lead to documentation on the format of the
Recognition of private certificate types need not be based on URI certificate. Recognition of private certificate types need not be
equality but can use various forms of pattern matching so that, for based on URI equality but can use various forms of pattern matching
example, subtype or version information can also be encoded into the so that, for example, subtype or version information can also be
URI. encoded into the URI.
The OID private type indicates a private format certificate specified The OID private type indicates a private format certificate specified
by an ISO OID prefix. The certificate section will start with a one- by an ISO OID prefix. The certificate section will start with a
octet unsigned OID length and then a BER-encoded OID indicating the one-octet unsigned OID length and then a BER-encoded OID indicating
nature of the remainder of the certificate section. This can be an the nature of the remainder of the certificate section. This can be
X.509 certificate format or some other format. X.509 certificates an X.509 certificate format or some other format. X.509 certificates
that conform to the IETF PKIX profile SHOULD be indicated by the PKIX that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
type, not the OID private type. Recognition of private certificate type, not the OID private type. Recognition of private certificate
types need not be based on OID equality but can use various forms of types need not be based on OID equality but can use various forms of
pattern matching such as OID prefix. pattern matching such as OID prefix.
2.2. Text Representation of CERT RRs 2.2. Text Representation of CERT RRs
The RDATA portion of a CERT RR has the type field as an unsigned The RDATA portion of a CERT RR has the type field as an unsigned
decimal integer or as a mnemonic symbol as listed in Section 2.1, decimal integer or as a mnemonic symbol as listed in Section 2.1,
above. above.
skipping to change at page 9, line 14 skipping to change at page 9, line 13
recommended, in priority order, would be recommended, in priority order, would be
1. john-doe.com, 1. john-doe.com,
2. www.secure.john-doe.com, and 2. www.secure.john-doe.com, and
3. Doe.com.xy. 3. Doe.com.xy.
Example 2: An X.509v3 certificate is issued to /CN=James Hacker/ Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a) L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
(c) string "James Hacker <hacker@mail.widget.foo.example>". The (c) string "James Hacker <hacker@mail.widget.foo.example>". The
storage locations recommended, in priority order, would be storage locations recommended, in priority order, would be
1. widget.foo.example, 1. widget.foo.example,
2. 201.13.251.10.in-addr.arpa, and 2. 201.13.251.10.in-addr.arpa, and
3. hacker.mail.widget.foo.example. 3. hacker.mail.widget.foo.example.
3.2. Purpose-Based X.509 CERT RR Names 3.2. Purpose-Based X.509 CERT RR Names
Due to the difficulty for clients that do not already possess a Due to the difficulty for clients that do not already possess a
certificate to reconstruct the content-based owner name, purpose- certificate to reconstruct the content-based owner name,
based owner names are recommended in this section. Recommendations purpose-based owner names are recommended in this section.
for purpose-based owner names vary per scenario. The following table Recommendations for purpose-based owner names vary per scenario. The
summarizes the purpose-based X.509 CERT RR owner name guidelines for following table summarizes the purpose-based X.509 CERT RR owner name
use with S/MIME [17], SSL/TLS [13], and IPsec [14]: guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
Scenario Owner name Scenario Owner name
------------------ ---------------------------------------------- ------------------ ----------------------------------------------
S/MIME Certificate Standard translation of an RFC 2822 email S/MIME Certificate Standard translation of an RFC 2822 email
address. Example: An S/MIME certificate for address. Example: An S/MIME certificate for
"postmaster@example.org" will use a standard "postmaster@example.org" will use a standard
hostname translation of the owner name, hostname translation of the owner name,
"postmaster.example.org". "postmaster.example.org".
TLS Certificate Hostname of the TLS server. TLS Certificate Hostname of the TLS server.
skipping to change at page 11, line 34 skipping to change at page 11, line 44
6. Acknowledgements 6. Acknowledgements
Thanks to David Shaw and Michael Graff for their contributions to Thanks to David Shaw and Michael Graff for their contributions to
earlier works that motivated, and served as inspiration for, this earlier works that motivated, and served as inspiration for, this
document. document.
This document was improved by suggestions and comments from Olivier This document was improved by suggestions and comments from Olivier
Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M. Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin, Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
Weiler, Florian Weimer, and the IANA. No doubt the list is Weiler, and Florian Weimer. No doubt the list is incomplete. We
incomplete. We apologize to anyone we left out. apologize to anyone we left out.
7. Security Considerations 7. Security Considerations
By definition, certificates contain their own authenticating By definition, certificates contain their own authenticating
signatures. Thus, it is reasonable to store certificates in non- signatures. Thus, it is reasonable to store certificates in
secure DNS zones or to retrieve certificates from DNS with DNS non-secure DNS zones or to retrieve certificates from DNS with DNS
security checking not implemented or deferred for efficiency. The security checking not implemented or deferred for efficiency. The
results may be trusted if the certificate chain is verified back to a results may be trusted if the certificate chain is verified back to a
known trusted key and this conforms with the user's security policy. known trusted key and this conforms with the user's security policy.
Alternatively, if certificates are retrieved from a secure DNS zone Alternatively, if certificates are retrieved from a secure DNS zone
with DNS security checking enabled and are verified by DNS security, with DNS security checking enabled and are verified by DNS security,
the key within the retrieved certificate may be trusted without the key within the retrieved certificate may be trusted without
verifying the certificate chain if this conforms with the user's verifying the certificate chain if this conforms with the user's
security policy. security policy.
If an organization chooses to issue certificates for its employees, If an organization chooses to issue certificates for its employees,
placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC) placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC)
is in use, it is possible for someone to enumerate all employees of is in use, it is possible for someone to enumerate all employees of
the organization. This is usually not considered desirable, for the the organization. This is usually not considered desirable, for the
same reason that enterprise phone listings are not often publicly same reason that enterprise phone listings are not often publicly
published and are even marked confidential. published and are even marked confidential.
Using the URI type introduces another level of indirection that may Using the URI type introduces another level of indirection that may
open a new vulnerability. One method of securing that indirection is open a new vulnerability. One method of securing that indirection is
to include a hash of the certificate in the URI itself. to include a hash of the certificate in the URI itself.
If DNSSEC is used, then the non-existence of a CERT RR and, If DNSSEC is used, then the non-existence of a CERT RR and,
skipping to change at page 12, line 50 skipping to change at page 13, line 14
9-252 Available for IANA assignment 9-252 Available for IANA assignment
by IETF Standards action by IETF Standards action
253 URI URI private RFC 4398 253 URI URI private RFC 4398
254 OID OID private RFC 4398 254 OID OID private RFC 4398
255 Reserved RFC 4398 255 Reserved RFC 4398
256-65279 Available for IANA assignment 256-65279 Available for IANA assignment
by IETF Consensus by IETF Consensus
65280-65534 Experimental RFC 4398 65280-65534 Experimental RFC 4398
65535 Reserved RFC 4398 65535 Reserved RFC 4398
Certificate types 0x0000 through 0x00FF (255) and 0xFF00 (65280) Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
through 0xFFFF (65535) can only be assigned by an IETF standards only be assigned by an IETF standards action [6]. This document
action [6]. This document assigns 0x0001 through 0x0008 and 0x00FD assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE. Certificate
(253) and 0x00FE (254). Certificate types 0x0100 (256) through types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
0xFEFF (65279) are assigned through IETF Consensus [6] based on RFC based on RFC documentation of the certificate type. The availability
documentation of the certificate type. The availability of private of private types under 0x00FD and 0x00FE ought to satisfy most
types under 0x00FD (253) and 0x00FE (254) ought to satisfy most
requirements for proprietary or private types. requirements for proprietary or private types.
The CERT RR reuses the DNS Security Algorithm Numbers registry. In The CERT RR reuses the DNS Security Algorithm Numbers registry. In
particular, the CERT RR requires that algorithm number 0 remain particular, the CERT RR requires that algorithm number 0 remain
reserved, as described in Section 2. The IANA will reference the reserved, as described in Section 2. The IANA will reference the
CERT RR as a user of this registry and value 0, in particular. CERT RR as a user of this registry and value 0, in particular.
9. Changes since RFC 2538 9. Changes since RFC 2538
1. Editorial changes to conform with new document requirements, 1. Editorial changes to conform with new document requirements,
skipping to change at page 16, line 9 skipping to change at page 16, line 21
anyone to use, modify, and distribute it in any way that does not anyone to use, modify, and distribute it in any way that does not
diminish the rights of anyone else to use, modify, and distribute it, diminish the rights of anyone else to use, modify, and distribute it,
provided that redistributed derivative works do not contain provided that redistributed derivative works do not contain
misleading author or version information. Derivative works need not misleading author or version information. Derivative works need not
be licensed under similar terms. be licensed under similar terms.
Author's Address Author's Address
Simon Josefsson Simon Josefsson
Email: simon@josefsson.org EMail: simon@josefsson.org
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 17, line 29 skipping to change at page 17, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 17 change blocks. 
97 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/