Diff: rfc2538.txt - rfc2538xml.txt

	rfc2538.txt	rfc2538xml.txt
1			1

2	Network Working Group D. Eastlake	Network Working Group S. Josefsson	2
3	Request for Comments: 2538 IBM		3
4	Category: Standards Track O. Gudmundsson	Expires: March 5, 2005	4
5	TIS Labs
6	March 1999
7			5
8	Storing Certificates in the Domain Name System (DNS)	Storing Certificates in the Domain Name System (DNS)	6

		rfc2538	7
9			8
10	Status of this Memo	Status of this Memo	9
11			10

12	This document specifies an Internet standards track protocol for the	By submitting this Internet-Draft, each author represents that any	11
13	Internet community, and requests discussion and suggestions for	applicable patent or other IPR claims of which he or she is aware	12
14	improvements. Please refer to the current edition of the "Internet	have been or will be disclosed, and any of which he or she becomes	13
15	Official Protocol Standards" (STD 1) for the standardization state	aware will be disclosed, in accordance with Section 6 of BCP 79.	14
16	and status of this protocol. Distribution of this memo is unlimited.		15
		Internet-Drafts are working documents of the Internet Engineering	16
		Task Force (IETF), its areas, and its working groups. Note that	17
		other groups may also distribute working documents as Internet-	18
		Drafts.	19
			20
		Internet-Drafts are draft documents valid for a maximum of six months	21
		and may be updated, replaced, or obsoleted by other documents at any	22
		time. It is inappropriate to use Internet-Drafts as reference	23
		material or to cite them other than as "work in progress."	24
			25
		The list of current Internet-Drafts can be accessed at	26
		http://www.ietf.org/ietf/1id-abstracts.txt.	27
			28
		The list of Internet-Draft Shadow Directories can be accessed at	29
		http://www.ietf.org/shadow.html.	30
			31
		This Internet-Draft will expire on March 5, 2005.	32
17			33
18	Copyright Notice	Copyright Notice	34
19			35

20	Copyright (C) The Internet Society (1999). All Rights Reserved.	Copyright (C) The Internet Society (2004).	36
21			37
22	Abstract	Abstract	38
23			39
24	Cryptographic public key are frequently published and their	Cryptographic public key are frequently published and their	40
25	authenticity demonstrated by certificates. A CERT resource record	authenticity demonstrated by certificates. A CERT resource record	41
26	(RR) is defined so that such certificates and related certificate	(RR) is defined so that such certificates and related certificate	42
27	revocation lists can be stored in the Domain Name System (DNS).	revocation lists can be stored in the Domain Name System (DNS).	43
28			44
29	Table of Contents	Table of Contents	45
30			46

31	Abstract...................................................1	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3	47
32	1. Introduction............................................2	2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3	48
33	2. The CERT Resource Record................................2	2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4	49
34	2.1 Certificate Type Values................................3	2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5	50
35	2.2 Text Representation of CERT RRs........................4	2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 5	51
36	2.3 X.509 OIDs.............................................4	3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6	52
37	3. Appropriate Owner Names for CERT RRs....................5	3.1. X.509 CERT RR Names . . . . . . . . . . . . . . . . . . . 6	53
38	3.1 X.509 CERT RR Names....................................5	3.2. PGP CERT RR Names . . . . . . . . . . . . . . . . . . . . 7	54
39	3.2 PGP CERT RR Names......................................6	4. Performance Considerations . . . . . . . . . . . . . . . . . . 7	55
40	4. Performance Considerations..............................6	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8	56
41	5. IANA Considerations.....................................7	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8	57
42	6. Security Considerations.................................7	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8	58
43	References.................................................8	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10	59
44	Authors' Addresses.........................................9	Intellectual Property and Copyright Statements . . . . . . . . . . 11	60
45	Full Copyright Notice.....................................10
46			61
47	1. Introduction	1. Introduction	62
48			63
49	Public keys are frequently published in the form of a certificate and	Public keys are frequently published in the form of a certificate and	64
50	their authenticity is commonly demonstrated by certificates and	their authenticity is commonly demonstrated by certificates and	65
51	related certificate revocation lists (CRLs). A certificate is a	related certificate revocation lists (CRLs). A certificate is a	66
52	binding, through a cryptographic digital signature, of a public key,	binding, through a cryptographic digital signature, of a public key,	67
53	a validity interval and/or conditions, and identity, authorization,	a validity interval and/or conditions, and identity, authorization,	68
54	or other information. A certificate revocation list is a list of	or other information. A certificate revocation list is a list of	69
55	certificates that are revoked, and incidental information, all signed	certificates that are revoked, and incidental information, all signed	70

	skipping to change at page 2, line 28	skipping to change at page 3, line 28
