draft-ietf-dnsext-rfc2538bis-06.txt | draft-ietf-dnsext-rfc2538bis-07.txt | |||
---|---|---|---|---|
Network Working Group S. Josefsson | Network Working Group S. Josefsson | |||
Obsoletes: 2538 (if approved) | Obsoletes: 2538 (if approved) | |||
Expires: March 19, 2006 | Expires: March 27, 2006 | |||
Storing Certificates in the Domain Name System (DNS) | Storing Certificates in the Domain Name System (DNS) | |||
draft-ietf-dnsext-rfc2538bis-06 | draft-ietf-dnsext-rfc2538bis-07 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 34 | skipping to change at page 1, line 34 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on March 19, 2006. | This Internet-Draft will expire on March 27, 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2005). | |||
Abstract | Abstract | |||
Cryptographic public keys are frequently published and their | Cryptographic public keys are frequently published and their | |||
authenticity demonstrated by certificates. A CERT resource record | authenticity 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 | |||
skipping to change at page 2, line 24 | skipping to change at page 2, line 24 | |||
3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 | 3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 | |||
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 . . . . . . . . . . . 9 | 3.4. Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9 | |||
3.5. Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 10 | 3.5. Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 10 | |||
4. Performance Considerations . . . . . . . . . . . . . . . . . . 10 | 4. Performance Considerations . . . . . . . . . . . . . . . . . . 10 | |||
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 12 | 9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 12 | |||
Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 12 | Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 13 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 16 | Intellectual Property and Copyright Statements . . . . . . . . . . 16 | |||
1. Introduction | 1. Introduction | |||
Public keys are frequently published in the form of a certificate and | Public keys are frequently published in the form of a certificate and | |||
their authenticity is commonly demonstrated by certificates and | their authenticity is commonly demonstrated by certificates and | |||
skipping to change at page 11, line 49 | skipping to change at page 11, line 49 | |||
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 to secure that indirection is | open a new vulnerability. One method to secure 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, | |||
consequently, certificates or revocation lists can be securely | consequently, certificates or revocation lists can be securely | |||
asserted. Without DNSSEC, this is not possible. | asserted. Without DNSSEC, this is not possible. | |||
8. IANA Considerations | 8. IANA Considerations | |||
IANA needs to create a new registry for CERT RR, certificate types. | ||||
The initial contents of this registry is: | ||||
0 reserved | ||||
1 PKIX X.509 as per PKIX | ||||
2 SPKI SPKI certificate | ||||
3 PGP OpenPGP packet | ||||
4 IPKIX The URL of an X.509 data object | ||||
5 ISPKI The URL of an SPKI certificate | ||||
6 IPGP The URL of an OpenPGP packet | ||||
7-252 available for IANA assignment | ||||
by IETF Standards action | ||||
253 URI URI private | ||||
254 OID OID private | ||||
255-65023 available for IANA assignment | ||||
by IETF Consensus. | ||||
65024-65534 experimental | ||||
65535 reserved | ||||
Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can | Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can | |||
only be assigned by an IETF standards action [7]. This document | only be assigned by an IETF standards action [7]. This document | |||
assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate | assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate | |||
types 0x0100 through 0xFEFF are assigned through IETF Consensus [7] | types 0x0100 through 0xFEFF are assigned through IETF Consensus [7] | |||
based on RFC documentation of the certificate type. The availability | based on RFC documentation of the certificate type. The availability | |||
of private types under 0x00FD and 0x00FE ought to satisfy most | of private types under 0x00FD and 0x00FE 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 | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |