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
the organization. This is usually not considered desirable, for the
same reason that enterprise phone listings are not often publicly
published and are even marked confidential.
Using the URI type introduces another level of indirection that may
open a new vulnerability. One method of securing that indirection is
to include a hash of the certificate in the URI itself.
If DNSSEC is used, then the non-existence of a CERT RR and,
consequently, certificates or revocation lists can be securely
asserted. Without DNSSEC, this is not possible.
8. IANA Considerations
The IANA has created a new registry for CERT RR: certificate types.
The initial contents of this registry is:
Decimal Type Meaning Reference
------- ---- ------- ---------
0 Reserved RFC 4398
1 PKIX X.509 as per PKIX RFC 4398
2 SPKI SPKI certificate RFC 4398
3 PGP OpenPGP packet RFC 4398
4 IPKIX The URL of an X.509 data object RFC 4398
5 ISPKI The URL of an SPKI certificate RFC 4398
6 IPGP The fingerprint and URL RFC 4398
of an OpenPGP packet
7 ACPKIX Attribute Certificate RFC 4398
8 IACPKIX The URL of an Attribute RFC 4398
Certificate
9-252 Available for IANA assignment
by IETF Standards action
253 URI URI private RFC 4398
254 OID OID private RFC 4398
255-65023 Available for IANA assignment
by IETF Consensus
65024-65534 Experimental RFC 4398
65535 Reserved RFC 4398
Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
only be assigned by an IETF standards action [6]. This document
assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE. Certificate
types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
based on RFC documentation of the certificate type. The availability
of private types under 0x00FD and 0x00FE ought to satisfy most
requirements for proprietary or private types.
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 will 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,
including splitting reference section into two parts and
updating the references to point at latest versions, and to add
some additional references.
2. Improve terminology. For example replace "PGP" with "OpenPGP",
to align with RFC 2440.
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
how to deal with OpenPGP keys, and acknowledge that
implementations may handle additional packet types.
4. Clarify that integers in the representation format are decimal.
5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
terminology. Improve reference for Key Tag Algorithm
calculations.
6. Add examples that suggest use of CNAME to reduce bandwidth.
7. In Section 3, appended the last paragraphs that discuss
"content-based" vs "purpose-based" owner names. Add Section 3.2
for purpose-based X.509 CERT owner names, and Section 3.4 for
purpose-based OpenPGP CERT owner names.
8. Added size considerations.
9. The SPKI types has been reserved, until RFC 2692/2693 is moved
from the experimental status.
10. Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
11. An IANA registry of CERT type values was created.
10. References
10.1. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
January 1998.
[5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[9] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
10.2. Informative References
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[14] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[15] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
September 1999.
[16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[18] Richardson, M., "A Method for Storing IPsec Keying Material in
DNS", RFC 4025, March 2005.
Appendix A. Copying Conditions
Regarding the portion of this document that was written by Simon
Josefsson ("the author", for the remainder of this section), the
author makes no guarantees and is not responsible for any damage
resulting from its use. The author grants irrevocable permission to
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,
provided that redistributed derivative works do not contain
misleading author or version information. Derivative works need not
be licensed under similar terms.
Author’s Address
Simon Josefsson
EMail: simon@josefsson.org
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
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).