60	Section 2 below specifies a CERT resource record (RR) for the storage	Section 2 below specifies a CERT resource record (RR) for the storage	75
61	of certificates in the Domain Name System.	of certificates in the Domain Name System.	76
62			77
63	Section 3 discusses appropriate owner names for CERT RRs.	Section 3 discusses appropriate owner names for CERT RRs.	78
64			79
65	Sections 4, 5, and 6 below cover performance, IANA, and security	Sections 4, 5, and 6 below cover performance, IANA, and security	80
66	considerations, respectively.	considerations, respectively.	81
67			82
68	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	83
69	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	84

70	document are to be interpreted as described in [RFC2119].	document are to be interpreted as described in [3].	85
71			86
72	2. The CERT Resource Record	2. The CERT Resource Record	87
73			88
74	The CERT resource record (RR) has the structure given below. Its RR	The CERT resource record (RR) has the structure given below. Its RR	89
75	type code is 37.	type code is 37.	90
76			91
77	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 3	92
78	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 1	93
79	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	94
80	\| type \| key tag \|	\| type \| key tag \|	95
81	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	96
82	\| algorithm \| /	\| algorithm \| /	97
83	+---------------+ certificate or CRL /	+---------------+ certificate or CRL /	98
84	/ /	/ /	99
85	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\|	100
86			101
87	The type field is the certificate type as define in section 2.1	The type field is the certificate type as define in section 2.1	102
88	below.	below.	103
89			104
90	The algorithm field has the same meaning as the algorithm field in	The algorithm field has the same meaning as the algorithm field in	105

91	KEY and SIG RRs [RFC 2535] except that a zero algorithm field	KEY and SIG RRs [8] except that a zero algorithm field indicates the	106
92	indicates the algorithm is unknown to a secure DNS, which may simply	algorithm is unknown to a secure DNS, which may simply be the result	107
93	be the result of the algorithm not having been standardized for	of the algorithm not having been standardized for secure DNS.	108
94	secure DNS.
95			109
96	The key tag field is the 16 bit value computed for the key embedded	The key tag field is the 16 bit value computed for the key embedded	110

97	in the certificate as specified in the DNSSEC Standard [RFC 2535].	in the certificate as specified in the DNSSEC Standard [8]. This	111
98	This field is used as an efficiency measure to pick which CERT RRs	field is used as an efficiency measure to pick which CERT RRs may be	112
99	may be applicable to a particular key. The key tag can be calculated	applicable to a particular key. The key tag can be calculated for	113
100	for the key in question and then only CERT RRs with the same key tag	the key in question and then only CERT RRs with the same key tag need	114
101	need be examined. However, the key must always be transformed to the	be examined. However, the key must always be transformed to the	115
102	format it would have as the public key portion of a KEY RR before the	format it would have as the public key portion of a KEY RR before the	116
103	key tag is computed. This is only possible if the key is applicable	key tag is computed. This is only possible if the key is applicable	117
104	to an algorithm (and limits such as key size limits) defined for DNS	to an algorithm (and limits such as key size limits) defined for DNS	118
105	security. If it is not, the algorithm field MUST BE zero and the tag	security. If it is not, the algorithm field MUST BE zero and the tag	119
106	field is meaningless and SHOULD BE zero.	field is meaningless and SHOULD BE zero.	120
107			121

