diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt deleted file mode 100644 index 2ec9dbec51..0000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt +++ /dev/null @@ -1,840 +0,0 @@ - - - -Network Working Group S. Josefsson -Internet-Draft August 30, 2005 -Expires: March 3, 2006 - - - Storing Certificates in the Domain Name System (DNS) - draft-ietf-dnsext-rfc2538bis-04 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - 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 March 3, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - Cryptographic public keys are frequently published and their - authenticity demonstrated by certificates. A CERT resource record - (RR) is defined so that such certificates and related certificate - revocation lists can be stored in the Domain Name System (DNS). - - This document obsoletes RFC 2538. - - - - - - -Josefsson Expires March 3, 2006 [Page 1] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3 - 2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4 - 2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5 - 2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 - 3.1. Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 - 3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 - 3.3. Content-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 - 4. Performance Considerations . . . . . . . . . . . . . . . . . . 10 - 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 - Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 12 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - - -Josefsson Expires March 3, 2006 [Page 2] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -1. Introduction - - Public keys are frequently published in the form of a certificate and - their authenticity is commonly demonstrated by certificates and - related certificate revocation lists (CRLs). A certificate is a - binding, through a cryptographic digital signature, of a public key, - a validity interval and/or conditions, and identity, authorization, - or other information. A certificate revocation list is a list of - certificates that are revoked, and incidental information, all signed - by the signer (issuer) of the revoked certificates. Examples are - X.509 certificates/CRLs in the X.500 directory system or OpenPGP - certificates/revocations used by OpenPGP software. - - Section 2 below specifies a CERT resource record (RR) for the storage - of certificates in the Domain Name System [1] [2]. - - Section 3 discusses appropriate owner names for CERT RRs. - - Sections 4, 5, and 6 below cover performance, IANA, and security - considerations, respectively. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [3]. - - -2. The CERT Resource Record - - The CERT resource record (RR) has the structure given below. Its RR - type code is 37. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | type | key tag | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | algorithm | / - +---------------+ certificate or CRL / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - The type field is the certificate type as defined in section 2.1 - below. - - The key tag field is the 16 bit value computed for the key embedded - in the certificate, using the RRSIG Key Tag algorithm described in - Appendix B of [10]. This field is used as an efficiency measure to - pick which CERT RRs may be applicable to a particular key. The key - - - -Josefsson Expires March 3, 2006 [Page 3] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - tag can be calculated for the key in question and then only CERT RRs - with the same key tag need be examined. However, the key must always - be transformed to the format it would have as the public key portion - of a DNSKEY RR before the key tag is computed. This is only possible - if the key is applicable to an algorithm (and limits such as key size - limits) defined for DNS security. If it is not, the algorithm field - MUST BE zero and the tag field is meaningless and SHOULD BE zero. - - The algorithm field has the same meaning as the algorithm field in - DNSKEY and RRSIG RRs [10], except that a zero algorithm field - indicates the algorithm is unknown to a secure DNS, which may simply - be the result of the algorithm not having been standardized for - DNSSEC. - -2.1. Certificate Type Values - - The following values are defined or reserved: - - Value Mnemonic Certificate Type - ----- -------- ---------------- - 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 - 253 URI URI private - 254 OID OID private - 255-65534 available for IANA assignment - 65535 reserved - - The PKIX type is reserved to indicate an X.509 certificate conforming - to the profile being defined by the IETF PKIX working group. The - 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 - certificate section (see 2.3 below). (NOTE: X.509 certificates do - not include their X.500 directory type designating OID as a prefix.) - - The SPKI type is reserved to indicate the SPKI certificate format - [13], for use when the SPKI documents are moved from experimental - status. - - The PGP type indicates an OpenPGP packet as described in [6] and its - extensions and successors. Two uses are to transfer public key - material and revocation signatures. The data is binary, and MUST NOT - be encoded into an ASCII armor. An implementation SHOULD process - - - -Josefsson Expires March 3, 2006 [Page 4] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - transferable public keys as described in section 10.1 of [6], but it - MAY handle additional OpenPGP packets. - - 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 - of the corresponding (PKIX, SPKI or PGP) packet types. These types - are known as "indirect". These packet 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 NOT be used where the entire - UDP packet would have fit in 512 bytes. - - The URI private type indicates a certificate format defined by an - absolute URI. The certificate portion of the CERT RR MUST begin with - a null terminated URI [5] and the data after the null is the private - format certificate itself. The URI SHOULD be such that a retrieval - from it will lead to documentation on the format of the certificate. - Recognition of private certificate types need not be based on URI - equality but can use various forms of pattern matching so that, for - example, subtype or version information can also be encoded into the - URI. - - The OID private type indicates a private format certificate specified - by an ISO OID prefix. The certificate section will start with a one- - byte unsigned OID length and then a BER encoded OID indicating the - nature of the remainder of the certificate section. This can be 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 - type, not the OID private type. Recognition of private certificate - types need not be based on OID equality but can use various forms of - pattern matching such as OID prefix. - -2.2. Text Representation of CERT RRs - - 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 - above. - - The key tag field is represented as an unsigned decimal integer. - - The algorithm field is represented as an unsigned decimal integer or - a mnemonic symbol as listed in [10]. - - The certificate / CRL portion is represented in base 64 [14] and may - be divided up into any number of white space separated substrings, - down to single base 64 digits, which are concatenated to obtain the - full signature. These substrings can span lines using the standard - parenthesis. - - - - -Josefsson Expires March 3, 2006 [Page 5] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - Note that the certificate / CRL portion may have internal sub-fields, - 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 - the certificate / CRL proper. But only a single logical base 64 - string will appear in the text representation. - -2.3. X.509 OIDs - - OIDs have been defined in connection with the X.500 directory for - user certificates, certification authority certificates, revocations - of certification authority, and revocations of user certificates. - The following table lists the OIDs, their BER encoding, and their - length-prefixed hex format for use in CERT RRs: - - id-at-userCertificate - = { joint-iso-ccitt(2) ds(5) at(4) 36 } - == 0x 03 55 04 24 - id-at-cACertificate - = { joint-iso-ccitt(2) ds(5) at(4) 37 } - == 0x 03 55 04 25 - id-at-authorityRevocationList - = { joint-iso-ccitt(2) ds(5) at(4) 38 } - == 0x 03 55 04 26 - id-at-certificateRevocationList - = { joint-iso-ccitt(2) ds(5) at(4) 39 } - == 0x 03 55 04 27 - - -3. Appropriate Owner Names for CERT RRs - - It is recommended that certificate CERT RRs be stored under a domain - name related to their subject, i.e., the name of the entity intended - to control the private key corresponding to the public key being - certified. It is recommended that certificate revocation list CERT - RRs be stored under a domain name related to their issuer. - - Following some of the guidelines below may result in the use in DNS - names of characters that require DNS quoting which is to use a - backslash followed by the octal representation of the ASCII code for - the character (e.g., \000 for NULL). - - The choice of name under which CERT RRs are stored is important to - clients that perform CERT queries. In some situations, the clients - may not know all information about the CERT RR object it wishes to - retrieve. For example, a client may not know the subject name of an - X.509 certificate, or the e-mail address of the owner of an OpenPGP - key. Further, the client might only know the hostname of a service - that uses X.509 certificates or the Key ID of an OpenPGP key. - - - -Josefsson Expires March 3, 2006 [Page 6] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - Therefore, two owner name guidelines are defined: content-based owner - names and purpose-based owner names. A content-based owner name is - derived from the content of the CERT RR data; for example, the - Subject field in an X.509 certificate or the User ID field in OpenPGP - keys. A purpose-based owner name is a name that a client retrieving - CERT RRs MUST already know; for example, the host name of an X.509 - protected service or the Key ID of an OpenPGP key. The content-based - and purpose-based owner name MAY be the same; for example, when a - client looks up a key based on the From: address of an incoming - e-mail. - - Implementations SHOULD use the purpose-based owner name guidelines - described in this document, and MAY use CNAMEs of content-based owner - names (or other names), pointing to the purpose-based owner name. - -3.1. Content-based X.509 CERT RR Names - - Some X.509 versions permit multiple names to be associated with - subjects and issuers under "Subject Alternate Name" and "Issuer - Alternate Name". For example, X.509v3 has such Alternate Names with - an ASN.1 specification as follows: - - GeneralName ::= CHOICE { - otherName [0] INSTANCE OF OTHER-NAME, - rfc822Name [1] IA5String, - dNSName [2] IA5String, - x400Address [3] EXPLICIT OR-ADDRESS.&Type, - directoryName [4] EXPLICIT Name, - ediPartyName [5] EDIPartyName, - uniformResourceIdentifier [6] IA5String, - iPAddress [7] OCTET STRING, - registeredID [8] OBJECT IDENTIFIER - } - - The recommended locations of CERT storage are as follows, in priority - order: - 1. If a domain name is included in the identification in the - certificate or CRL, that should be used. - 2. If a domain name is not included but an IP address is included, - then the translation of that IP address into the appropriate - inverse domain name should be used. - 3. If neither of the above is used, but a URI containing a domain - name is present, that domain name should be used. - 4. If none of the above is included but a character string name is - included, then it should be treated as described for OpenPGP - names below. - - - - - -Josefsson Expires March 3, 2006 [Page 7] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - 5. If none of the above apply, then the distinguished name (DN) - should be mapped into a domain name as specified in [4]. - - Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/ - DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a) - string "John (the Man) Doe", (b) domain name john-doe.com, and (c) - uri . The storage locations - recommended, in priority order, would be - 1. john-doe.com, - 2. www.secure.john-doe.com, and - 3. Doe.com.xy. - - 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) - domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and - (c) string "James Hacker ". The - storage locations recommended, in priority order, would be - 1. widget.foo.example, - 2. 201.13.251.10.in-addr.arpa, and - 3. hacker.mail.widget.foo.example. - -3.2. Purpose-based X.509 CERT RR Names - - Due to the difficulty for clients that do not already possess a - certificate to reconstruct the content-based owner name, purpose- - based owner names are recommended in this section. Recommendations - for purpose-based owner names vary per scenario. The following table - summarizes the purpose-based X.509 CERT RR owner name guidelines for - use with S/MIME [16], SSL/TLS [11], and IPSEC [12]: - - Scenario Owner name - ------------------ ---------------------------------------------- - S/MIME Certificate Standard translation of an RFC 2822 email - address. Example: An S/MIME certificate for - "postmaster@example.org" will use a standard - hostname translation of the owner name, - "postmaster.example.org". - - TLS Certificate Hostname of the TLS server. - - IPSEC Certificate Hostname of the IPSEC machine and/or, for IPv4 - or IPv6 addresses, the fully qualified domain - name in the appropriate reverse domain. - - An alternate approach for IPSEC is to store raw public keys [15]. - - - - - - -Josefsson Expires March 3, 2006 [Page 8] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -3.3. Content-based OpenPGP CERT RR Names - - OpenPGP signed keys (certificates) use a general character string - User ID [6]. However, it is recommended by OpenPGP that such names - include the RFC 2822 [8] email address of the party, as in "Leslie - Example ". If such a format is used, the CERT - 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 - RFC 2822 name can be extracted from the string name, no specific - domain name is recommended. - - If a user has more than one email address, the CNAME type can be used - to reduce the amount of data stored in the DNS. Example: - - $ORIGIN example.org. - smith IN CERT PGP 0 0 - john.smith IN CNAME smith - js IN CNAME smith - -3.4. Purpose-based OpenPGP CERT RR Names - - Applications that receive an OpenPGP packet containing encrypted or - signed data but do not know the email address of the sender will have - difficulties constructing the correct owner name and cannot use the - content-based owner name guidelines. However, these clients commonly - know the key fingerprint or the Key ID. The key ID is found in - OpenPGP packets, and the key fingerprint is commonly found in - auxilliary data that may be available. In this case, use of an owner - name identical to the key fingerprint and the key ID expressed in - hexadecimal [14] is recommended. Example: - - $ORIGIN example.org. - 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... - F835EDA21E94B565716F IN CERT PGP ... - B565716F IN CERT PGP ... - - If the same key material is stored for several owner names, the use - of CNAME may be used to avoid data duplication. Note that CNAME is - not always applicable, because it maps one owner name to the other - for all purposes, which may be sub-optimal when two keys with the - same Key ID are stored. - -3.5. Owner names for IPKIX, ISPKI, and IPGP - - These types are stored under the same owner names, both purpose- and - content-based, as the PKIX, SPKI and PGP types. - - - - - -Josefsson Expires March 3, 2006 [Page 9] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -4. Performance Considerations - - Current Domain Name System (DNS) implementations are optimized for - small transfers, typically not more than 512 bytes including - overhead. While larger transfers will perform correctly and work is - underway to make larger transfers more efficient, it is still - advisable at this time to make every reasonable effort to minimize - the size of certificates stored within the DNS. Steps that can be - taken may include using the fewest possible optional or extension - fields and using short field values for necessary variable length - fields. - - The RDATA field in the DNS protocol may only hold data of size 65535 - octets (64kb) or less. This means that each CERT RR MUST NOT contain - more than 64kb of payload, even if the corresponding certificate or - certificate revocation list is larger. This document addresses this - by defining "indirect" data types for each normal type. - - -5. Contributors - - The majority of this document is copied verbatim from RFC 2538, by - Donald Eastlake 3rd and Olafur Gudmundsson. - - -6. Acknowledgements - - Thanks to David Shaw and Michael Graff for their contributions to - earlier works that motivated, and served as inspiration for, this - document. - - This document was improved by suggestions and comments from Olivier - Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason - Sloderbeck, Samuel Weiler, and Florian Weimer. No doubt the list is - incomplete. We apologize to anyone we left out. - - -7. Security Considerations - - By definition, certificates contain their own authenticating - signature. Thus, it is reasonable to store certificates in non- - secure DNS zones or to retrieve certificates from DNS with DNS - security checking not implemented or deferred for efficiency. The - 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. - - Alternatively, if certificates are retrieved from a secure DNS zone - with DNS security checking enabled and are verified by DNS security, - - - -Josefsson Expires March 3, 2006 [Page 10] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - the key within the retrieved certificate MAY be trusted without - verifying the certificate chain if this conforms with the user's - security policy. - - If an organization chooses to issue certificates for it's employees, - placing CERT RR's 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 enterprise phone listings are not often publicly - published and are even mark confidential. - - When the URI type is used, it should be understood that it introduces - an additional indirection that may allow for a new attack vector. - One method to secure that indirection is to include a hash of the - certificate in the URI itself. - - CERT RRs are not used by DNSSEC [9], so there are no security - considerations related to CERT RRs and securing the DNS 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 - - Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can - only be assigned by an IETF standards action [7]. This document - assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate - types 0x0100 through 0xFEFF are assigned through IETF Consensus [7] - based on RFC documentation of the certificate type. The availability - of private types under 0x00FD and 0x00FE should 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 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, - including splitting reference section into two parts and - updating the references to point at latest versions, and to add - some additional references. - - - - -Josefsson Expires March 3, 2006 [Page 11] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - 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, and IPGP. - - -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. - - -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, - - - -Josefsson Expires March 3, 2006 [Page 12] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, - January 1998. - - [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. - - [6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, - "OpenPGP Message Format", RFC 2440, November 1998. - - [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001. - - [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [10] 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 - - [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. - - [15] Richardson, M., "A Method for Storing IPsec Keying Material in - DNS", RFC 4025, March 2005. - - [16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions - (S/MIME) Version 3.1 Message Specification", RFC 3851, - July 2004. - - - - - - -Josefsson Expires March 3, 2006 [Page 13] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -Author's Address - - Simon Josefsson - - Email: simon@josefsson.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Josefsson Expires March 3, 2006 [Page 14] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -Intellectual Property Statement - - 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. - - -Disclaimer of Validity - - 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 (2005). 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 - Internet Society. - - - - -Josefsson Expires March 3, 2006 [Page 15] - diff --git a/doc/rfc/index b/doc/rfc/index index 947827e59a..6d8e3d255a 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -105,4 +105,5 @@ 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints 4343: Domain Name System (DNS) Case Insensitivity Clarification 4367: What's in a Name: False Assumptions about DNS Names +4398: Storing Certificates in the Domain Name System (DNS) 4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record diff --git a/doc/rfc/rfc4398.txt b/doc/rfc/rfc4398.txt new file mode 100644 index 0000000000..6437436e6a --- /dev/null +++ b/doc/rfc/rfc4398.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group S. Josefsson +Request for Comments: 4398 March 2006 +Obsoletes: 2538 +Category: Standards Track + + + Storing Certificates in the Domain Name System (DNS) + +Status of This Memo + + 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 (C) The Internet Society (2006). + +Abstract + + Cryptographic public keys are frequently published, and their + authenticity is demonstrated by certificates. A CERT resource record + (RR) is defined so that such certificates and related certificate + revocation lists can be stored in the Domain Name System (DNS). + + This document obsoletes RFC 2538. + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Standards Track [Page 1] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. The CERT Resource Record ........................................3 + 2.1. Certificate Type Values ....................................4 + 2.2. Text Representation of CERT RRs ............................6 + 2.3. X.509 OIDs .................................................6 + 3. Appropriate Owner Names for CERT RRs ............................7 + 3.1. Content-Based X.509 CERT RR Names ..........................8 + 3.2. Purpose-Based X.509 CERT RR Names ..........................9 + 3.3. Content-Based OpenPGP CERT RR Names ........................9 + 3.4. Purpose-Based OpenPGP CERT RR Names .......................10 + 3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10 + 4. Performance Considerations .....................................11 + 5. Contributors ...................................................11 + 6. Acknowledgements ...............................................11 + 7. Security Considerations ........................................12 + 8. IANA Considerations ............................................12 + 9. Changes since RFC 2538 .........................................13 + 10. References ....................................................14 + 10.1. Normative References .....................................14 + 10.2. Informative References ...................................15 + Appendix A. Copying Conditions ...................................16 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Standards Track [Page 2] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +1. Introduction + + Public keys are frequently published in the form of a certificate, + and their authenticity is commonly demonstrated by certificates and + related certificate revocation lists (CRLs). A certificate is a + binding, through a cryptographic digital signature, of a public key, + a validity interval and/or conditions, and identity, authorization, + or other information. A certificate revocation list is a list of + certificates that are revoked, and of incidental information, all + signed by the signer (issuer) of the revoked certificates. Examples + are X.509 certificates/CRLs in the X.500 directory system or OpenPGP + certificates/revocations used by OpenPGP software. + + Section 2 specifies a CERT resource record (RR) for the storage of + certificates in the Domain Name System [1] [2]. + + Section 3 discusses appropriate owner names for CERT RRs. + + Sections 4, 7, and 8 cover performance, security, and IANA + considerations, respectively. + + Section 9 explains the changes in this document compared to RFC 2538. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [3]. + +2. The CERT Resource Record + + The CERT resource record (RR) has the structure given below. Its RR + type code is 37. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | type | key tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | algorithm | / + +---------------+ certificate or CRL / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + The type field is the certificate type as defined in Section 2.1 + below. + + The key tag field is the 16-bit value computed for the key embedded + in the certificate, using the RRSIG Key Tag algorithm described in + Appendix B of [12]. This field is used as an efficiency measure to + + + +Josefsson Standards Track [Page 3] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + pick which CERT RRs may be applicable to a particular key. The key + tag can be calculated for the key in question, and then only CERT RRs + with the same key tag need to be examined. Note that two different + keys can have the same key tag. However, the key MUST be transformed + to the format it would have as the public key portion of a DNSKEY RR + before the key tag is computed. This is only possible if the key is + applicable to an algorithm and complies to limits (such as key size) + defined for DNS security. If it is not, the algorithm field MUST be + zero and the tag field is meaningless and SHOULD be zero. + + The algorithm field has the same meaning as the algorithm field in + DNSKEY and RRSIG RRs [12], except that a zero algorithm field + indicates that the algorithm is unknown to a secure DNS, which may + simply be the result of the algorithm not having been standardized + for DNSSEC [11]. + +2.1. Certificate Type Values + + The following values are defined or reserved: + + Value Mnemonic Certificate Type + ----- -------- ---------------- + 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 fingerprint and URL of an OpenPGP packet + 7 ACPKIX Attribute Certificate + 8 IACPKIX The URL of an Attribute Certificate + 9-252 Available for IANA assignment + 253 URI URI private + 254 OID OID private + 255 Reserved + 256-65279 Available for IANA assignment + 65280-65534 Experimental + 65535 Reserved + + These values represent the initial content of the IANA registry; see + Section 8. + + The PKIX type is reserved to indicate an X.509 certificate conforming + to the profile defined by the IETF PKIX working group [8]. The + certificate section will start with a one-octet unsigned OID length + and then an X.500 OID indicating the nature of the remainder of the + + + + + +Josefsson Standards Track [Page 4] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + certificate section (see Section 2.3, below). (NOTE: X.509 + certificates do not include their X.500 directory-type-designating + OID as a prefix.) + + The SPKI and ISPKI types are reserved to indicate the SPKI + certificate format [15], for use when the SPKI documents are moved + from experimental status. The format for these two CERT RR types + will need to be specified later. + + The PGP type indicates an OpenPGP packet as described in [5] and its + extensions and successors. This is used to transfer public key + material and revocation signatures. The data is binary and MUST NOT + be encoded into an ASCII armor. An implementation SHOULD process + transferable public keys as described in Section 10.1 of [5], but it + MAY handle additional OpenPGP packets. + + The ACPKIX type indicates an Attribute Certificate format [9]. + + The IPKIX and IACPKIX types indicate a URL that will serve the + content that would have been in the "certificate, CRL, or URL" field + of the corresponding type (PKIX or ACPKIX, respectively). + + The IPGP type contains both an OpenPGP fingerprint for the key in + question, as well as a URL. The certificate portion of the IPGP CERT + RR is defined as a one-octet fingerprint length, followed by the + OpenPGP fingerprint, followed by the URL. The OpenPGP fingerprint is + calculated as defined in RFC 2440 [5]. A zero-length fingerprint or + a zero-length URL are legal, and indicate URL-only IPGP data or + fingerprint-only IPGP data, respectively. A zero-length fingerprint + and a zero-length URL are meaningless and invalid. + + 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 + 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 + thus be expected to fit a UDP packet. + + The URI private type indicates a certificate format defined by an + absolute URI. The certificate portion of the CERT RR MUST begin with + a null-terminated URI [10], and the data after the null is the + private format certificate itself. The URI SHOULD be such that a + retrieval from it will lead to documentation on the format of the + certificate. Recognition of private certificate types need not be + based on URI equality but can use various forms of pattern matching + so that, for example, subtype or version information can also be + encoded into the URI. + + + + + +Josefsson Standards Track [Page 5] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + The OID private type indicates a private format certificate specified + by an ISO OID prefix. The certificate section will start with a + one-octet unsigned OID length and then a BER-encoded OID indicating + the nature of the remainder of the certificate section. This can be + 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 + type, not the OID private type. Recognition of private certificate + types need not be based on OID equality but can use various forms of + pattern matching such as OID prefix. + +2.2. Text Representation of CERT RRs + + 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, + above. + + The key tag field is represented as an unsigned decimal integer. + + The algorithm field is represented as an unsigned decimal integer or + a mnemonic symbol as listed in [12]. + + The certificate/CRL portion is represented in base 64 [16] and may be + divided into any number of white-space-separated substrings, down to + single base-64 digits, which are concatenated to obtain the full + signature. These substrings can span lines using the standard + parenthesis. + + Note that the certificate/CRL portion may have internal sub-fields, + 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 + the certificate/CRL proper. However, only a single logical base-64 + string will appear in the text representation. + +2.3. X.509 OIDs + + OIDs have been defined in connection with the X.500 directory for + user certificates, certification authority certificates, revocations + of certification authority, and revocations of user certificates. + The following table lists the OIDs, their BER encoding, and their + length-prefixed hex format for use in CERT RRs: + + + + + + + + + + + +Josefsson Standards Track [Page 6] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + id-at-userCertificate + = { joint-iso-ccitt(2) ds(5) at(4) 36 } + == 0x 03 55 04 24 + id-at-cACertificate + = { joint-iso-ccitt(2) ds(5) at(4) 37 } + == 0x 03 55 04 25 + id-at-authorityRevocationList + = { joint-iso-ccitt(2) ds(5) at(4) 38 } + == 0x 03 55 04 26 + id-at-certificateRevocationList + = { joint-iso-ccitt(2) ds(5) at(4) 39 } + == 0x 03 55 04 27 + +3. Appropriate Owner Names for CERT RRs + + It is recommended that certificate CERT RRs be stored under a domain + name related to their subject, i.e., the name of the entity intended + to control the private key corresponding to the public key being + certified. It is recommended that certificate revocation list CERT + RRs be stored under a domain name related to their issuer. + + Following some of the guidelines below may result in DNS names with + characters that require DNS quoting as per Section 5.1 of RFC 1035 + [2]. + + The choice of name under which CERT RRs are stored is important to + clients that perform CERT queries. In some situations, the clients + may not know all information about the CERT RR object it wishes to + retrieve. For example, a client may not know the subject name of an + X.509 certificate, or the email address of the owner of an OpenPGP + key. Further, the client might only know the hostname of a service + that uses X.509 certificates or the Key ID of an OpenPGP key. + + Therefore, two owner name guidelines are defined: content-based owner + names and purpose-based owner names. A content-based owner name is + derived from the content of the CERT RR data; for example, the + Subject field in an X.509 certificate or the User ID field in OpenPGP + keys. A purpose-based owner name is a name that a client retrieving + CERT RRs ought to know already; for example, the host name of an + X.509 protected service or the Key ID of an OpenPGP key. The + content-based and purpose-based owner name may be the same; for + example, when a client looks up a key based on the From: address of + an incoming email. + + Implementations SHOULD use the purpose-based owner name guidelines + described in this document and MAY use CNAME RRs at content-based + owner names (or other names), pointing to the purpose-based owner + name. + + + +Josefsson Standards Track [Page 7] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + Note that this section describes an application-based mapping from + the name space used in a certificate to the name space used by DNS. + The DNS does not infer any relationship amongst CERT resource records + based on similarities or differences of the DNS owner name(s) of CERT + resource records. For example, if multiple labels are used when + mapping from a CERT identifier to a domain name, then care must be + taken in understanding wildcard record synthesis. + +3.1. Content-Based X.509 CERT RR Names + + Some X.509 versions, such as the PKIX profile of X.509 [8], permit + multiple names to be associated with subjects and issuers under + "Subject Alternative Name" and "Issuer Alternative Name". For + example, the PKIX profile has such Alternate Names with an ASN.1 + specification as follows: + + GeneralName ::= CHOICE { + otherName [0] OtherName, + rfc822Name [1] IA5String, + dNSName [2] IA5String, + x400Address [3] ORAddress, + directoryName [4] Name, + ediPartyName [5] EDIPartyName, + uniformResourceIdentifier [6] IA5String, + iPAddress [7] OCTET STRING, + registeredID [8] OBJECT IDENTIFIER } + + The recommended locations of CERT storage are as follows, in priority + order: + + 1. If a domain name is included in the identification in the + certificate or CRL, that ought to be used. + 2. If a domain name is not included but an IP address is included, + then the translation of that IP address into the appropriate + inverse domain name ought to be used. + 3. If neither of the above is used, but a URI containing a domain + name is present, that domain name ought to be used. + 4. If none of the above is included but a character string name is + included, then it ought to be treated as described below for + OpenPGP names. + 5. If none of the above apply, then the distinguished name (DN) + ought to be mapped into a domain name as specified in [4]. + + Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/ + DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a) + string "John (the Man) Doe", (b) domain name john-doe.com, and (c) + URI . The storage locations + recommended, in priority order, would be + + + +Josefsson Standards Track [Page 8] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + 1. john-doe.com, + 2. www.secure.john-doe.com, and + 3. Doe.com.xy. + + 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) + domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and + (c) string "James Hacker ". The + storage locations recommended, in priority order, would be + + 1. widget.foo.example, + 2. 201.13.251.10.in-addr.arpa, and + 3. hacker.mail.widget.foo.example. + +3.2. Purpose-Based X.509 CERT RR Names + + Due to the difficulty for clients that do not already possess a + certificate to reconstruct the content-based owner name, + purpose-based owner names are recommended in this section. + Recommendations for purpose-based owner names vary per scenario. The + following table summarizes the purpose-based X.509 CERT RR owner name + guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]: + + Scenario Owner name + ------------------ ---------------------------------------------- + S/MIME Certificate Standard translation of an RFC 2822 email + address. Example: An S/MIME certificate for + "postmaster@example.org" will use a standard + hostname translation of the owner name, + "postmaster.example.org". + + TLS Certificate Hostname of the TLS server. + + IPsec Certificate Hostname of the IPsec machine and/or, for IPv4 + or IPv6 addresses, the fully qualified domain + name in the appropriate reverse domain. + + An alternate approach for IPsec is to store raw public keys [18]. + +3.3. Content-Based OpenPGP CERT RR Names + + OpenPGP signed keys (certificates) use a general character string + 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 + Example ". If such a format is used, the CERT + ought to be under the standard translation of the email address into + + + + + +Josefsson Standards Track [Page 9] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + a 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 + domain name is recommended. + + If a user has more than one email address, the CNAME type can be used + to reduce the amount of data stored in the DNS. For example: + + $ORIGIN example.org. + smith IN CERT PGP 0 0 + john.smith IN CNAME smith + js IN CNAME smith + +3.4. Purpose-Based OpenPGP CERT RR Names + + Applications that receive an OpenPGP packet containing encrypted or + signed data but do not know the email address of the sender will have + difficulties constructing the correct owner name and cannot use the + content-based owner name guidelines. However, these clients commonly + know the key fingerprint or the Key ID. The key ID is found in + OpenPGP packets, and the key fingerprint is commonly found in + auxiliary data that may be available. In this case, use of an owner + name identical to the key fingerprint and the key ID expressed in + hexadecimal [16] is recommended. For example: + + $ORIGIN example.org. + 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... + F835EDA21E94B565716F IN CERT PGP ... + B565716F IN CERT PGP ... + + If the same key material is stored for several owner names, the use + of CNAME may help avoid data duplication. Note that CNAME is not + always applicable, because it maps one owner name to the other for + all purposes, which may be sub-optimal when two keys with the same + Key ID are stored. + +3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX + + These types are stored under the same owner names, both purpose- and + content-based, as the PKIX, SPKI, PGP, and ACPKIX types. + + + + + + + + + + + + +Josefsson Standards Track [Page 10] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +4. Performance Considerations + + The Domain Name System (DNS) protocol was designed for small + transfers, typically below 512 octets. While larger transfers will + perform correctly and work is underway to make larger transfers more + efficient, it is still advisable at this time that every reasonable + effort be made to minimize the size of certificates stored within the + DNS. Steps that can be taken may include using the fewest possible + optional or extension fields and using short field values for + necessary variable-length fields. + + The RDATA field in the DNS protocol may only hold data of size 65535 + octets (64kb) or less. This means that each CERT RR MUST NOT contain + more than 64kb of payload, even if the corresponding certificate or + certificate revocation list is larger. This document addresses this + by defining "indirect" data types for each normal type. + + Deploying CERT RRs to support digitally signed email changes the + access patterns of DNS lookups from per-domain to per-user. If + digitally signed email and a key/certificate lookup based on CERT RRs + are deployed on a wide scale, this may lead to an increased DNS load, + with potential performance and cache effectiveness consequences. + Whether or not this load increase will be noticeable is not known. + +5. Contributors + + The majority of this document is copied verbatim from RFC 2538, by + Donald Eastlake 3rd and Olafur Gudmundsson. + +6. Acknowledgements + + Thanks to David Shaw and Michael Graff for their contributions to + earlier works that motivated, and served as inspiration for, this + document. + + This document was improved by suggestions and comments from Olivier + Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M. + Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin, + Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel + Weiler, and Florian Weimer. No doubt the list is incomplete. We + apologize to anyone we left out. + + + + + + + + + + +Josefsson Standards Track [Page 11] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +7. Security Considerations + + By definition, certificates contain their own authenticating + signatures. Thus, it is reasonable to store certificates in + non-secure DNS zones or to retrieve certificates from DNS with DNS + security checking not implemented or deferred for efficiency. The + 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. + + Alternatively, if certificates are retrieved from a secure DNS zone + with DNS security checking enabled and are verified by DNS security, + the key within the retrieved certificate may be trusted without + verifying the certificate chain if this conforms with the user's + security policy. + + If an organization chooses to issue certificates for its employees, + 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 + + + +Josefsson Standards Track [Page 12] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + 9-252 Available for IANA assignment + by IETF Standards action + 253 URI URI private RFC 4398 + 254 OID OID private RFC 4398 + 255 Reserved RFC 4398 + 256-65279 Available for IANA assignment + by IETF Consensus + 65280-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. + + + +Josefsson Standards Track [Page 13] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + 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. + + + + + +Josefsson Standards Track [Page 14] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Standards Track [Page 15] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Standards Track [Page 16] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +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). + + + + + + + +Josefsson Standards Track [Page 17] +