rfc2538xml.txt   draft-ietf-dnsext-rfc2538bis.txt 
1 1
2Network Working Group S. Josefsson Network Working Group S. Josefsson2
3 3
4Expires: March 5, 2005 Obsoletes: 2538 (if approved)4
Expires: September 2, 20065
5 6
6 Storing Certificates in the Domain Name System (DNS) Storing Certificates in the Domain Name System (DNS)7
7 rfc2538 draft-ietf-dnsext-rfc2538bis-108
8 9
9Status of this Memo Status of this Memo10
10 11
11 By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any12
12 applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware13
13 have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes14
14 aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.15
15 16
16 Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering17
17 Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that18
skipping to change at page 1, line 33 skipping to change at page 1, line 34
22 and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any23
23 time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference24
24 material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."25
25 26
26 The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at27
27 http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.28
28 29
29 The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at30
30 http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.31
31 32
32 This Internet-Draft will expire on March 5, 2005. This Internet-Draft will expire on September 2, 2006.33
33 34
34Copyright Notice Copyright Notice35
35 36
36 Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2006).37
37 38
38Abstract Abstract39
39 40
40 Cryptographic public key are frequently published and their Cryptographic public keys are frequently published, and their41
41 authenticity demonstrated by certificates. A CERT resource record authenticity is demonstrated by certificates. A CERT resource record42
42 (RR) is defined so that such certificates and related certificate (RR) is defined so that such certificates and related certificate43
43 revocation lists can be stored in the Domain Name System (DNS). revocation lists can be stored in the Domain Name System (DNS).44
44 45
This document obsoletes RFC 2538.46
47
45Table of Contents Table of Contents48
46 49
47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 350
48 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 351
49 2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4 2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 452
50 2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5 2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 653
51 2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 654
52 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 755
53 3.1. X.509 CERT RR Names . . . . . . . . . . . . . . . . . . . 6 3.1. Content-Based X.509 CERT RR Names . . . . . . . . . . . . 856
54 3.2. PGP CERT RR Names . . . . . . . . . . . . . . . . . . . . 7 3.2. Purpose-Based X.509 CERT RR Names . . . . . . . . . . . . 957
55 4. Performance Considerations . . . . . . . . . . . . . . . . . . 7 3.3. Content-Based OpenPGP CERT RR Names . . . . . . . . . . . 958
56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3.4. Purpose-Based OpenPGP CERT RR Names . . . . . . . . . . . 1059
57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX . . . . . 1060
58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Performance Considerations . . . . . . . . . . . . . . . . . . 1061
59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 1162
60 Intellectual Property and Copyright Statements . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 1163
7. Security Considerations . . . . . . . . . . . . . . . . . . . 1164
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1265
9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 1366
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 1367
10.1. Normative References . . . . . . . . . . . . . . . . . . . 1368
10.2. Informative References . . . . . . . . . . . . . . . . . . 1469
Appendix A. Copying Conditions . . . . . . . . . . . . . . . . . 1570
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 1671
Intellectual Property and Copyright Statements . . . . . . . . . . 1772
61 73
621. Introduction 1. Introduction74
63 75
64 Public keys are frequently published in the form of a certificate and Public keys are frequently published in the form of a certificate,76
65 their authenticity is commonly demonstrated by certificates and and their authenticity is commonly demonstrated by certificates and77
66 related certificate revocation lists (CRLs). A certificate is a related certificate revocation lists (CRLs). A certificate is a78
67 binding, through a cryptographic digital signature, of a public key, binding, through a cryptographic digital signature, of a public key,79
68 a validity interval and/or conditions, and identity, authorization, a validity interval and/or conditions, and identity, authorization,80
69 or other information. A certificate revocation list is a list of or other information. A certificate revocation list is a list of81
70 certificates that are revoked, and incidental information, all signed certificates that are revoked, and of incidental information, all82
71 by the signer (issuer) of the revoked certificates. Examples are signed by the signer (issuer) of the revoked certificates. Examples83
72 X.509 certificates/CRLs in the X.500 directory system or PGP are X.509 certificates/CRLs in the X.500 directory system or OpenPGP84
73 certificates/revocations used by PGP software. certificates/revocations used by OpenPGP software.85
74 86
75 Section 2 below specifies a CERT resource record (RR) for the storage Section 2 specifies a CERT resource record (RR) for the storage of87
76 of certificates in the Domain Name System. certificates in the Domain Name System [1] [2].88
77 89
78 Section 3 discusses appropriate owner names for CERT RRs. Section 3 discusses appropriate owner names for CERT RRs.90
79 91
80 Sections 4, 5, and 6 below cover performance, IANA, and security Sections 4, 7, and 8 cover performance, security, and IANA92
81 considerations, respectively. considerations, respectively.93
82 94
Section 9 explains the changes in this document compared to RFC 2538.95
96
83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",97
84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this98
85 document are to be interpreted as described in [3]. document are to be interpreted as described in [3].99
86 100
872. The CERT Resource Record 2. The CERT Resource Record101
88 102
89 The CERT resource record (RR) has the structure given below. Its RR The CERT resource record (RR) has the structure given below. Its RR103
90 type code is 37. type code is 37.104
91 105
92 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3106
93 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 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 1107
94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+108
95 | type | key tag | | type | key tag |109
96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+110
97 | algorithm | / | algorithm | /111
98 +---------------+ certificate or CRL / +---------------+ certificate or CRL /112
99 / / / /113
100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|114
101 115
102 The type field is the certificate type as define in section 2.1 The type field is the certificate type as defined in Section 2.1116
103 below. below.117
104 118
105 The algorithm field has the same meaning as the algorithm field in The key tag field is the 16-bit value computed for the key embedded119
106 KEY and SIG RRs [8] except that a zero algorithm field indicates the in the certificate, using the RRSIG Key Tag algorithm described in120
107 algorithm is unknown to a secure DNS, which may simply be the result Appendix B of [12]. This field is used as an efficiency measure to121
108 of the algorithm not having been standardized for secure DNS. pick which CERT RRs may be applicable to a particular key. The key122
tag can be calculated for the key in question, and then only CERT RRs123
with the same key tag need to be examined. Note that two different124
keys can have the same key tag. However, the key MUST be transformed125
to the format it would have as the public key portion of a DNSKEY RR126
before the key tag is computed. This is only possible if the key is127
applicable to an algorithm and complies to limits (such as key size)128
defined for DNS security. If it is not, the algorithm field MUST be129
zero and the tag field is meaningless and SHOULD be zero.130
109 131
110 The key tag field is the 16 bit value computed for the key embedded The algorithm field has the same meaning as the algorithm field in132
111 in the certificate as specified in the DNSSEC Standard [8]. This DNSKEY and RRSIG RRs [12], except that a zero algorithm field133
112 field is used as an efficiency measure to pick which CERT RRs may be indicates that the algorithm is unknown to a secure DNS, which may134
113 applicable to a particular key. The key tag can be calculated for simply be the result of the algorithm not having been standardized135
114 the key in question and then only CERT RRs with the same key tag need for DNSSEC [11].136
115 be examined. However, the key must always be transformed to the
116 format it would have as the public key portion of a KEY RR before the
117 key tag is computed. This is only possible if the key is applicable
118 to an algorithm (and limits such as key size limits) defined for DNS
119 security. If it is not, the algorithm field MUST BE zero and the tag
120 field is meaningless and SHOULD BE zero.
121 137
1222.1. Certificate Type Values 2.1. Certificate Type Values138
123 139
124 The following values are defined or reserved: The following values are defined or reserved:140
125 141
126 Value Mnemonic Certificate Type Value Mnemonic Certificate Type142
127 ----- -------- ----------- ---- ----- -------- ----------------143
128 0 reserved 0 Reserved144
129 1 PKIX X.509 as per PKIX 1 PKIX X.509 as per PKIX145
130 2 SPKI SPKI cert 2 SPKI SPKI certificate146
131 3 PGP PGP cert 3 PGP OpenPGP packet147
132 4-252 available for IANA assignment 4 IPKIX The URL of an X.509 data object148
5 ISPKI The URL of an SPKI certificate149
6 IPGP The fingerprint and URL of an OpenPGP packet150
7 ACPKIX Attribute Certificate151
8 IACPKIX The URL of an Attribute Certificate152
9-252 Available for IANA assignment153
133 253 URI URI private 253 URI URI private154
134 254 OID OID private 254 OID OID private155
135 255-65534 available for IANA assignment 255 Reserved156
136 65535 reserved 256-65279 Available for IANA assignment157
65280-65534 Experimental158
65535 Reserved159
160
These values represent the initial content of the IANA registry; see161
Section 8.162
137 163
138 The PKIX type is reserved to indicate an X.509 certificate conforming The PKIX type is reserved to indicate an X.509 certificate conforming164
139 to the profile being defined by the IETF PKIX working group. The to the profile defined by the IETF PKIX working group [8]. The165
140 certificate section will start with a one byte unsigned OID length certificate section will start with a one-octet unsigned OID length166
141 and then an X.500 OID indicating the nature of the remainder of the and then an X.500 OID indicating the nature of the remainder of the167
142 certificate section (see 2.3 below). (NOTE: X.509 certificates do certificate section (see Section 2.3, below). (NOTE: X.509168
143 not include their X.500 directory type designating OID as a prefix.) certificates do not include their X.500 directory-type-designating169
OID as a prefix.)170
144 171
145 The SPKI type is reserved to indicate a certificate formated as to be The SPKI and ISPKI types are reserved to indicate the SPKI172
146 specified by the IETF SPKI working group. certificate format [15], for use when the SPKI documents are moved173
from experimental status. The format for these two CERT RR types174
will need to be specified later.175
147 176
148 The PGP type indicates a Pretty Good Privacy certificate as described The PGP type indicates an OpenPGP packet as described in [5] and its177
149 in [6] and its extensions and successors. extensions and successors. This is used to transfer public key178
material and revocation signatures. The data is binary and MUST NOT179
be encoded into an ASCII armor. An implementation SHOULD process180
transferable public keys as described in Section 10.1 of [5], but it181
MAY handle additional OpenPGP packets.182
183
The ACPKIX type indicates an Attribute Certificate format [9].184
185
The IPKIX and IACPKIX types indicate a URL that will serve the186
content that would have been in the "certificate, CRL, or URL" field187
of the corresponding type (PKIX or ACPKIX, respectively).188
189
The IPGP type contains both an OpenPGP fingerprint for the key in190
question, as well as a URL. The certificate portion of the IPGP CERT191
RR is defined as a one-octet fingerprint length, followed by the192
OpenPGP fingerprint, followed by the URL. The OpenPGP fingerprint is193
calculated as defined in RFC 2440 [5]. A zero-length fingerprint or194
a zero-length URL are legal, and indicate URL-only IPGP data or195
fingerprint-only IPGP data, respectively. A zero-length fingerprint196
and a zero-length URL are meaningless and invalid.197
198
The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".199
These types MUST be used when the content is too large to fit in the200
CERT RR and MAY be used at the implementer's discretion. They SHOULD201
NOT be used where the DNS message is 512 octets or smaller and could202
thus be expected to fit a UDP packet.203
150 204
151 The URI private type indicates a certificate format defined by an The URI private type indicates a certificate format defined by an205
152 absolute URI. The certificate portion of the CERT RR MUST begin with absolute URI. The certificate portion of the CERT RR MUST begin with206
153 a null terminated URI [5] and the data after the null is the private a NUL-terminated URI [10] and the data after the NUL is the private207
154 format certificate itself. The URI SHOULD be such that a retrieval format certificate itself. The URI SHOULD be such that a retrieval208
155 from it will lead to documentation on the format of the certificate. from it will lead to documentation on the format of the certificate.209
156 Recognition of private certificate types need not be based on URI Recognition of private certificate types need not be based on URI210
157 equality but can use various forms of pattern matching so that, for equality but can use various forms of pattern matching so that, for211
158 example, subtype or version information can also be encoded into the example, subtype or version information can also be encoded into the212
159 URI. URI.213
160 214
161 The OID private type indicates a private format certificate specified The OID private type indicates a private format certificate specified215
162 by a an ISO OID prefix. The certificate section will start with a by an ISO OID prefix. The certificate section will start with a one-216
163 one byte unsigned OID length and then a BER encoded OID indicating octet unsigned OID length and then a BER-encoded OID indicating the217
164 the nature of the remainder of the certificate section. This can be nature of the remainder of the certificate section. This can be an218
165 an X.509 certificate format or some other format. X.509 certificates X.509 certificate format or some other format. X.509 certificates219
166 that conform to the IETF PKIX profile SHOULD be indicated by the PKIX that conform to the IETF PKIX profile SHOULD be indicated by the PKIX220
167 type, not the OID private type. Recognition of private certificate type, not the OID private type. Recognition of private certificate221
168 types need not be based on OID equality but can use various forms of types need not be based on OID equality but can use various forms of222
169 pattern matching such as OID prefix. pattern matching such as OID prefix.223
170 224
1712.2. Text Representation of CERT RRs 2.2. Text Representation of CERT RRs225
172 226
173 The RDATA portion of a CERT RR has the type field as an unsigned The RDATA portion of a CERT RR has the type field as an unsigned227
174 integer or as a mnemonic symbol as listed in section 2.1 above. decimal integer or as a mnemonic symbol as listed in Section 2.1,228
above.229
175 230
176 The key tag field is represented as an unsigned integer. The key tag field is represented as an unsigned decimal integer.231
177 232
178 The algorithm field is represented as an unsigned integer or a The algorithm field is represented as an unsigned decimal integer or233
179 mnemonic symbol as listed in [8]. a mnemonic symbol as listed in [12].234
180 235
181 The certificate / CRL portion is represented in base 64 and may be The certificate/CRL portion is represented in base 64 [16] and may be236
182 divided up into any number of white space separated substrings, down divided into any number of white-space-separated substrings, down to237
183 to single base 64 digits, which are concatenated to obtain the full single base-64 digits, which are concatenated to obtain the full238
184 signature. These substrings can span lines using the standard signature. These substrings can span lines using the standard239
185 parenthesis. parenthesis.240
186 241
187 Note that the certificate / CRL portion may have internal sub-fields Note that the certificate / CRL portion may have internal sub-fields,242
188 but these do not appear in the master file representation. For but these do not appear in the master file representation. For243
189 example, with type 254, there will be an OID size, an OID, and then example, with type 254, there will be an OID size, an OID, and then244
190 the certificate / CRL proper. But only a single logical base 64 the certificate/CRL proper. However, only a single logical base-64245
191 string will appear in the text representation. string will appear in the text representation.246
192 247
1932.3. X.509 OIDs 2.3. X.509 OIDs248
194 249
195 OIDs have been defined in connection with the X.500 directory for OIDs have been defined in connection with the X.500 directory for250
196 user certificates, certification authority certificates, revocations user certificates, certification authority certificates, revocations251
197 of certification authority, and revocations of user certificates. of certification authority, and revocations of user certificates.252
198 The following table lists the OIDs, their BER encoding, and their The following table lists the OIDs, their BER encoding, and their253
199 length prefixed hex format for use in CERT RRs: length-prefixed hex format for use in CERT RRs:254
200 255
201 id-at-userCertificate id-at-userCertificate256
202 = { joint-iso-ccitt(2) ds(5) at(4) 36 } = { joint-iso-ccitt(2) ds(5) at(4) 36 }257
203 == 0x 03 55 04 24 == 0x 03 55 04 24258
204 id-at-cACertificate id-at-cACertificate259
205 = { joint-iso-ccitt(2) ds(5) at(4) 37 } = { joint-iso-ccitt(2) ds(5) at(4) 37 }260
206 == 0x 03 55 04 25 == 0x 03 55 04 25261
207 id-at-authorityRevocationList id-at-authorityRevocationList262
208 = { joint-iso-ccitt(2) ds(5) at(4) 38 } = { joint-iso-ccitt(2) ds(5) at(4) 38 }263
209 == 0x 03 55 04 26 == 0x 03 55 04 26264
skipping to change at page 6, line 26 skipping to change at page 7, line 26
212 == 0x 03 55 04 27 == 0x 03 55 04 27267
213 268
2143. Appropriate Owner Names for CERT RRs 3. Appropriate Owner Names for CERT RRs269
215 270
216 It is recommended that certificate CERT RRs be stored under a domain It is recommended that certificate CERT RRs be stored under a domain271
217 name related to their subject, i.e., the name of the entity intended name related to their subject, i.e., the name of the entity intended272
218 to control the private key corresponding to the public key being to control the private key corresponding to the public key being273
219 certified. It is recommended that certificate revocation list CERT certified. It is recommended that certificate revocation list CERT274
220 RRs be stored under a domain name related to their issuer. RRs be stored under a domain name related to their issuer.275
221 276
222 Following some of the guidelines below may result in the use in DNS Following some of the guidelines below may result in DNS names with277
223 names of characters that require DNS quoting which is to use a characters that require DNS quoting as per Section 5.1 of RFC 1035278
224 backslash followed by the octal representation of the ASCII code for [2].279
225 the character such as \000 for NULL.
226 280
2273.1. X.509 CERT RR Names The choice of name under which CERT RRs are stored is important to281
clients that perform CERT queries. In some situations, the clients282
may not know all information about the CERT RR object it wishes to283
retrieve. For example, a client may not know the subject name of an284
X.509 certificate, or the email address of the owner of an OpenPGP285
key. Further, the client might only know the hostname of a service286
that uses X.509 certificates or the Key ID of an OpenPGP key.287
228 288
229 Some X.509 versions permit multiple names to be associated with Therefore, two owner name guidelines are defined: content-based owner289
230 subjects and issuers under "Subject Alternate Name" and "Issuer names and purpose-based owner names. A content-based owner name is290
231 Alternate Name". For example, x.509v3 has such Alternate Names with derived from the content of the CERT RR data; for example, the291
232 an ASN.1 specification as follows: Subject field in an X.509 certificate or the User ID field in OpenPGP292
keys. A purpose-based owner name is a name that a client retrieving293
CERT RRs ought to know already; for example, the host name of an294
X.509 protected service or the Key ID of an OpenPGP key. The295
content-based and purpose-based owner name may be the same; for296
example, when a client looks up a key based on the From: address of297
an incoming email.298
299
Implementations SHOULD use the purpose-based owner name guidelines300
described in this document and MAY use CNAME RRs at content-based301
owner names (or other names), pointing to the purpose-based owner302
name.303
304
Note that this section describes an application-based mapping from305
the name space used in a certificate to the name space used by DNS.306
The DNS does not infer any relationship amongst CERT resource records307
based on similarities or differences of the DNS owner name(s) of CERT308
resource records. For example, if multiple labels are used when309
mapping from a CERT identifier to a domain name, then care must be310
taken in understanding wildcard record synthesis.311
312
3.1. Content-Based X.509 CERT RR Names313
314
Some X.509 versions, such as the PKIX profile of X.509 [8], permit315
multiple names to be associated with subjects and issuers under316
"Subject Alternative Name" and "Issuer Alternative Name". For317
example, the PKIX profile has such Alternate Names with an ASN.1318
specification as follows:319
233 320
234 GeneralName ::= CHOICE { GeneralName ::= CHOICE {321
235 otherName [0] INSTANCE OF OTHER-NAME, otherName [0] OtherName,322
236 rfc822Name [1] IA5String, rfc822Name [1] IA5String,323
237 dNSName [2] IA5String, dNSName [2] IA5String,324
238 x400Address [3] EXPLICIT OR-ADDRESS.&Type, x400Address [3] ORAddress,325
239 directoryName [4] EXPLICIT Name, directoryName [4] Name,326
240 ediPartyName [5] EDIPartyName, ediPartyName [5] EDIPartyName,327
241 uniformResourceIdentifier [6] IA5String, uniformResourceIdentifier [6] IA5String,328
242 iPAddress [7] OCTET STRING, iPAddress [7] OCTET STRING,329
243 registeredID [8] OBJECT IDENTIFIER registeredID [8] OBJECT IDENTIFIER }330
244 }
245 331
246 The recommended locations of CERT storage are as follows, in priority The recommended locations of CERT storage are as follows, in priority332
247 order: order:333
248
249 1. If a domain name is included in the identification in the 1. If a domain name is included in the identification in the334
250 certificate or CRL, that should be used. certificate or CRL, that ought to be used.335
251 2. If a domain name is not included but an IP address is included, 2. If a domain name is not included but an IP address is included,336
252 then the translation of that IP address into the appropriate then the translation of that IP address into the appropriate337
253 inverse domain name should be used. inverse domain name ought to be used.338
254 3. If neither of the above it used but a URI containing a domain 3. If neither of the above is used, but a URI containing a domain339
255 name is present, that domain name should be used. name is present, that domain name ought to be used.340
256 4. If none of the above is included but a character string name is 4. If none of the above is included but a character string name is341
257 included, then it should be treated as described for PGP names in included, then it ought to be treated as described below for342
258 3.2 below. OpenPGP names.343
259 5. If none of the above apply, then the distinguished name (DN) 5. If none of the above apply, then the distinguished name (DN)344
260 should be mapped into a domain name as specified in [4]. ought to be mapped into a domain name as specified in [4].345
261 346
262 Example 1: Assume that an X.509v3 certificate is issued to /CN=John Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/347
263 Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)348
264 names of (a) string "John (the Man) Doe", (b) domain name john- string "John (the Man) Doe", (b) domain name john-doe.com, and (c)349
265 doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>. Then URI <https://www.secure.john-doe.com:8080/>. The storage locations350
266 the storage locations recommended, in priority order, would be recommended, in priority order, would be351
267 1. john-doe.com, 1. john-doe.com,352
268 2. www.secure.john-doe.com, and 2. www.secure.john-doe.com, and353
269 3. Doe.com.xy. 3. Doe.com.xy.354
270 355
271 Example 2: Assume that an X.509v3 certificate is issued to /CN=James Example 2: An X.509v3 certificate is issued to /CN=James Hacker/356
272 Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)357
273 of (a) domain name widget.foo.example, (b) IPv4 address domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and358
274 10.251.13.201, and (c) string "James Hacker (c) string "James Hacker <hacker@mail.widget.foo.example>". The359
275 <hacker@mail.widget.foo.example>". Then the storage locations storage locations recommended, in priority order, would be360
276 recommended, in priority order, would be
277 1. widget.foo.example, 1. widget.foo.example,361
278 2. 201.13.251.10.in-addr.arpa, and 2. 201.13.251.10.in-addr.arpa, and362
279 3. hacker.mail.widget.foo.example. 3. hacker.mail.widget.foo.example.363
280 364
2813.2. PGP CERT RR Names 3.2. Purpose-Based X.509 CERT RR Names365
282 366
283 PGP signed keys (certificates) use a general character string User ID Due to the difficulty for clients that do not already possess a367
284 [6]. However, it is recommended by PGP that such names include the certificate to reconstruct the content-based owner name, purpose-368
285 RFC 822 email address of the party, as in "Leslie Example based owner names are recommended in this section. Recommendations369
286 <Leslie@host.example>". If such a format is used, the CERT should be for purpose-based owner names vary per scenario. The following table370
287 under the standard translation of the email address into a domain summarizes the purpose-based X.509 CERT RR owner name guidelines for371
288 name, which would be leslie.host.example in this case. If no RFC 822 use with S/MIME [17], SSL/TLS [13], and IPsec [14]:372
289 name can be extracted from the string name no specific domain name is 373
290 recommended. Scenario Owner name374
------------------ ----------------------------------------------375
S/MIME Certificate Standard translation of an RFC 2822 email376
address. Example: An S/MIME certificate for377
"postmaster@example.org" will use a standard378
hostname translation of the owner name,379
"postmaster.example.org".380
381
TLS Certificate Hostname of the TLS server.382
383
IPsec Certificate Hostname of the IPsec machine and/or, for IPv4384
or IPv6 addresses, the fully qualified domain385
name in the appropriate reverse domain.386
387
An alternate approach for IPsec is to store raw public keys [18].388
389
3.3. Content-Based OpenPGP CERT RR Names390
391
OpenPGP signed keys (certificates) use a general character string392
User ID [5]. However, it is recommended by OpenPGP that such names393
include the RFC 2822 [7] email address of the party, as in "Leslie394
Example <Leslie@host.example>". If such a format is used, the CERT395
ought to be under the standard translation of the email address into396
a domain name, which would be leslie.host.example in this case. If397
no RFC 2822 name can be extracted from the string name, no specific398
domain name is recommended.399
400
If a user has more than one email address, the CNAME type can be used401
to reduce the amount of data stored in the DNS. For example:402
403
$ORIGIN example.org.404
smith IN CERT PGP 0 0 <OpenPGP binary>405
john.smith IN CNAME smith406
js IN CNAME smith407
408
3.4. Purpose-Based OpenPGP CERT RR Names409
410
Applications that receive an OpenPGP packet containing encrypted or411
signed data but do not know the email address of the sender will have412
difficulties constructing the correct owner name and cannot use the413
content-based owner name guidelines. However, these clients commonly414
know the key fingerprint or the Key ID. The key ID is found in415
OpenPGP packets, and the key fingerprint is commonly found in416
auxiliary data that may be available. In this case, use of an owner417
name identical to the key fingerprint and the key ID expressed in418
hexadecimal [16] is recommended. For example:419
420
$ORIGIN example.org.421
0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...422
F835EDA21E94B565716F IN CERT PGP ...423
B565716F IN CERT PGP ...424
425
If the same key material is stored for several owner names, the use426
of CNAME may help avoid data duplication. Note that CNAME is not427
always applicable, because it maps one owner name to the other for428
all purposes, which may be sub-optimal when two keys with the same429
Key ID are stored.430
431
3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX432
433
These types are stored under the same owner names, both purpose- and434
content-based, as the PKIX, SPKI, PGP, and ACPKIX types.435
291 436
2924. Performance Considerations 4. Performance Considerations437
293 438
294 Current Domain Name System (DNS) implementations are optimized for The Domain Name System (DNS) protocol was designed for small439
295 small transfers, typically not more than 512 bytes including transfers, typically below 512 octets. While larger transfers will440
296 overhead. While larger transfers will perform correctly and work is perform correctly and work is underway to make larger transfers more441
297 underway to make larger transfers more efficient, it is still efficient, it is still advisable at this time that every reasonable442
298 advisable at this time to make every reasonable effort to minimize effort be made to minimize the size of certificates stored within the443
299 the size of certificates stored within the DNS. Steps that can be DNS. Steps that can be taken may include using the fewest possible444
300 taken may include using the fewest possible optional or extensions optional or extension fields and using short field values for445
301 fields and using short field values for variable length fields that necessary variable-length fields.446
302 must be included.
303 447
3045. IANA Considerations The RDATA field in the DNS protocol may only hold data of size 65535448
octets (64kb) or less. This means that each CERT RR MUST NOT contain449
more than 64kb of payload, even if the corresponding certificate or450
certificate revocation list is larger. This document addresses this451
by defining "indirect" data types for each normal type.452
305 453
306 Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can Deploying CERT RRs to support digitally signed email changes the454
307 only be assigned by an IETF standards action [7] (and this document access patterns of DNS lookups from per-domain to per-user. If455
308 assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE). Certificate digitally signed email and a key/certificate lookup based on CERT RRs456
309 types 0x0100 through 0xFEFF are assigned through IETF Consensus [7] are deployed on a wide scale, this may lead to an increased DNS load,457
310 based on RFC documentation of the certificate type. The availability with potential performance and cache effectiveness consequences.458
311 of private types under 0x00FD and 0x00FE should satisfy most Whether or not this load increase will be noticeable is not known.459
312 requirements for proprietary or private types.
313 460
3146. Security Considerations 5. Contributors461
462
The majority of this document is copied verbatim from RFC 2538, by463
Donald Eastlake 3rd and Olafur Gudmundsson.464
465
6. Acknowledgements466
467
Thanks to David Shaw and Michael Graff for their contributions to468
earlier works that motivated, and served as inspiration for, this469
document.470
471
This document was improved by suggestions and comments from Olivier472
Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.473
Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,474
Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel475
Weiler, Florian Weimer, and the IANA. No doubt the list is476
incomplete. We apologize to anyone we left out.477
478
7. Security Considerations479
315 480
316 By definition, certificates contain their own authenticating By definition, certificates contain their own authenticating481
317 signature. Thus it is reasonable to store certificates in non-secure signatures. Thus, it is reasonable to store certificates in non-482
318 DNS zones or to retrieve certificates from DNS with DNS security secure DNS zones or to retrieve certificates from DNS with DNS483
319 checking not implemented or deferred for efficiency. The results MAY security checking not implemented or deferred for efficiency. The484
320 be trusted if the certificate chain is verified back to a known results may be trusted if the certificate chain is verified back to a485
321 trusted key and this conforms with the user's security policy. known trusted key and this conforms with the user's security policy.486
322 487
323 Alternatively, if certificates are retrieved from a secure DNS zone Alternatively, if certificates are retrieved from a secure DNS zone488
324 with DNS security checking enabled and are verified by DNS security, with DNS security checking enabled and are verified by DNS security,489
325 the key within the retrieved certificate MAY be trusted without the key within the retrieved certificate may be trusted without490
326 verifying the certificate chain if this conforms with the user's verifying the certificate chain if this conforms with the user's491
327 security policy. security policy.492
328 493
329 CERT RRs are not used in connection with securing the DNS security If an organization chooses to issue certificates for its employees,494
330 additions so there are no security considerations related to CERT RRs placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)495
331 and securing the DNS itself. is in use, it is possible for someone to enumerate all employees of496
the organization. This is usually not considered desirable, for the497
same reason that enterprise phone listings are not often publicly498
published and are even marked confidential.499
332 500
3337. References Using the URI type introduces another level of indirection that may501
open a new vulnerability. One method of securing that indirection is502
to include a hash of the certificate in the URI itself.503
504
If DNSSEC is used, then the non-existence of a CERT RR and,505
consequently, certificates or revocation lists can be securely506
asserted. Without DNSSEC, this is not possible.507
508
8. IANA Considerations509
510
The IANA has created a new registry for CERT RR: certificate types.511
The initial contents of this registry is:512
513
Decimal Type Meaning Reference514
------- ---- ------- ---------515
0 Reserved RFC 4398516
1 PKIX X.509 as per PKIX RFC 4398517
2 SPKI SPKI certificate RFC 4398518
3 PGP OpenPGP packet RFC 4398519
4 IPKIX The URL of an X.509 data object RFC 4398520
5 ISPKI The URL of an SPKI certificate RFC 4398521
6 IPGP The fingerprint and URL RFC 4398522
of an OpenPGP packet523
7 ACPKIX Attribute Certificate RFC 4398524
8 IACPKIX The URL of an Attribute RFC 4398525
Certificate526
9-252 Available for IANA assignment527
by IETF Standards action528
253 URI URI private RFC 4398529
254 OID OID private RFC 4398530
255 Reserved RFC 4398531
256-65279 Available for IANA assignment532
by IETF Consensus533
65280-65534 Experimental RFC 4398534
65535 Reserved RFC 4398535
536
Certificate types 0x0000 through 0x00FF (255) and 0xFF00 (65280)537
through 0xFFFF (65535) can only be assigned by an IETF standards538
action [6]. This document assigns 0x0001 through 0x0008 and 0x00FD539
(253) and 0x00FE (254). Certificate types 0x0100 (256) through540
0xFEFF (65279) are assigned through IETF Consensus [6] based on RFC541
documentation of the certificate type. The availability of private542
types under 0x00FD (253) and 0x00FE (254) ought to satisfy most543
requirements for proprietary or private types.544
545
The CERT RR reuses the DNS Security Algorithm Numbers registry. In546
particular, the CERT RR requires that algorithm number 0 remain547
reserved, as described in Section 2. The IANA will reference the548
CERT RR as a user of this registry and value 0, in particular.549
550
9. Changes since RFC 2538551
552
1. Editorial changes to conform with new document requirements,553
including splitting reference section into two parts and554
updating the references to point at latest versions, and to add555
some additional references.556
2. Improve terminology. For example replace "PGP" with "OpenPGP",557
to align with RFC 2440.558
3. In Section 2.1, clarify that OpenPGP public key data are binary,559
not the ASCII armored format, and reference 10.1 in RFC 2440 on560
how to deal with OpenPGP keys, and acknowledge that561
implementations may handle additional packet types.562
4. Clarify that integers in the representation format are decimal.563
5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis564
terminology. Improve reference for Key Tag Algorithm565
calculations.566
6. Add examples that suggest use of CNAME to reduce bandwidth.567
7. In Section 3, appended the last paragraphs that discuss568
"content-based" vs "purpose-based" owner names. Add Section 3.2569
for purpose-based X.509 CERT owner names, and Section 3.4 for570
purpose-based OpenPGP CERT owner names.571
8. Added size considerations.572
9. The SPKI types has been reserved, until RFC 2692/2693 is moved573
from the experimental status.574
10. Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.575
11. An IANA registry of CERT type values was created.576
577
10. References578
579
10.1. Normative References580
334 581
335 [1] Mockapetris, P., "Domain names - concepts and facilities", [1] Mockapetris, P., "Domain names - concepts and facilities",582
336 STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.583
337 584
338 [2] Mockapetris, P., "Domain names - implementation and [2] Mockapetris, P., "Domain names - implementation and585
339 specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.586
340 587
341 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement588
342 Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.589
343 590
344 [4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri, [4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,591
345 "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,592
346 January 1998. January 1998.593
347 594
348 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,595
349 Resource Identifiers (URI): Generic Syntax", RFC 2396, "OpenPGP Message Format", RFC 2440, November 1998.596
350 August 1998.
351 597
352 [6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA598
353 Message Format", RFC 2440, November 1998. Considerations Section in RFCs", BCP 26, RFC 2434,599
October 1998.600
354 601
355 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.602
356 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
357 603
358 [8] Eastlake, D., "Domain Name System Security Extensions", [8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509604
359 RFC 2535, March 1999. Public Key Infrastructure Certificate and Certificate605
Revocation List (CRL) Profile", RFC 3280, April 2002.606
360 607
361 [9] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet X.509 [9] Farrell, S. and R. Housley, "An Internet Attribute Certificate608
362 Public Key Infrastructure Certificate and CRL Profile", Profile for Authorization", RFC 3281, April 2002.609
363 RFC 2459, January 1999. 610
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform611
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,612
January 2005.613
614
[11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,615
"DNS Security Introduction and Requirements", RFC 4033,616
March 2005.617
618
[12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,619
"Resource Records for the DNS Security Extensions", RFC 4034,620
March 2005.621
622
10.2. Informative References623
624
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",625
RFC 2246, January 1999.626
627
[14] Kent, S. and K. Seo, "Security Architecture for the Internet628
Protocol", RFC 4301, December 2005.629
630
[15] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,631
and T. Ylonen, "SPKI Certificate Theory", RFC 2693,632
September 1999.633
634
[16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",635
RFC 3548, July 2003.636
637
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions638
(S/MIME) Version 3.1 Message Specification", RFC 3851,639
July 2004.640
641
[18] Richardson, M., "A Method for Storing IPsec Keying Material in642
DNS", RFC 4025, March 2005.643
644
Appendix A. Copying Conditions645
646
Regarding the portion of this document that was written by Simon647
Josefsson ("the author", for the remainder of this section), the648
author makes no guarantees and is not responsible for any damage649
resulting from its use. The author grants irrevocable permission to650
anyone to use, modify, and distribute it in any way that does not651
diminish the rights of anyone else to use, modify, and distribute it,652
provided that redistributed derivative works do not contain653
misleading author or version information. Derivative works need not654
be licensed under similar terms.655
364 656
365Author's Address Author's Address657
366 658
367 Simon Josefsson Simon Josefsson659
368 660
369 Email: simon@josefsson.org Email: simon@josefsson.org661
370 662
371Intellectual Property Statement Intellectual Property Statement663
372 664
373 The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any665
skipping to change at page 11, line 41 skipping to change at page 17, line 41
397 This document and the information contained herein are provided on an This document and the information contained herein are provided on an689
398 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS690
399 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET691
400 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,692
401 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE693
402 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED694
403 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.695
404 696
405Copyright Statement Copyright Statement697
406 698
407 Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2006). This document is subject699
408 to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and700
409 except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.701
410 702
411Acknowledgment Acknowledgment703
412 704
413 Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the705
414 Internet Society. Internet Society.706
 End of changes. 60 change blocks. 
155 lines changed or deleted 447 lines changed or added

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