Diff: rfc2538xml.txt - draft-josefsson-rfc2538bis.txt

	rfc2538xml.txt	draft-josefsson-rfc2538bis.txt
1			1
2	Network Working Group S. Josefsson	Network Working Group S. Josefsson	2
3			3
4	Expires: March 2, 2005	Expires: July 25, 2005	4
5			5
6	Storing Certificates in the Domain Name System (DNS)	Storing Certificates in the Domain Name System (DNS)	6
7	rfc2538	draft-josefsson-rfc2538bis-02	7
8			8
9	Status of this Memo	Status of this Memo	9
10			10
11	This document is an Internet-Draft and is subject to all provisions	This document is an Internet-Draft and is subject to all provisions	11
12	of section 3 of RFC 3667. By submitting this Internet-Draft, each	of section 3 of RFC 3667. By submitting this Internet-Draft, each	12
13	author represents that any applicable patent or other IPR claims of	author represents that any applicable patent or other IPR claims of	13
14	which he or she is aware have been or will be disclosed, and any of	which he or she is aware have been or will be disclosed, and any of	14
15	which he or she become aware will be disclosed, in accordance with	which he or she become aware will be disclosed, in accordance with	15
16	RFC 3668.	RFC 3668.	16
17			17

	skipping to change at page 1, line 35	skipping to change at page 1, line 35
24	and may be updated, replaced, or obsoleted by other documents at any	and may be updated, replaced, or obsoleted by other documents at any	24
25	time. It is inappropriate to use Internet-Drafts as reference	time. It is inappropriate to use Internet-Drafts as reference	25
26	material or to cite them other than as "work in progress."	material or to cite them other than as "work in progress."	26
27			27
28	The list of current Internet-Drafts can be accessed at	The list of current Internet-Drafts can be accessed at	28
29	http://www.ietf.org/ietf/1id-abstracts.txt.	http://www.ietf.org/ietf/1id-abstracts.txt.	29
30			30
31	The list of Internet-Draft Shadow Directories can be accessed at	The list of Internet-Draft Shadow Directories can be accessed at	31
32	http://www.ietf.org/shadow.html.	http://www.ietf.org/shadow.html.	32
33			33
34	This Internet-Draft will expire on March 2, 2005.	This Internet-Draft will expire on July 25, 2005.	34
35			35
36	Copyright Notice	Copyright Notice	36
37			37
38	Copyright (C) The Internet Society (2004).	Copyright (C) The Internet Society (2005).	38
39			39
40	Abstract	Abstract	40
41			41
42	Cryptographic public key are frequently published and their	Cryptographic public key are frequently published and their	42
43	authenticity demonstrated by certificates. A CERT resource record	authenticity demonstrated by certificates. A CERT resource record	43
44	(RR) is defined so that such certificates and related certificate	(RR) is defined so that such certificates and related certificate	44
45	revocation lists can be stored in the Domain Name System (DNS).	revocation lists can be stored in the Domain Name System (DNS).	45
46			46
		More information on this document, including rfcdiff output, may be	47
		found at <http://josefsson.org/rfc2538bis/>.	48
			49
47	Table of Contents	Table of Contents	50
48			51
49	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3	52
50	2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3	2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3	53
51	2.1 Certificate Type Values . . . . . . . . . . . . . . . . . 4	2.1 Certificate Type Values . . . . . . . . . . . . . . . . . 4	54
52	2.2 Text Representation of CERT RRs . . . . . . . . . . . . . 5	2.2 Text Representation of CERT RRs . . . . . . . . . . . . . 5	55
53	2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 5	2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 5	56
54	3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6	3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6	57
55	3.1 X.509 CERT RR Names . . . . . . . . . . . . . . . . . . . 6	3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7	58
56	3.2 PGP CERT RR Names . . . . . . . . . . . . . . . . . . . . 7	3.2 Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8	59
57	4. Performance Considerations . . . . . . . . . . . . . . . . . . 7	3.3 Content-based PGP CERT RR Names . . . . . . . . . . . . . 8	60
58	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8	3.4 Purpose-based PGP CERT RR Names . . . . . . . . . . . . . 9	61
59	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8	4. Performance Considerations . . . . . . . . . . . . . . . . . . 9	62
60	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8	5. Size Considerations . . . . . . . . . . . . . . . . . . . . . 9	63
61	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10	64
62	Intellectual Property and Copyright Statements . . . . . . . . 10	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10	65
		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10	66
		9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11	67
		10. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . 11	68
		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12	69
		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11	70
		11.1 Normative References . . . . . . . . . . . . . . . . . . . . 11	71
		11.2 Informative References . . . . . . . . . . . . . . . . . . . 12	72
		A. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 12	73
		Intellectual Property and Copyright Statements . . . . . . . . 13	74
