diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2538.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2538.txt | 563 |
1 files changed, 0 insertions, 563 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2538.txt b/contrib/bind9/doc/rfc/rfc2538.txt deleted file mode 100644 index c53e3ef..0000000 --- a/contrib/bind9/doc/rfc/rfc2538.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group D. Eastlake -Request for Comments: 2538 IBM -Category: Standards Track O. Gudmundsson - TIS Labs - March 1999 - - - 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 (1999). All Rights Reserved. - -Abstract - - Cryptographic public key 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). - -Table of Contents - - Abstract...................................................1 - 1. Introduction............................................2 - 2. The CERT Resource Record................................2 - 2.1 Certificate Type Values................................3 - 2.2 Text Representation of CERT RRs........................4 - 2.3 X.509 OIDs.............................................4 - 3. Appropriate Owner Names for CERT RRs....................5 - 3.1 X.509 CERT RR Names....................................5 - 3.2 PGP CERT RR Names......................................6 - 4. Performance Considerations..............................6 - 5. IANA Considerations.....................................7 - 6. Security Considerations.................................7 - References.................................................8 - Authors' Addresses.........................................9 - Full Copyright Notice.....................................10 - - - - - - -Eastlake & Gudmundsson Standards Track [Page 1] - -RFC 2538 Storing Certificates in the DNS March 1999 - - -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 PGP - certificates/revocations used by PGP software. - - Section 2 below specifies a CERT resource record (RR) for the storage - of certificates in the Domain Name System. - - 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 [RFC2119]. - -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 define in section 2.1 - below. - - The algorithm field has the same meaning as the algorithm field in - KEY and SIG RRs [RFC 2535] 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 - secure DNS. - - - -Eastlake & Gudmundsson Standards Track [Page 2] - -RFC 2538 Storing Certificates in the DNS March 1999 - - - The key tag field is the 16 bit value computed for the key embedded - in the certificate as specified in the DNSSEC Standard [RFC 2535]. - This field is used as an efficiency measure to 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 be examined. However, the key must always be transformed to the - format it would have as the public key portion of a KEY 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. - -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 cert - 3 PGP PGP cert - 4-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 a certificate formated as to be - specified by the IETF SPKI working group. - - The PGP type indicates a Pretty Good Privacy certificate as described - in RFC 2440 and its extensions and successors. - - 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 [RFC 2396] 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 - - - -Eastlake & Gudmundsson Standards Track [Page 3] - -RFC 2538 Storing Certificates in the DNS March 1999 - - - 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 a 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 - integer or as a mnemonic symbol as listed in section 2.1 above. - - The key tag field is represented as an unsigned integer. - - The algorithm field is represented as an unsigned integer or a - mnemonic symbol as listed in [RFC 2535]. - - The certificate / CRL portion is represented in base 64 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. - - 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: - - - - - - - - - -Eastlake & Gudmundsson Standards Track [Page 4] - -RFC 2538 Storing Certificates in the DNS March 1999 - - - 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 such as \000 for NULL. - -3.1 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: - - - - -Eastlake & Gudmundsson Standards Track [Page 5] - -RFC 2538 Storing Certificates in the DNS March 1999 - - - (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 it 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 PGP names in - 3.2 below. - (5) If none of the above apply, then the distinguished name (DN) - should be mapped into a domain name as specified in RFC 2247. - - Example 1: Assume that 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 <https://www.secure.john-doe.com:8080/>. Then - 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: Assume that 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 - <hacker@mail.widget.foo.example>". Then 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 PGP CERT RR Names - - PGP signed keys (certificates) use a general character string User ID - [RFC 2440]. However, it is recommended by PGP that such names include - the RFC 822 email address of the party, as in "Leslie Example - <Leslie@host.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 822 - name can be extracted from the string name no specific domain name is - recommended. - -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 - - - -Eastlake & Gudmundsson Standards Track [Page 6] - -RFC 2538 Storing Certificates in the DNS March 1999 - - - 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 extensions - fields and using short field values for variable length fields that - must be included. - -5. IANA Considerations - - Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can - only be assigned by an IETF standards action [RFC 2434] (and this - document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE). - Certificate types 0x0100 through 0xFEFF are assigned through IETF - Consensus [RFC 2434] 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. - -6. 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, - the key within the retrieved certificate MAY be trusted without - verifying the certificate chain if this conforms with the user's - security policy. - - CERT RRs are not used in connection with securing the DNS security - additions so there are no security considerations related to CERT RRs - and securing the DNS itself. - - - - - - - - - - - - - - - - -Eastlake & Gudmundsson Standards Track [Page 7] - -RFC 2538 Storing Certificates in the DNS March 1999 - - -References - - RFC 1034 Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - RFC 1035 Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - RFC 2247 Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. - Sataluri, "Using Domains in LDAP/X.500 Distinguished - Names", RFC 2247, January 1998. - - RFC 2396 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. - - RFC 2440 Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, - "OpenPGP Message Format", RFC 2240, November 1998. - - RFC 2434 Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - RFC 2535 Eastlake, D., "Domain Name System (DNS) Security - Extensions", RFC 2535, March 1999. - - RFC 2459 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet - X.509 Public Key Infrastructure Certificate and CRL - Profile", RFC 2459, January 1999. - - - - - - - - - - - - - - - - - - - -Eastlake & Gudmundsson Standards Track [Page 8] - -RFC 2538 Storing Certificates in the DNS March 1999 - - -Authors' Addresses - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road - RR#1 - Carmel, NY 10512 USA - - Phone: +1-914-784-7913 (w) - +1-914-276-2668 (h) - Fax: +1-914-784-3833 (w-fax) - EMail: dee3@us.ibm.com - - - Olafur Gudmundsson - TIS Labs at Network Associates - 3060 Washington Rd, Route 97 - Glenwood MD 21738 - - Phone: +1 443-259-2389 - EMail: ogud@tislabs.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake & Gudmundsson Standards Track [Page 9] - -RFC 2538 Storing Certificates in the DNS March 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake & Gudmundsson Standards Track [Page 10] - |
