564 lines
19 KiB
Plaintext
564 lines
19 KiB
Plaintext
|
|
|
|
|
|
|
|
|
|
|
|
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]
|
|
|