63			75
64	1. Introduction	1. Introduction	76
65			77
66	Public keys are frequently published in the form of a certificate and	Public keys are frequently published in the form of a certificate and	78
67	their authenticity is commonly demonstrated by certificates and	their authenticity is commonly demonstrated by certificates and	79
68	related certificate revocation lists (CRLs). A certificate is a	related certificate revocation lists (CRLs). A certificate is a	80
69	binding, through a cryptographic digital signature, of a public key,	binding, through a cryptographic digital signature, of a public key,	81
70	a validity interval and/or conditions, and identity, authorization,	a validity interval and/or conditions, and identity, authorization,	82
71	or other information. A certificate revocation list is a list of	or other information. A certificate revocation list is a list of	83
72	certificates that are revoked, and incidental information, all signed	certificates that are revoked, and incidental information, all signed	84
73	by the signer (issuer) of the revoked certificates. Examples are	by the signer (issuer) of the revoked certificates. Examples are	85
74	X.509 certificates/CRLs in the X.500 directory system or PGP	X.509 certificates/CRLs in the X.500 directory system or OpenPGP	86
75	certificates/revocations used by PGP software.	certificates/revocations used by OpenPGP software.	87
76			88
77	Section 2 below specifies a CERT resource record (RR) for the storage	Section 2 below specifies a CERT resource record (RR) for the storage	89
78	of certificates in the Domain Name System.	of certificates in the Domain Name System.	90
79			91
80	Section 3 discusses appropriate owner names for CERT RRs.	Section 3 discusses appropriate owner names for CERT RRs.	92
81			93
82	Sections 4, 5, and 6 below cover performance, IANA, and security	Sections 4, 5, and 6 below cover performance, IANA, and security	94
83	considerations, respectively.	considerations, respectively.	95
84			96
85	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	97
86	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	98
87	document are to be interpreted as described in [3].	document are to be interpreted as described in [10].	99
88			100
89	2. The CERT Resource Record	2. The CERT Resource Record	101
90			102
91	The CERT resource record (RR) has the structure given below. Its RR	The CERT resource record (RR) has the structure given below. Its RR	103
92	type code is 37.	type code is 37.	104
93			105
94	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	106
95	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	107
96	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	108
97	\| type \| key tag \|	\| type \| key tag \|	109
98	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	110
99	\| algorithm \| /	\| algorithm \| /	111
100	+---------------+ certificate or CRL /	+---------------+ certificate or CRL /	112
101	/ /	/ /	113
102	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\|	114
103			115
104	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	116
105	below.	below.	117
106			118
107	The algorithm field has the same meaning as the algorithm field in	The algorithm field has the same meaning as the algorithm field in	119
108	KEY and SIG RRs [8] except that a zero algorithm field indicates the	DNSKEY and RRSIG RRs [9] except that a zero algorithm field indicates	120
109	algorithm is unknown to a secure DNS, which may simply be the result	the algorithm is unknown to a secure DNS, which may simply be the	121
110	of the algorithm not having been standardized for secure DNS.	result of the algorithm not having been standardized for DNSSEC.	122
111			123
112	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	124
113	in the certificate as specified in the DNSSEC Standard [8]. This	in the certificate, using the RRSIG Key Tag Algorithm described in	125
114	field is used as an efficiency measure to pick which CERT RRs may be	Appendix B of [9]. This field is used as an efficiency measure to	126
115	applicable to a particular key. The key tag can be calculated for	pick which CERT RRs may be applicable to a particular key. The key	127
116	the key in question and then only CERT RRs with the same key tag need	tag can be calculated for the key in question and then only CERT RRs	128
117	be examined. However, the key must always be transformed to the	with the same key tag need be examined. However, the key must always	129
118	format it would have as the public key portion of a KEY RR before the	be transformed to the format it would have as the public key portion	130
119	key tag is computed. This is only possible if the key is applicable	of a DNSKEY RR before the key tag is computed. This is only possible	131
120	to an algorithm (and limits such as key size limits) defined for DNS	if the key is applicable to an algorithm (and limits such as key size	132
121	security. If it is not, the algorithm field MUST BE zero and the tag	limits) defined for DNS security. If it is not, the algorithm field	133
122	field is meaningless and SHOULD BE zero.	MUST BE zero and the tag field is meaningless and SHOULD BE zero.	134
123			135
124	2.1 Certificate Type Values	2.1 Certificate Type Values	136
125			137
126	The following values are defined or reserved:	The following values are defined or reserved:	138
127			139
128	Value Mnemonic Certificate Type	Value Mnemonic Certificate Type	140
129	----- -------- ----------- ----	----- -------- ----------- ----	141
130	0 reserved	0 reserved	142
131	1 PKIX X.509 as per PKIX	1 PKIX X.509 as per PKIX	143
132	2 SPKI SPKI cert	2 SPKI SPKI certificate	144
133	3 PGP PGP cert	3 PGP OpenPGP packet	145
134	4-252 available for IANA assignment	4-252 available for IANA assignment	146
135	253 URI URI private	253 URI URI private	147
136	254 OID OID private	254 OID OID private	148
137	255-65534 available for IANA assignment	255-65534 available for IANA assignment	149
138	65535 reserved	65535 reserved	150
139			151
140	The PKIX type is reserved to indicate an X.509 certificate conforming	The PKIX type is reserved to indicate an X.509 certificate conforming	152
141	to the profile being defined by the IETF PKIX working group. The	to the profile being defined by the IETF PKIX working group. The	153
142	certificate section will start with a one byte unsigned OID length	certificate section will start with a one byte unsigned OID length	154
143	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	155
144	certificate section (see 2.3 below). (NOTE: X.509 certificates do	certificate section (see 2.3 below). (NOTE: X.509 certificates do	156
145	not include their X.500 directory type designating OID as a prefix.)	not include their X.500 directory type designating OID as a prefix.)	157
146			158
147	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	159
148	specified by the IETF SPKI working group.	specified by the IETF SPKI working group.	160
149			161
150	The PGP type indicates a Pretty Good Privacy certificate as described	The PGP type indicates an OpenPGP packet as described in [5] and its	162
151	in [6] and its extensions and successors.	extensions and successors. Two uses are to transfer public key	163
		material and revocation signatures. The data is binary, and MUST NOT	164
		be encoded into an ASCII armor. An implementation SHOULD process	165
		transferable public keys as described in section 10.1 of [5], but it	166
		MAY handle additional OpenPGP packets.	167
