draft-ietf-dnsext-rfc2538bis-01.txt   draft-ietf-dnsext-rfc2538bis-02.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Expires: July 2, 2005 Expires: November 26, 2005
Storing Certificates in the Domain Name System (DNS) Storing Certificates in the Domain Name System (DNS)
draft-ietf-dnsext-rfc2538bis-01 draft-ietf-dnsext-rfc2538bis-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 July 2, 2005. This Internet-Draft will expire on November 26, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
Cryptographic public key are frequently published and their Cryptographic public key 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
revocation lists can be stored in the Domain Name System (DNS). revocation lists can be stored in the Domain Name System (DNS).
See <http://josefsson.org/rfc2538bis/> for more information.
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 . . . . . . . . . . . . . 5 2.2 Text Representation of CERT RRs . . . . . . . . . . . . . 5
2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . 6
3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7
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 . . . . . . . . . . . 8 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 . . . . . . . . . . 9 3.5 Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9
4. Performance Considerations . . . . . . . . . . . . . . . . . . 9 4. Performance Considerations . . . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . 10
8. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 10.1 Normative References . . . . . . . . . . . . . . . . . . 12
A. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 12 10.2 Informative References . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 14 A. Copying conditions . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 14
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
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 incidental information, all signed certificates that are revoked, and incidental information, all signed
skipping to change at page 4, line 43 skipping to change at page 4, line 43
255-65534 available for IANA assignment 255-65534 available for IANA assignment
65535 reserved 65535 reserved
The PKIX type is reserved to indicate an X.509 certificate conforming The PKIX type is reserved to indicate an X.509 certificate conforming
to the profile being defined by the IETF PKIX working group. The to the profile being defined by the IETF PKIX working group. The
certificate section will start with a one byte unsigned OID length certificate section will start with a one byte unsigned OID length
and then an X.500 OID indicating the nature of the remainder of the and then an X.500 OID indicating the nature of the remainder of the
certificate section (see 2.3 below). (NOTE: X.509 certificates do certificate section (see 2.3 below). (NOTE: X.509 certificates do
not include their X.500 directory type designating OID as a prefix.) not include their X.500 directory type designating OID as a prefix.)
The SPKI type is reserved to indicate a certificate formated as to be The SPKI type is reserved to indicate the SPKI certificate format
specified by the IETF SPKI working group. [13], for use when the SPKI documents are moved from experimental
status.
The PGP type indicates an OpenPGP packet as described in [5] and its The PGP type indicates an OpenPGP packet as described in [5] and its
extensions and successors. Two uses are to transfer public key extensions and successors. Two uses are to transfer public key
material and revocation signatures. The data is binary, and MUST NOT material and revocation signatures. The data is binary, and MUST NOT
be encoded into an ASCII armor. An implementation SHOULD process be encoded into an ASCII armor. An implementation SHOULD process
transferable public keys as described in section 10.1 of [5], but it transferable public keys as described in section 10.1 of [5], but it
MAY handle additional OpenPGP packets. MAY handle additional OpenPGP packets.
The IPKIX, ISPKI and IPGP types indicate a URL which will serve the The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
content that would have been in the "certificate, CRL or URL" field content that would have been in the "certificate, CRL or URL" field
skipping to change at page 5, line 44 skipping to change at page 5, line 44
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.
The key tag field is represented as an unsigned decimal integer. The key tag field is represented as an unsigned decimal integer.
The algorithm field is represented as an unsigned decimal integer or The algorithm field is represented as an unsigned decimal integer or
a mnemonic symbol as listed in [9]. a mnemonic symbol as listed in [9].
The certificate / CRL portion is represented in base 64 [11] and may The certificate / CRL portion is represented in base 64 [14] and may
be divided up into any number of white space separated substrings, be divided up into any number of white space separated substrings,
down to single base 64 digits, which are concatenated to obtain the down to single base 64 digits, which are concatenated to obtain the
full signature. These substrings can span lines using the standard full signature. These substrings can span lines using the standard
parenthesis. parenthesis.
Note that the certificate / CRL portion may have internal sub-fields Note that the certificate / CRL portion may have internal sub-fields
but these do not appear in the master file representation. For but these do not appear in the master file representation. For
example, with type 254, there will be an OID size, an OID, and then example, with type 254, there will be an OID size, an OID, and then
the certificate / CRL proper. But only a single logical base 64 the certificate / CRL proper. But only a single logical base 64
string will appear in the text representation. string will appear in the text representation.
skipping to change at page 8, line 33 skipping to change at page 8, line 33
3.2 Purpose-based X.509 CERT RR Names 3.2 Purpose-based X.509 CERT RR Names
It is difficult for clients that do not already posses a certificate It is difficult for clients that do not already posses a certificate
to reconstruct the content-based owner name that should be used to to reconstruct the content-based owner name that should be used to
retrieve the certificate. For this reason, purpose-based owner names retrieve the certificate. For this reason, purpose-based owner names
are recommended in this section. Because purpose-based owner names are recommended in this section. Because purpose-based owner names
by nature depend on the specific scenario, or purpose, for which the by nature depend on the specific scenario, or purpose, for which the
certificate will be used, there are more than one recommendation. certificate will be used, there are more than one recommendation.
The following table summarize the purpose-based X.509 CERT RR owner The following table summarize the purpose-based X.509 CERT RR owner
name guidelines. name guidelines for use with S/MIME [16], SSL/TLS [11], and IPSEC
[12].
Scenario Owner name Scenario Owner name
------------------------------------------------------------------- -------------------------------------------------------------------
S/MIME Certificate Standard translation of RFC 822 email address. S/MIME Certificate Standard translation of RFC 822 email address.
Example: A S/MIME certificate for Example: A 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,
i.e. "postmaster.example.org". i.e. "postmaster.example.org".
SSL Certificate Hostname of the SSL server. TLS Certificate Hostname of the TLS server.
IPSEC Certificate Hostname of the IPSEC machine, and/or IPSEC Certificate Hostname of the IPSEC machine, and/or
for the in-addr.arpa reverse lookup IP address. for the in-addr.arpa reverse lookup IP address.
An alternative approach for IPSEC is to store raw public keys [12]. An alternative approach for IPSEC is to store raw public keys [15].
3.3 Content-based OpenPGP CERT RR Names 3.3 Content-based OpenPGP CERT RR Names
OpenPGP signed keys (certificates) use a general character string OpenPGP signed keys (certificates) use a general character string
User ID [5]. However, it is recommended by OpenPGP that such names User ID [5]. However, it is recommended by OpenPGP that such names
include the RFC 2822 [7] email address of the party, as in "Leslie include the RFC 2822 [7] email address of the party, as in "Leslie
Example <Leslie@host.example>". If such a format is used, the CERT Example <Leslie@host.example>". If such a format is used, the CERT
should be under the standard translation of the email address into a should be under the standard translation of the email address into a
domain name, which would be leslie.host.example in this case. If no domain name, which would be leslie.host.example in this case. If no
RFC 2822 name can be extracted from the string name no specific RFC 2822 name can be extracted from the string name no specific
skipping to change at page 9, line 30 skipping to change at page 9, line 34
3.4 Purpose-based OpenPGP CERT RR Names 3.4 Purpose-based OpenPGP CERT RR Names
Applications that receive an OpenPGP packet containing encrypted or Applications that receive an OpenPGP packet containing encrypted or
signed data but do not know the email address of the sender will have signed data but do not know the email address of the sender will have
difficulties constructing the correct owner name and cannot use the difficulties constructing the correct owner name and cannot use the
content-based owner name guidelines. However, these clients commonly content-based owner name guidelines. However, these clients commonly
know the key fingerprint or the Key ID. The key ID is found in know the key fingerprint or the Key ID. The key ID is found in
OpenPGP packets, and the key fingerprint is commonly found in OpenPGP packets, and the key fingerprint is commonly found in
auxilliary data that may be available. For these situations, it is auxilliary data that may be available. For these situations, it is
recommended to use an owner name identical to the key fingerprint and recommended to use an owner name identical to the key fingerprint and
key ID expressed in hexadecimal [11]. For example: key ID expressed in hexadecimal [14]. For example:
$ORIGIN example.org. $ORIGIN example.org.
0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
F835EDA21E94B565716F IN CERT PGP ... F835EDA21E94B565716F IN CERT PGP ...
B565716F IN CERT PGP ... B565716F IN CERT PGP ...
If the same key material is stored at several owner names, the use of If the same key material is stored at several owner names, the use of
CNAME may be used to avoid data duplication. Note that CNAME is not CNAME may be used to avoid data duplication. Note that CNAME is not
always applicable, because it map an owner names to the other for all always applicable, because it map an owner names to the other for all
purposes, and this may be sub-optimal when two keys with the same Key purposes, and this may be sub-optimal when two keys with the same Key
skipping to change at page 10, line 19 skipping to change at page 10, line 23
taken may include using the fewest possible optional or extensions taken may include using the fewest possible optional or extensions
fields and using short field values for variable length fields that fields and using short field values for variable length fields that
must be included. must be included.
The RDATA field in the DNS protocol may only hold data of size 65535 The RDATA field in the DNS protocol may only hold data of size 65535
octets (64kb) or less. This means that each CERT RR cannot contain octets (64kb) or less. This means that each CERT RR cannot contain
more than 64kb worth of payload, even if the corresponding more than 64kb worth of payload, even if the corresponding
certificate or certificate revocation list is larger. This document certificate or certificate revocation list is larger. This document
address this by defining "indirect" data types for each normal type. address this by defining "indirect" data types for each normal type.
5. Acknowledgements 5. Contributors
The majority of this document is copied verbatim from RFC 2538, by The majority of this document is copied verbatim from RFC 2538, by
Donald Eastlake 3rd and Olafur Gudmundsson. Donald Eastlake 3rd and Olafur Gudmundsson.
The author wishes to thank David Shaw and Michael Graff for their 6. Acknowledgements
contributions to the earlier work that motivated this revised
Thanks to David Shaw and Michael Graff for their contributions to
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, Ben Laurie, Samuel Weiler, and Florian Weimer. No doubt Dubuisson, Ben Laurie, Samuel Weiler, and Florian Weimer. No doubt
the list is incomplete. We apologize to anyone we left out. the list is incomplete. We apologize to anyone we left out.
6. Security Considerations 7. Security Considerations
By definition, certificates contain their own authenticating By definition, certificates contain their own authenticating
signature. Thus it is reasonable to store certificates in non-secure signature. Thus it is reasonable to store certificates in non-secure
DNS zones or to retrieve certificates from DNS with DNS security DNS zones or to retrieve certificates from DNS with DNS security
checking not implemented or deferred for efficiency. The results MAY checking not implemented or deferred for efficiency. The results MAY
be trusted if the certificate chain is verified back to a known be trusted if the certificate chain is verified back to a known
trusted key and this conforms with the user's security policy. 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,
skipping to change at page 11, line 12 skipping to change at page 11, line 17
One method to secure that indirection is to include a hash of the One method to secure that indirection is to include a hash of the
certificate in the URI itself. certificate in the URI itself.
CERT RRs are not used by DNSSEC [8] so there are no security CERT RRs are not used by DNSSEC [8] so there are no security
considerations related to CERT RRs and securing the DNS itself. considerations related to CERT RRs and securing the DNS itself.
If DNSSEC [8] is used then the non-existence of a CERT RR, and If DNSSEC [8] 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.
7. IANA Considerations 8. IANA Considerations
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 [6]. This document only be assigned by an IETF standards action [6]. 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 [6] types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
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 should satisfy most of private types under 0x00FD and 0x00FE should satisfy most
requirements for proprietary or private types. requirements for proprietary or private types.
8. Changes since RFC 2538 The CERT RR reuses the DNS Security Algorithm Numbers registry. In
particular, the CERT RR requires that algorithm number 0 remain
reserved, as described in Section 2. The IANA is directed to
reference the CERT RR as a user of this registry and value 0, in
particular.
9. Changes since RFC 2538
1. Editorial changes to conform with new document requirements, 1. Editorial changes to conform with new document requirements,
including splitting reference section into two parts and updating including splitting reference section into two parts and
the references to point at latest versions, and to add some updating the references to point at latest versions, and to add
additional references. some additional references.
2. Improve terminology. For example replace "PGP" with "OpenPGP", 2. Improve terminology. For example replace "PGP" with "OpenPGP",
to align with RFC 2440. to align with RFC 2440.
3. In section 2.1, clarify that OpenPGP public key data are binary, 3. In section 2.1, clarify that OpenPGP public key data are binary,
not the ASCII armored format, and reference 10.1 in RFC 2440 on not the ASCII armored format, and reference 10.1 in RFC 2440 on
how to deal with OpenPGP keys, and acknowledge that how to deal with OpenPGP keys, and acknowledge that
implementations may handle additional packet types. implementations may handle additional packet types.
4. Clarify that integers in the representation format are decimal. 4. Clarify that integers in the representation format are decimal.
5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
terminology. Improve reference for Key Tag Algorithm terminology. Improve reference for Key Tag Algorithm
calculations. calculations.
6. Add examples that suggest use of CNAME to reduce bandwidth. 6. Add examples that suggest use of CNAME to reduce bandwidth.
7. In section 3, appended the last paragraphs that discuss 7. In section 3, appended the last paragraphs that discuss
"content-based" vs "purpose-based" owner names. Add section 3.2 "content-based" vs "purpose-based" owner names. Add section 3.2
for purpose-based X.509 CERT owner names, and section 3.4 for for purpose-based X.509 CERT owner names, and section 3.4 for
purpose-based OpenPGP CERT owner names. purpose-based OpenPGP CERT owner names.
8. Added size considerations. 8. Added size considerations.
9. Added indirect types IPKIX, ISPKI, and IPGP. 9. The SPKI types has been reserved, until RFC 2692/2693 is moved
from the experimental status.
10. Added indirect types IPKIX, ISPKI, and IPGP.
9. References 10. References
9.1 Normative References 10.1 Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD [1] Mockapetris, P., "Domain names - concepts and facilities",
13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and [2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[3] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, [3] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
January 1998. January 1998.
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP [5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP
Message Format", RFC 2440, November 1998. Message Format", RFC 2440, November 1998.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, [8] Arends, R., Austein, R., Massey, D., Larson, M., and S. Rose,
"DNS Security Introduction and Requirements", "DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-13 (work in progress), October draft-ietf-dnsext-dnssec-intro-13 (work in progress),
2004. October 2004.
[9] Arends, R., "Resource Records for the DNS Security Extensions", [9] Arends, R., "Resource Records for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-11 (work in progress), October draft-ietf-dnsext-dnssec-records-11 (work in progress),
2004. October 2004.
9.2 Informative References 10.2 Informative References
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[13] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
September 1999.
[14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003. RFC 3548, July 2003.
[12] Richardson, M., "A method for storing IPsec keying material in [15] Richardson, M., "A method for storing IPsec keying material in
DNS", draft-ietf-ipseckey-rr-11 (work in progress), July 2004. DNS", draft-ietf-ipseckey-rr-11 (work in progress), July 2004.
[16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
Author's Address Author's Address
Simon Josefsson Simon Josefsson
EMail: simon@josefsson.org Email: simon@josefsson.org
Appendix A. Copying conditions Appendix A. Copying conditions
Regarding the portion of this document that was written by Simon Regarding the portion of this document that was written by Simon
Josefsson ("the author", for the remainder of this section), the Josefsson ("the author", for the remainder of this section), the
author makes no guarantees and is not responsible for any damage author makes no guarantees and is not responsible for any damage
resulting from its use. The author grants irrevocable permission to resulting from its use. The author grants irrevocable permission to
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
 End of changes. 

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