108	2.1 Certificate Type Values	2.1. Certificate Type Values	122
109			123
110	The following values are defined or reserved:	The following values are defined or reserved:	124
111			125
112	Value Mnemonic Certificate Type	Value Mnemonic Certificate Type	126
113	----- -------- ----------- ----	----- -------- ----------- ----	127
114	0 reserved	0 reserved	128
115	1 PKIX X.509 as per PKIX	1 PKIX X.509 as per PKIX	129
116	2 SPKI SPKI cert	2 SPKI SPKI cert	130
117	3 PGP PGP cert	3 PGP PGP cert	131
118	4-252 available for IANA assignment	4-252 available for IANA assignment	132

	skipping to change at page 3, line 44	skipping to change at page 4, line 44
125	to the profile being defined by the IETF PKIX working group. The	to the profile being defined by the IETF PKIX working group. The	139
126	certificate section will start with a one byte unsigned OID length	certificate section will start with a one byte unsigned OID length	140
127	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 the	141
128	certificate section (see 2.3 below). (NOTE: X.509 certificates do	certificate section (see 2.3 below). (NOTE: X.509 certificates do	142
129	not include their X.500 directory type designating OID as a prefix.)	not include their X.500 directory type designating OID as a prefix.)	143
130			144
131	The SPKI type is reserved to indicate a certificate formated as to be	The SPKI type is reserved to indicate a certificate formated as to be	145
132	specified by the IETF SPKI working group.	specified by the IETF SPKI working group.	146
133			147
134	The PGP type indicates a Pretty Good Privacy certificate as described	The PGP type indicates a Pretty Good Privacy certificate as described	148

135	in RFC 2440 and its extensions and successors.	in [6] and its extensions and successors.	149
136			150
137	The URI private type indicates a certificate format defined by an	The URI private type indicates a certificate format defined by an	151
138	absolute URI. The certificate portion of the CERT RR MUST begin with	absolute URI. The certificate portion of the CERT RR MUST begin with	152

139	a null terminated URI [RFC 2396] and the data after the null is the	a null terminated URI [5] and the data after the null is the private	153
140	private format certificate itself. The URI SHOULD be such that a	format certificate itself. The URI SHOULD be such that a retrieval	154
141	retrieval from it will lead to documentation on the format of the	from it will lead to documentation on the format of the certificate.	155
142	certificate. Recognition of private certificate types need not be	Recognition of private certificate types need not be based on URI	156
143	based on URI equality but can use various forms of pattern matching	equality but can use various forms of pattern matching so that, for	157
144	so that, for example, subtype or version information can also be	example, subtype or version information can also be encoded into the	158
145	encoded into the URI.	URI.	159
146			160
147	The OID private type indicates a private format certificate specified	The OID private type indicates a private format certificate specified	161
148	by a an ISO OID prefix. The certificate section will start with a	by a an ISO OID prefix. The certificate section will start with a	162
149	one byte unsigned OID length and then a BER encoded OID indicating	one byte unsigned OID length and then a BER encoded OID indicating	163
150	the nature of the remainder of the certificate section. This can be	the nature of the remainder of the certificate section. This can be	164
151	an X.509 certificate format or some other format. X.509 certificates	an X.509 certificate format or some other format. X.509 certificates	165
152	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 PKIX	166
153	type, not the OID private type. Recognition of private certificate	type, not the OID private type. Recognition of private certificate	167
154	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 of	168
155	pattern matching such as OID prefix.	pattern matching such as OID prefix.	169
156			170

157	2.2 Text Representation of CERT RRs	2.2. Text Representation of CERT RRs	171
158			172
159	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 unsigned	173
160	integer or as a mnemonic symbol as listed in section 2.1 above.	integer or as a mnemonic symbol as listed in section 2.1 above.	174
161			175
162	The key tag field is represented as an unsigned integer.	The key tag field is represented as an unsigned integer.	176
163			177
164	The algorithm field is represented as an unsigned integer or a	The algorithm field is represented as an unsigned integer or a	178