152			168
153	The URI private type indicates a certificate format defined by an	The URI private type indicates a certificate format defined by an	169
154	absolute URI. The certificate portion of the CERT RR MUST begin with	absolute URI. The certificate portion of the CERT RR MUST begin with	170
155	a null terminated URI [5] and the data after the null is the private	a null terminated URI [4] and the data after the null is the private	171
156	format certificate itself. The URI SHOULD be such that a retrieval	format certificate itself. The URI SHOULD be such that a retrieval	172
157	from it will lead to documentation on the format of the certificate.	from it will lead to documentation on the format of the certificate.	173
158	Recognition of private certificate types need not be based on URI	Recognition of private certificate types need not be based on URI	174
159	equality but can use various forms of pattern matching so that, for	equality but can use various forms of pattern matching so that, for	175
160	example, subtype or version information can also be encoded into the	example, subtype or version information can also be encoded into the	176
161	URI.	URI.	177
162			178
163	The OID private type indicates a private format certificate specified	The OID private type indicates a private format certificate specified	179
164	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	180
165	one byte unsigned OID length and then a BER encoded OID indicating	one byte unsigned OID length and then a BER encoded OID indicating	181
166	the nature of the remainder of the certificate section. This can be	the nature of the remainder of the certificate section. This can be	182
167	an X.509 certificate format or some other format. X.509 certificates	an X.509 certificate format or some other format. X.509 certificates	183
168	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	184
169	type, not the OID private type. Recognition of private certificate	type, not the OID private type. Recognition of private certificate	185
170	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	186
171	pattern matching such as OID prefix.	pattern matching such as OID prefix.	187
172			188
173	2.2 Text Representation of CERT RRs	2.2 Text Representation of CERT RRs	189
174			190
175	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	191
176	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	192
		above.	193
177			194
178	The key tag field is represented as an unsigned integer.	The key tag field is represented as an unsigned decimal integer.	195
179			196
180	The algorithm field is represented as an unsigned integer or a	The algorithm field is represented as an unsigned decimal integer or	197
181	mnemonic symbol as listed in [8].	a mnemonic symbol as listed in [9].	198
182			199
183	The certificate / CRL portion is represented in base 64 and may be	The certificate / CRL portion is represented in base 64 [11] and may	200
184	divided up into any number of white space separated substrings, down	be divided up into any number of white space separated substrings,	201
185	to single base 64 digits, which are concatenated to obtain the full	down to single base 64 digits, which are concatenated to obtain the	202
186	signature. These substrings can span lines using the standard	full signature. These substrings can span lines using the standard	203
187	parenthesis.	parenthesis.	204
188			205
189	Note that the certificate / CRL portion may have internal sub-fields	Note that the certificate / CRL portion may have internal sub-fields	206
190	but these do not appear in the master file representation. For	but these do not appear in the master file representation. For	207
191	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	208
192	the certificate / CRL proper. But only a single logical base 64	the certificate / CRL proper. But only a single logical base 64	209
193	string will appear in the text representation.	string will appear in the text representation.	210
194			211
195	2.3 X.509 OIDs	2.3 X.509 OIDs	212
196			213

	skipping to change at page 6, line 31	skipping to change at page 6, line 31
219	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	236
220	to control the private key corresponding to the public key being	to control the private key corresponding to the public key being	237
221	certified. It is recommended that certificate revocation list CERT	certified. It is recommended that certificate revocation list CERT	238
222	RRs be stored under a domain name related to their issuer.	RRs be stored under a domain name related to their issuer.	239
223			240
224	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	241
225	names of characters that require DNS quoting which is to use a	names of characters that require DNS quoting which is to use a	242
226	backslash followed by the octal representation of the ASCII code for	backslash followed by the octal representation of the ASCII code for	243
227	the character such as \000 for NULL.	the character such as \000 for NULL.	244
228			245
229	3.1 X.509 CERT RR Names	The choice of name under which CERT RRs are stored is important to	246
		clients that perform CERT queries. In some situations, the client	247
		may not know all information about the CERT RR object it wishes to	248
		retrieve. For example, a client may not know the subject name of an	249
		X.509 certificate, or the e-mail address of the owner of an OpenPGP	250
		key. Further, the client may only know the hostname of a service	251
		that uses X.509 certificates or the OpenPGP key id of an OpenPGP key.	252
			253
		This motivate describing two different owner name guidelines. We	254
		call the two rules content-based owner names and purpose-based owner	255
		names. A content-based owner name is derived from the content of the	256
		CERT RR data; for example the Subject field in an X.509 certificate	257
		or the User ID field in OpenPGP keys. A purpose-based owner name is	258
		selected to be a name that clients that wishes to retrieve CERT RRs	259
		knows; for example the host name of a X.509 protected service or a	260
		OpenPGP key id of an OpenPGP key. Note that in some situations, the	261
		content-based and purpose-based owner name can be the same; for	262
		example when a client look up keys based on e-mail addresses for	263
		incoming e-mail.	264
			265
		[Editorial note: Purpose-based owner name guidelines were introduced	266
		in RFC 2538bis. Earlier, in RFC 2538, only content-based owner name	267
		guidelines were described. Implementation experience suggested that	268
		the content-based owner name guidelines were not generally	269
		applicable. It was realized that purpose-based owner name guidelines	270
		were required to use CERT RRs in some ways.]	271
			272
		3.1 Content-based X.509 CERT RR Names	273