165	mnemonic symbol as listed in [RFC 2535].	mnemonic symbol as listed in [8].	179
166			180
167	The certificate / CRL portion is represented in base 64 and may be	The certificate / CRL portion is represented in base 64 and may be	181
168	divided up into any number of white space separated substrings, down	divided up into any number of white space separated substrings, down	182
169	to single base 64 digits, which are concatenated to obtain the full	to single base 64 digits, which are concatenated to obtain the full	183
170	signature. These substrings can span lines using the standard	signature. These substrings can span lines using the standard	184
171	parenthesis.	parenthesis.	185
172			186
173	Note that the certificate / CRL portion may have internal sub-fields	Note that the certificate / CRL portion may have internal sub-fields	187
174	but these do not appear in the master file representation. For	but these do not appear in the master file representation. For	188
175	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 then	189
176	the certificate / CRL proper. But only a single logical base 64	the certificate / CRL proper. But only a single logical base 64	190
177	string will appear in the text representation.	string will appear in the text representation.	191
178			192

179	2.3 X.509 OIDs	2.3. X.509 OIDs	193
180			194
181	OIDs have been defined in connection with the X.500 directory for	OIDs have been defined in connection with the X.500 directory for	195
182	user certificates, certification authority certificates, revocations	user certificates, certification authority certificates, revocations	196
183	of certification authority, and revocations of user certificates.	of certification authority, and revocations of user certificates.	197
184	The following table lists the OIDs, their BER encoding, and their	The following table lists the OIDs, their BER encoding, and their	198
185	length prefixed hex format for use in CERT RRs:	length prefixed hex format for use in CERT RRs:	199
186			200
187	id-at-userCertificate	id-at-userCertificate	201
188	= { joint-iso-ccitt(2) ds(5) at(4) 36 }	= { joint-iso-ccitt(2) ds(5) at(4) 36 }	202
189	== 0x 03 55 04 24	== 0x 03 55 04 24	203

	skipping to change at page 5, line 31	skipping to change at page 6, line 31
203	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 intended	217
204	to control the private key corresponding to the public key being	to control the private key corresponding to the public key being	218
205	certified. It is recommended that certificate revocation list CERT	certified. It is recommended that certificate revocation list CERT	219
206	RRs be stored under a domain name related to their issuer.	RRs be stored under a domain name related to their issuer.	220
207			221
208	Following some of the guidelines below may result in the use in DNS	Following some of the guidelines below may result in the use in DNS	222
209	names of characters that require DNS quoting which is to use a	names of characters that require DNS quoting which is to use a	223
210	backslash followed by the octal representation of the ASCII code for	backslash followed by the octal representation of the ASCII code for	224
211	the character such as \000 for NULL.	the character such as \000 for NULL.	225
212			226

213	3.1 X.509 CERT RR Names	3.1. X.509 CERT RR Names	227
214			228
215	Some X.509 versions permit multiple names to be associated with	Some X.509 versions permit multiple names to be associated with	229
216	subjects and issuers under "Subject Alternate Name" and "Issuer	subjects and issuers under "Subject Alternate Name" and "Issuer	230
217	Alternate Name". For example, x.509v3 has such Alternate Names with	Alternate Name". For example, x.509v3 has such Alternate Names with	231
218	an ASN.1 specification as follows:	an ASN.1 specification as follows:	232
219			233
220	GeneralName ::= CHOICE {	GeneralName ::= CHOICE {	234
221	otherName [0] INSTANCE OF OTHER-NAME,	otherName [0] INSTANCE OF OTHER-NAME,	235
222	rfc822Name [1] IA5String,	rfc822Name [1] IA5String,	236
223	dNSName [2] IA5String,	dNSName [2] IA5String,	237

	skipping to change at page 6, line 5	skipping to change at page 7, line 5
225	directoryName [4] EXPLICIT Name,	directoryName [4] EXPLICIT Name,	239
226	ediPartyName [5] EDIPartyName,	ediPartyName [5] EDIPartyName,	240
227	uniformResourceIdentifier [6] IA5String,	uniformResourceIdentifier [6] IA5String,	241
228	iPAddress [7] OCTET STRING,	iPAddress [7] OCTET STRING,	242
229	registeredID [8] OBJECT IDENTIFIER	registeredID [8] OBJECT IDENTIFIER	243
230	}	}	244
231			245
232	The recommended locations of CERT storage are as follows, in priority	The recommended locations of CERT storage are as follows, in priority	246
233	order:	order:	247
234			248