230			274
231	Some X.509 versions permit multiple names to be associated with	Some X.509 versions permit multiple names to be associated with	275
232	subjects and issuers under "Subject Alternate Name" and "Issuer	subjects and issuers under "Subject Alternate Name" and "Issuer	276
233	Alternate Name". For example, x.509v3 has such Alternate Names with	Alternate Name". For example, x.509v3 has such Alternate Names with	277
234	an ASN.1 specification as follows:	an ASN.1 specification as follows:	278
235			279
236	GeneralName ::= CHOICE {	GeneralName ::= CHOICE {	280
237	otherName [0] INSTANCE OF OTHER-NAME,	otherName [0] INSTANCE OF OTHER-NAME,	281
238	rfc822Name [1] IA5String,	rfc822Name [1] IA5String,	282
239	dNSName [2] IA5String,	dNSName [2] IA5String,	283

	skipping to change at page 7, line 16	skipping to change at page 7, line 42
252	certificate or CRL, that should be used.	certificate or CRL, that should be used.	295
253	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,	296
254	then the translation of that IP address into the appropriate	then the translation of that IP address into the appropriate	297
255	inverse domain name should be used.	inverse domain name should be used.	298
256	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	299
257	name is present, that domain name should be used.	name is present, that domain name should be used.	300
258	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	301
259	included, then it should be treated as described for PGP names in	included, then it should be treated as described for PGP names in	302
260	3.2 below.	3.2 below.	303
261	5. If none of the above apply, then the distinguished name (DN)	5. If none of the above apply, then the distinguished name (DN)	304
262	should be mapped into a domain name as specified in [4].	should be mapped into a domain name as specified in [3].	305
263			306
264	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	307
265	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	308
266	names of (a) string "John (the Man) Doe", (b) domain name john-	names of (a) string "John (the Man) Doe", (b) domain name john-	309
267	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	310
268	the storage locations recommended, in priority order, would be	the storage locations recommended, in priority order, would be	311
269	1. john-doe.com,	1. john-doe.com,	312
270	2. www.secure.john-doe.com, and	2. www.secure.john-doe.com, and	313
271	3. Doe.com.xy.	3. Doe.com.xy.	314
272			315
273	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	316
274	Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names	Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names	317
275	of (a) domain name widget.foo.example, (b) IPv4 address	of (a) domain name widget.foo.example, (b) IPv4 address	318
276	10.251.13.201, and (c) string "James Hacker	10.251.13.201, and (c) string "James Hacker	319
277	<hacker@mail.widget.foo.example>". Then the storage locations	<hacker@mail.widget.foo.example>". Then the storage locations	320
278	recommended, in priority order, would be	recommended, in priority order, would be	321
279	1. widget.foo.example,	1. widget.foo.example,	322
280	2. 201.13.251.10.in-addr.arpa, and	2. 201.13.251.10.in-addr.arpa, and	323
281	3. hacker.mail.widget.foo.example.	3. hacker.mail.widget.foo.example.	324
282			325
283	3.2 PGP CERT RR Names	3.2 Purpose-based X.509 CERT RR Names	326
284			327
285	PGP signed keys (certificates) use a general character string User ID	It is difficult for clients that do not already posses a certificate	328
286	[6]. However, it is recommended by PGP that such names include the	to reconstruct the content-based owner name that should be used to	329
287	RFC 822 email address of the party, as in "Leslie Example	retrieve the certificate. For this reason, purpose-based owner names	330
288	<Leslie@host.example>". If such a format is used, the CERT should be	are recommended in this section. Because purpose-based owner names	331
289	under the standard translation of the email address into a domain	by nature depend on the specific scenario, or purpose, for which the	332
290	name, which would be leslie.host.example in this case. If no RFC 822	certificate will be used, there are more than one recommendation.	333
291	name can be extracted from the string name no specific domain name is	The following table summarize the purpose-based X.509 CERT RR owner	334
292	recommended.	name guidelines.	335
			336
		Scenario Owner name	337
		-------------------------------------------------------------------	338
		S/MIME Certificate Standard translation of RFC 822 email address.	339
		Example: A S/MIME certificate for	340
		"postmaster@example.org" will use a standard	341
		hostname translation of the owner name,	342
		i.e. "postmaster.example.org".	343
			344
		SSL Certificate Hostname of the SSL server.	345
			346
		IPSEC Certificate Hostname of the IPSEC machine, and/or	347
		for the in-addr.arpa reverse lookup IP address.	348
			349
		CRLs Hostname of the issuing CA.	350
			351
		3.3 Content-based PGP CERT RR Names	352
			353
		OpenPGP signed keys (certificates) use a general character string	354
		User ID [5]. However, it is recommended by PGP that such names	355
		include the RFC 2822 [7] email address of the party, as in "Leslie	356
		Example <Leslie@host.example>". If such a format is used, the CERT	357
		should be under the standard translation of the email address into a	358
		domain name, which would be leslie.host.example in this case. If no	359
		RFC 2822 name can be extracted from the string name no specific	360
		domain name is recommended.	361
			362
		If a user has more than one email address, the CNAME type can be used	363
		to reduce the amount of data stored in the DNS. For example:	364
			365
		$ORIGIN example.org.	366
		smith IN CERT PGP 0 0 <OpenPGP binary>	367
		john.smith IN CNAME smith	368
		js IN CNAME smith	369
			370
		3.4 Purpose-based PGP CERT RR Names	371
			372
		Applications that receive an OpenPGP packet but do not know the email	373
		address of the sender will have difficulties guessing the correct	374
		owner name, and cannot use the content-based owner name guidelines.	375
		However, the OpenPGP packet typically contain the Key ID of the key.	376
		In these situations, it is recommended to use an owner name derived	377
		from the Key ID. For example:	378
			379
		$ORIGIN example.org.	380
		F835EDA21E94B565716F IN CERT PGP ...	381
		B565716F IN CNAME F835EDA21E94B565716F	382
			383
		As before, if the same key material is stored at several owner names,	384
		using CNAME can be used to avoid data duplication.	385
293			386
294	4. Performance Considerations	4. Performance Considerations	387
295			388
296	Current Domain Name System (DNS) implementations are optimized for	Current Domain Name System (DNS) implementations are optimized for	389
297	small transfers, typically not more than 512 bytes including	small transfers, typically not more than 512 bytes including	390
298	overhead. While larger transfers will perform correctly and work is	overhead. While larger transfers will perform correctly and work is	391
299	underway to make larger transfers more efficient, it is still	underway to make larger transfers more efficient, it is still	392
300	advisable at this time to make every reasonable effort to minimize	advisable at this time to make every reasonable effort to minimize	393
301	the size of certificates stored within the DNS. Steps that can be	the size of certificates stored within the DNS. Steps that can be	394
302	taken may include using the fewest possible optional or extensions	taken may include using the fewest possible optional or extensions	395
303	fields and using short field values for variable length fields that	fields and using short field values for variable length fields that	396
304	must be included.	must be included.	397
305			398
306	5. IANA Considerations	5. Size Considerations	399
307			400
308	Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can	The RDATA field in the DNS protocol may only hold data of size 65535	401
309	only be assigned by an IETF standards action [7] (and this document	octets (64kb) or less. This means that each CERT RR cannot contain	402
310	assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE). Certificate	more than 64kb worth of payload, even if the corresponding	403
311	types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]	certificate or certificate revocation list is larger. This document	404
312	based on RFC documentation of the certificate type. The availability	do not address this limitation.	405
313	of private types under 0x00FD and 0x00FE should satisfy most
314	requirements for proprietary or private types.
315			406
316	6. Security Considerations	6. Acknowledgements	407
			408
		The majority of this document is copied verbatim from RFC 2538, by	409
		Donald Eastlake 3rd and Olafur Gudmundsson.	410
			411
		The author wishes to thank David Shaw and Michael Graff for their	412
		contributions to the earlier work that motivated this revised	413
		document.	414
			415
		Florian Weimer suggested to clarify wording regarding what data can	416
		be stored in RRDATA portion of OpenPGP CERT RRs, and that the URI	417
		type may include hashes to secure the indirection. Olivier Dubuisson	418
		confirmed that the X.509 OID were indeed correct.	419
			420
		7. Security Considerations	421
317			422
318	By definition, certificates contain their own authenticating	By definition, certificates contain their own authenticating	423
319	signature. Thus it is reasonable to store certificates in non-secure	signature. Thus it is reasonable to store certificates in non-secure	424
320	DNS zones or to retrieve certificates from DNS with DNS security	DNS zones or to retrieve certificates from DNS with DNS security	425
321	checking not implemented or deferred for efficiency. The results MAY	checking not implemented or deferred for efficiency. The results MAY	426
322	be trusted if the certificate chain is verified back to a known	be trusted if the certificate chain is verified back to a known	427
323	trusted key and this conforms with the user's security policy.	trusted key and this conforms with the user's security policy.	428
324			429
325	Alternatively, if certificates are retrieved from a secure DNS zone	Alternatively, if certificates are retrieved from a secure DNS zone	430
326	with DNS security checking enabled and are verified by DNS security,	with DNS security checking enabled and are verified by DNS security,	431
327	the key within the retrieved certificate MAY be trusted without	the key within the retrieved certificate MAY be trusted without	432
328	verifying the certificate chain if this conforms with the user's	verifying the certificate chain if this conforms with the user's	433
329	security policy.	security policy.	434
330			435
		When the URI type is used, it should be understood that is introduce	436
		an additional indirection that may allow for a new attack vector.	437
		One method to secure that indirection is to include a hash of the	438
		certificate in the URI itself.	439
			440
331	CERT RRs are not used in connection with securing the DNS security	CERT RRs are not used in connection with securing the DNS security	441
332	additions so there are no security considerations related to CERT RRs	additions so there are no security considerations related to CERT RRs	442
333	and securing the DNS itself.	and securing the DNS itself.	443
334			444
335	7 References	8. IANA Considerations	445
			446
		Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can	447
		only be assigned by an IETF standards action [6]. This document	448
		assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE. Certificate	449
		types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]	450
		based on RFC documentation of the certificate type. The availability	451
		of private types under 0x00FD and 0x00FE should satisfy most	452
		requirements for proprietary or private types.	453
			454
		9. Open Issues	455
			456
		1. Whether to enforce owner name guidelines with SHOULD/MUST. From	457
		David Shaw (on OpenPGP): "One of the things that struck me when	458
		reading this draft is that while there are several suggested ways	459
		to name keys in DNS, there is no one canonical name as a SHOULD	460
		or MUST. I suggest that the key fingerprint be the canonical	461
		name, and all others be CNAMEs pointing to the fingerprint	462
		name.". From Sean P. Turner (on PKIX): "Should "recommended" be	463
		"RECOMMENDED" in the 1st and 2nd sentences?" referring to the	464
		text in section 3 that recommend appropriate owner names.	465
		2. Should the document suggest use of both full fingerprints, 4/8	466
		byte OpenPGP key id owner names? Perhaps only fingerprint	467
		version.	468
			469
		10. Changes since RFC 2538	470
			471
		1. Editorial changes to conform with new document requirements,	472
		including splitting reference section into two parts and updating	473
		references to point at latest versions.	474
		2. Improve terminology. For example replace "PGP" with "OpenPGP",	475
		to align with RFC 2440.	476
		3. In section 2.1, clarify that OpenPGP public key data are binary,	477
		not the ASCII armored format, and reference 10.1 in RFC 2440 on	478
		how to deal with OpenPGP keys, and acknowledge that	479
		implementations may handle additional packet types.	480
		4. Clarify that integers in the representation format are decimal.	481
		5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis	482
		terminology.	483
		6. Add examples that suggest use of CNAME to reduce bandwidth.	484
		7. In section 3, add three paragraphs that discuss "content-based"	485
		vs "purpose-based" owner names. Add section 3.2 for	486
		purpose-based X.509 CERT owner names, and section 3.4 for	487
		purpose-based OpenPGP CERT owner names.	488
			489
		11. References	490
			491
		11.1 Normative References	492
336			493
337	[1] Mockapetris, P., "Domain names - concepts and facilities", STD	[1] Mockapetris, P., "Domain names - concepts and facilities", STD	494
338	13, RFC 1034, November 1987.	13, RFC 1034, November 1987.	495
339			496
340	[2] Mockapetris, P., "Domain names - implementation and	[2] Mockapetris, P., "Domain names - implementation and	497
341	specification", STD 13, RFC 1035, November 1987.	specification", STD 13, RFC 1035, November 1987.	498
342			499
343	[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement	[3] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri,	500
344	Levels", BCP 14, RFC 2119, March 1997.
345
346	[4] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri,
347	"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,	"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,	501
348	January 1998.	January 1998.	502
349			503
350	[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource	[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource	504
351	Identifiers (URI): Generic Syntax", RFC 2396, August 1998.	Identifiers (URI): Generic Syntax", RFC 2396, August 1998.	505
352			506
353	[6] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP	[5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP	507
354	Message Format", RFC 2440, November 1998.	Message Format", RFC 2440, November 1998.	508
355			509
356	[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA	[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA	510
357	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.	511
358			512
359	[8] Eastlake, D., "Domain Name System Security Extensions", RFC	[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.	513
360	2535, March 1999.
361			514
362	[9] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509	[8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,	515
363	Public Key Infrastructure Certificate and CRL Profile", RFC	"DNS Security Introduction and Requirements",	516
364	2459, January 1999.	draft-ietf-dnsext-dnssec-intro-13 (work in progress), October	517
		2004.	518
			519
		[9] Arends, R., "Resource Records for the DNS Security Extensions",	520
		draft-ietf-dnsext-dnssec-records-11 (work in progress), October	521
		2004.	522
			523
		11.2 Informative References	524
			525
		[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement	526
		Levels", BCP 14, RFC 2119, March 1997.	527
			528
		[11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",	529
		RFC 3548, July 2003.	530
365			531
366	Author's Address	Author's Address	532
367			533
368	Simon Josefsson	Simon Josefsson	534
369			535
370	EMail: simon@josefsson.org	EMail: simon@josefsson.org	536
371			537
		Appendix A. Copying conditions	538
			539
		Regarding the portion of this document that was written by Simon	540
		Josefsson ("the author", for the remainder of this section), the	541
		author makes no guarantees and is not responsible for any damage	542
		resulting from its use. The author grants irrevocable permission to	543
		anyone to use, modify, and distribute it in any way that does not	544
		diminish the rights of anyone else to use, modify, and distribute it,	545
		provided that redistributed derivative works do not contain	546
		misleading author or version information. Derivative works need not	547
		be licensed under similar terms.	548
			549
372	Intellectual Property Statement	Intellectual Property Statement	550
373			551
374	The IETF takes no position regarding the validity or scope of any	The IETF takes no position regarding the validity or scope of any	552
375	Intellectual Property Rights or other rights that might be claimed to	Intellectual Property Rights or other rights that might be claimed to	553
376	pertain to the implementation or use of the technology described in	pertain to the implementation or use of the technology described in	554
377	this document or the extent to which any license under such rights	this document or the extent to which any license under such rights	555
378	might or might not be available; nor does it represent that it has	might or might not be available; nor does it represent that it has	556
379	made any independent effort to identify any such rights. Information	made any independent effort to identify any such rights. Information	557
380	on the procedures with respect to rights in RFC documents can be	on the procedures with respect to rights in RFC documents can be	558
381	found in BCP 78 and BCP 79.	found in BCP 78 and BCP 79.	559

	skipping to change at page 10, line 41	skipping to change at page 13, line 41
398	This document and the information contained herein are provided on an	This document and the information contained herein are provided on an	576
399	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS	577
400	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET	578
401	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,	579
402	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE	580
403	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED	581
404	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.	582
405			583
406	Copyright Statement	Copyright Statement	584
407			585
408	Copyright (C) The Internet Society (2004). This document is subject	Copyright (C) The Internet Society (2005). This document is subject	586
409	to the rights, licenses and restrictions contained in BCP 78, and	to the rights, licenses and restrictions contained in BCP 78, and	587
410	except as set forth therein, the authors retain all their rights.	except as set forth therein, the authors retain all their rights.	588
411			589
412	Acknowledgment	Acknowledgment	590
413			591
414	Funding for the RFC Editor function is currently provided by the	Funding for the RFC Editor function is currently provided by the	592
415	Internet Society.	Internet Society.	593

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