235	(1) If a domain name is included in the identification in the	1. If a domain name is included in the identification in the	249
236	certificate or CRL, that should be used.	certificate or CRL, that should be used.	250

237	(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,	251
238	then the translation of that IP address into the appropriate	then the translation of that IP address into the appropriate	252
239	inverse domain name should be used.	inverse domain name should be used.	253

240	(3) If neither of the above it used but a URI containing a domain	3. If neither of the above it used but a URI containing a domain	254
241	name is present, that domain name should be used.	name is present, that domain name should be used.	255

242	(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 is	256
243	included, then it should be treated as described for PGP names in	included, then it should be treated as described for PGP names in	257
244	3.2 below.	3.2 below.	258

245	(5) If none of the above apply, then the distinguished name (DN)	5. If none of the above apply, then the distinguished name (DN)	259
246	should be mapped into a domain name as specified in RFC 2247.	should be mapped into a domain name as specified in [4].	260
247			261
248	Example 1: Assume that an X.509v3 certificate is issued to /CN=John	Example 1: Assume that an X.509v3 certificate is issued to /CN=John	262
249	Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative	Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative	263
250	names of (a) string "John (the Man) Doe", (b) domain name john-	names of (a) string "John (the Man) Doe", (b) domain name john-	264
251	doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>. Then	doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>. Then	265
252	the storage locations recommended, in priority order, would be	the storage locations recommended, in priority order, would be	266

253	(1) john-doe.com,	1. john-doe.com,	267
254	(2) www.secure.john-doe.com, and	2. www.secure.john-doe.com, and	268
255	(3) Doe.com.xy.	3. Doe.com.xy.	269
256			270
257	Example 2: Assume that an X.509v3 certificate is issued to /CN=James	Example 2: Assume that an X.509v3 certificate is issued to /CN=James	271
258	Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names	Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names	272
259	of (a) domain name widget.foo.example, (b) IPv4 address	of (a) domain name widget.foo.example, (b) IPv4 address	273
260	10.251.13.201, and (c) string "James Hacker	10.251.13.201, and (c) string "James Hacker	274
261	<hacker@mail.widget.foo.example>". Then the storage locations	<hacker@mail.widget.foo.example>". Then the storage locations	275
262	recommended, in priority order, would be	recommended, in priority order, would be	276

263	(1) widget.foo.example,	1. widget.foo.example,	277
264	(2) 201.13.251.10.in-addr.arpa, and	2. 201.13.251.10.in-addr.arpa, and	278
265	(3) hacker.mail.widget.foo.example.	3. hacker.mail.widget.foo.example.	279
266			280

267	3.2 PGP CERT RR Names	3.2. PGP CERT RR Names	281
268			282
269	PGP signed keys (certificates) use a general character string User ID	PGP signed keys (certificates) use a general character string User ID	283

270	[RFC 2440]. However, it is recommended by PGP that such names include	[6]. However, it is recommended by PGP that such names include the	284
271	the RFC 822 email address of the party, as in "Leslie Example	RFC 822 email address of the party, as in "Leslie Example	285
272	<Leslie@host.example>". If such a format is used, the CERT should be	<Leslie@host.example>". If such a format is used, the CERT should be	286
273	under the standard translation of the email address into a domain	under the standard translation of the email address into a domain	287
274	name, which would be leslie.host.example in this case. If no RFC 822	name, which would be leslie.host.example in this case. If no RFC 822	288
275	name can be extracted from the string name no specific domain name is	name can be extracted from the string name no specific domain name is	289
276	recommended.	recommended.	290
277			291
278	4. Performance Considerations	4. Performance Considerations	292
279			293
280	Current Domain Name System (DNS) implementations are optimized for	Current Domain Name System (DNS) implementations are optimized for	294
281	small transfers, typically not more than 512 bytes including	small transfers, typically not more than 512 bytes including	295

	skipping to change at page 7, line 14	skipping to change at page 8, line 15
283	underway to make larger transfers more efficient, it is still	underway to make larger transfers more efficient, it is still	297
284	advisable at this time to make every reasonable effort to minimize	advisable at this time to make every reasonable effort to minimize	298
285	the size of certificates stored within the DNS. Steps that can be	the size of certificates stored within the DNS. Steps that can be	299
286	taken may include using the fewest possible optional or extensions	taken may include using the fewest possible optional or extensions	300
287	fields and using short field values for variable length fields that	fields and using short field values for variable length fields that	301
288	must be included.	must be included.	302
289			303
290	5. IANA Considerations	5. IANA Considerations	304
291			305
292	Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can	Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can	306

293	only be assigned by an IETF standards action [RFC 2434] (and this	only be assigned by an IETF standards action [7] (and this document	307
294	document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE).	assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE). Certificate	308
295	Certificate types 0x0100 through 0xFEFF are assigned through IETF	types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]	309
296	Consensus [RFC 2434] based on RFC documentation of the certificate	based on RFC documentation of the certificate type. The availability	310
297	type. The availability of private types under 0x00FD and 0x00FE	of private types under 0x00FD and 0x00FE should satisfy most	311
298	should satisfy most requirements for proprietary or private types.	requirements for proprietary or private types.	312
299			313
300	6. Security Considerations	6. Security Considerations	314
301			315
302	By definition, certificates contain their own authenticating	By definition, certificates contain their own authenticating	316
303	signature. Thus it is reasonable to store certificates in non-secure	signature. Thus it is reasonable to store certificates in non-secure	317
304	DNS zones or to retrieve certificates from DNS with DNS security	DNS zones or to retrieve certificates from DNS with DNS security	318
305	checking not implemented or deferred for efficiency. The results MAY	checking not implemented or deferred for efficiency. The results MAY	319
306	be trusted if the certificate chain is verified back to a known	be trusted if the certificate chain is verified back to a known	320
307	trusted key and this conforms with the user's security policy.	trusted key and this conforms with the user's security policy.	321
308			322
309	Alternatively, if certificates are retrieved from a secure DNS zone	Alternatively, if certificates are retrieved from a secure DNS zone	323
310	with DNS security checking enabled and are verified by DNS security,	with DNS security checking enabled and are verified by DNS security,	324
311	the key within the retrieved certificate MAY be trusted without	the key within the retrieved certificate MAY be trusted without	325
312	verifying the certificate chain if this conforms with the user's	verifying the certificate chain if this conforms with the user's	326
313	security policy.	security policy.	327
314			328
315	CERT RRs are not used in connection with securing the DNS security	CERT RRs are not used in connection with securing the DNS security	329
316	additions so there are no security considerations related to CERT RRs	additions so there are no security considerations related to CERT RRs	330
317	and securing the DNS itself.	and securing the DNS itself.	331
318			332

319	References	7. References	333
320			334

321	RFC 1034 Mockapetris, P., "Domain Names - Concepts and Facilities",	[1] Mockapetris, P., "Domain names - concepts and facilities",	335
322	STD 13, RFC 1034, November 1987.	STD 13, RFC 1034, November 1987.	336
323			337

324	RFC 1035 Mockapetris, P., "Domain Names - Implementation and	[2] Mockapetris, P., "Domain names - implementation and	338
325	Specifications", STD 13, RFC 1035, November 1987.	specification", STD 13, RFC 1035, November 1987.	339
326			340

327	RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate	[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement	341
328	Requirement Levels", BCP 14, RFC 2119, March 1997.	Levels", BCP 14, RFC 2119, March 1997.	342
329			343

330	RFC 2247 Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.	[4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,	344
331	Sataluri, "Using Domains in LDAP/X.500 Distinguished	"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,	345
332	Names", RFC 2247, January 1998.	January 1998.	346
333			347

334	RFC 2396 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform	[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform	348
335	Resource Identifiers (URI): Generic Syntax", RFC 2396,	Resource Identifiers (URI): Generic Syntax", RFC 2396,	349
336	August 1998.	August 1998.	350
337			351

338	RFC 2440 Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,	[6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP	352
339	"OpenPGP Message Format", RFC 2240, November 1998.	Message Format", RFC 2440, November 1998.	353
340			354

341	RFC 2434 Narten, T. and H. Alvestrand, "Guidelines for Writing an	[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA	355
342	IANA Considerations Section in RFCs", BCP 26, RFC 2434,	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.	356
343	October 1998.
344			357

345	RFC 2535 Eastlake, D., "Domain Name System (DNS) Security	[8] Eastlake, D., "Domain Name System Security Extensions",	358
346	Extensions", RFC 2535, March 1999.	RFC 2535, March 1999.	359
347			360

348	RFC 2459 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet	[9] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet X.509	361
349	X.509 Public Key Infrastructure Certificate and CRL	Public Key Infrastructure Certificate and CRL Profile",	362
350	Profile", RFC 2459, January 1999.	RFC 2459, January 1999.	363
351			364

352	Authors' Addresses	Author's Address	365
353			366

354	Donald E. Eastlake 3rd	Simon Josefsson	367
355	IBM
356	65 Shindegan Hill Road
357	RR#1
358	Carmel, NY 10512 USA
359			368

360	Phone: +1-914-784-7913 (w)	Email: simon@josefsson.org	369
361	+1-914-276-2668 (h)
362	Fax: +1-914-784-3833 (w-fax)
363	EMail: dee3@us.ibm.com
364			370

365	Olafur Gudmundsson	Intellectual Property Statement	371
366	TIS Labs at Network Associates
367	3060 Washington Rd, Route 97
368	Glenwood MD 21738
369			372

370	Phone: +1 443-259-2389	The IETF takes no position regarding the validity or scope of any	373
371	EMail: ogud@tislabs.com	Intellectual Property Rights or other rights that might be claimed to	374
		pertain to the implementation or use of the technology described in	375
		this document or the extent to which any license under such rights	376
		might or might not be available; nor does it represent that it has	377
		made any independent effort to identify any such rights. Information	378
		on the procedures with respect to rights in RFC documents can be	379
		found in BCP 78 and BCP 79.	380
372			381

373	Full Copyright Statement	Copies of IPR disclosures made to the IETF Secretariat and any	382
		assurances of licenses to be made available, or the result of an	383
		attempt made to obtain a general license or permission for the use of	384
		such proprietary rights by implementers or users of this	385
		specification can be obtained from the IETF on-line IPR repository at	386
		http://www.ietf.org/ipr.	387
374			388

375	Copyright (C) The Internet Society (1999). All Rights Reserved.	The IETF invites any interested party to bring to its attention any	389
		copyrights, patents or patent applications, or other proprietary	390
		rights that may cover technology that may be required to implement	391
		this standard. Please address the information to the IETF at	392
		ietf-ipr@ietf.org.	393
376			394

377	This document and translations of it may be copied and furnished to	Disclaimer of Validity	395
378	others, and derivative works that comment on or otherwise explain it
379	or assist in its implementation may be prepared, copied, published
380	and distributed, in whole or in part, without restriction of any
381	kind, provided that the above copyright notice and this paragraph are
382	included on all such copies and derivative works. However, this
383	document itself may not be modified in any way, such as by removing
384	the copyright notice or references to the Internet Society or other
385	Internet organizations, except as needed for the purpose of
386	developing Internet standards in which case the procedures for
387	copyrights defined in the Internet Standards process must be
388	followed, or as required to translate it into languages other than
389	English.
390			396

391	The limited permissions granted above are perpetual and will not be	This document and the information contained herein are provided on an	397
392	revoked by the Internet Society or its successors or assigns.	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS	398
		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET	399
		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,	400
		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE	401
		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED	402
		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.	403
393			404

394	This document and the information contained herein is provided on an	Copyright Statement	405
395	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		406
396	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING	Copyright (C) The Internet Society (2004). This document is subject	407
397	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION	to the rights, licenses and restrictions contained in BCP 78, and	408
398	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF	except as set forth therein, the authors retain all their rights.	409
399	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		410
		Acknowledgment	411
			412
		Funding for the RFC Editor function is currently provided by the	413
		Internet Society.	414

End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/