rfc2538xml.txt		draft-ietf-dnsext-rfc2538bis.txt
1				1
2	Network Working Group S. Josefsson		Network Working Group S. Josefsson	2
3				3
4	Expires: March 5, 2005		Obsoletes: 2538 (if approved)	4
			Expires: September 2, 2006	5
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-10	8
8				9
9	Status of this Memo		Status of this Memo	10
10				11
11	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any	12
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 aware	13
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 becomes	14
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 Engineering	17
17	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that	18
	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 any	23
23	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference	24
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 at	27
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 at	30
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
34	Copyright Notice		Copyright Notice	35
35				36
36	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2006).	37
37				38
38	Abstract		Abstract	39
39				40
40	Cryptographic public key are frequently published and their		Cryptographic public keys are frequently published, and their	41
41	authenticity demonstrated by certificates. A CERT resource record		authenticity is demonstrated by certificates. A CERT resource record	42
42	(RR) is defined so that such certificates and related certificate		(RR) is defined so that such certificates and related certificate	43
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
45	Table of Contents		Table of Contents	48
46				49
47	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3	50
48	2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3		2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3	51
49	2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4		2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4	52
50	2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5		2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 6	53
51	2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 5		2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6	54
52	3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6		3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 7	55
53	3.1. X.509 CERT RR Names . . . . . . . . . . . . . . . . . . . 6		3.1. Content-Based X.509 CERT RR Names . . . . . . . . . . . . 8	56
54	3.2. PGP CERT RR Names . . . . . . . . . . . . . . . . . . . . 7		3.2. Purpose-Based X.509 CERT RR Names . . . . . . . . . . . . 9	57
55	4. Performance Considerations . . . . . . . . . . . . . . . . . . 7		3.3. Content-Based OpenPGP CERT RR Names . . . . . . . . . . . 9	58
56	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		3.4. Purpose-Based OpenPGP CERT RR Names . . . . . . . . . . . 10	59
57	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX . . . . . 10	60
58	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Performance Considerations . . . . . . . . . . . . . . . . . . 10	61
59	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11	62
60	Intellectual Property and Copyright Statements . . . . . . . . . . 11		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11	63
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 11	64
			8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12	65
			9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 13	66
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13	67
			10.1. Normative References . . . . . . . . . . . . . . . . . . . 13	68
			10.2. Informative References . . . . . . . . . . . . . . . . . . 14	69
			Appendix A. Copying Conditions . . . . . . . . . . . . . . . . . 15	70
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16	71
			Intellectual Property and Copyright Statements . . . . . . . . . . 17	72
61				73
62	1. Introduction		1. Introduction	74
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 and	77
66	related certificate revocation lists (CRLs). A certificate is a		related certificate revocation lists (CRLs). A certificate is a	78
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 of	81
70	certificates that are revoked, and incidental information, all signed		certificates that are revoked, and of incidental information, all	82
71	by the signer (issuer) of the revoked certificates. Examples are		signed by the signer (issuer) of the revoked certificates. Examples	83
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 OpenPGP	84
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 of	87
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 IANA	92
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 this	98
85	document are to be interpreted as described in [3].		document are to be interpreted as described in [3].	99
86				100
87	2. The CERT Resource Record		2. The CERT Resource Record	101
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 RR	103
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 3	106
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 1	107
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.1	116
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 embedded	119
106	KEY and SIG RRs [8] except that a zero algorithm field indicates the		in the certificate, using the RRSIG Key Tag algorithm described in	120
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 to	121
108	of the algorithm not having been standardized for secure DNS.		pick which CERT RRs may be applicable to a particular key. The key	122
			tag can be calculated for the key in question, and then only CERT RRs	123
			with the same key tag need to be examined. Note that two different	124
			keys can have the same key tag. However, the key MUST be transformed	125
			to the format it would have as the public key portion of a DNSKEY RR	126
			before the key tag is computed. This is only possible if the key is	127
			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 be	129
			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 in	132
111	in the certificate as specified in the DNSSEC Standard [8]. This		DNSKEY and RRSIG RRs [12], except that a zero algorithm field	133
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 may	134
113	applicable to a particular key. The key tag can be calculated for		simply be the result of the algorithm not having been standardized	135
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
122	2.1. Certificate Type Values		2.1. Certificate Type Values	138
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 Type	142
127	----- -------- ----------- ----		----- -------- ----------------	143
128	0 reserved		0 Reserved	144
129	1 PKIX X.509 as per PKIX		1 PKIX X.509 as per PKIX	145
130	2 SPKI SPKI cert		2 SPKI SPKI certificate	146
131	3 PGP PGP cert		3 PGP OpenPGP packet	147
132	4-252 available for IANA assignment		4 IPKIX The URL of an X.509 data object	148
			5 ISPKI The URL of an SPKI certificate	149
			6 IPGP The fingerprint and URL of an OpenPGP packet	150
			7 ACPKIX Attribute Certificate	151
			8 IACPKIX The URL of an Attribute Certificate	152
			9-252 Available for IANA assignment	153
133	253 URI URI private		253 URI URI private	154
134	254 OID OID private		254 OID OID private	155
135	255-65534 available for IANA assignment		255 Reserved	156
136	65535 reserved		256-65279 Available for IANA assignment	157
			65280-65534 Experimental	158
			65535 Reserved	159
				160
			These values represent the initial content of the IANA registry; see	161
			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 conforming	164
139	to the profile being defined by the IETF PKIX working group. The		to the profile defined by the IETF PKIX working group [8]. The	165
140	certificate section will start with a one byte unsigned OID length		certificate section will start with a one-octet unsigned OID length	166
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 the	167
142	certificate section (see 2.3 below). (NOTE: X.509 certificates do		certificate section (see Section 2.3, below). (NOTE: X.509	168
143	not include their X.500 directory type designating OID as a prefix.)		certificates do not include their X.500 directory-type-designating	169
			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 SPKI	172
146	specified by the IETF SPKI working group.		certificate format [15], for use when the SPKI documents are moved	173
			from experimental status. The format for these two CERT RR types	174
			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 its	177
149	in [6] and its extensions and successors.		extensions and successors. This is used to transfer public key	178
			material and revocation signatures. The data is binary and MUST NOT	179
			be encoded into an ASCII armor. An implementation SHOULD process	180
			transferable public keys as described in Section 10.1 of [5], but it	181
			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 the	186
			content that would have been in the "certificate, CRL, or URL" field	187
			of the corresponding type (PKIX or ACPKIX, respectively).	188
				189
			The IPGP type contains both an OpenPGP fingerprint for the key in	190
			question, as well as a URL. The certificate portion of the IPGP CERT	191
			RR is defined as a one-octet fingerprint length, followed by the	192
			OpenPGP fingerprint, followed by the URL. The OpenPGP fingerprint is	193
			calculated as defined in RFC 2440 [5]. A zero-length fingerprint or	194
			a zero-length URL are legal, and indicate URL-only IPGP data or	195
			fingerprint-only IPGP data, respectively. A zero-length fingerprint	196
			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 the	200
			CERT RR and MAY be used at the implementer's discretion. They SHOULD	201
			NOT be used where the DNS message is 512 octets or smaller and could	202
			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 an	205
152	absolute URI. The certificate portion of the CERT RR MUST begin with		absolute URI. The certificate portion of the CERT RR MUST begin with	206
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 private	207
154	format certificate itself. The URI SHOULD be such that a retrieval		format certificate itself. The URI SHOULD be such that a retrieval	208
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 URI	210
157	equality but can use various forms of pattern matching so that, for		equality but can use various forms of pattern matching so that, for	211
158	example, subtype or version information can also be encoded into the		example, subtype or version information can also be encoded into the	212
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 specified	215
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 the	217
164	the nature of the remainder of the certificate section. This can be		nature of the remainder of the certificate section. This can be an	218
165	an X.509 certificate format or some other format. X.509 certificates		X.509 certificate format or some other format. X.509 certificates	219
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 PKIX	220
167	type, not the OID private type. Recognition of private certificate		type, not the OID private type. Recognition of private certificate	221
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 of	222
169	pattern matching such as OID prefix.		pattern matching such as OID prefix.	223
170				224
171	2.2. Text Representation of CERT RRs		2.2. Text Representation of CERT RRs	225
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 unsigned	227
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 or	233
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 be	236
182	divided up into any number of white space separated substrings, down		divided into any number of white-space-separated substrings, down to	237
183	to single base 64 digits, which are concatenated to obtain the full		single base-64 digits, which are concatenated to obtain the full	238
184	signature. These substrings can span lines using the standard		signature. These substrings can span lines using the standard	239
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. For	243
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 then	244
190	the certificate / CRL proper. But only a single logical base 64		the certificate/CRL proper. However, only a single logical base-64	245
191	string will appear in the text representation.		string will appear in the text representation.	246
192				247
193	2.3. X.509 OIDs		2.3. X.509 OIDs	248
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 for	250
196	user certificates, certification authority certificates, revocations		user certificates, certification authority certificates, revocations	251
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 their	253
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-userCertificate	256
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 24	258
204	id-at-cACertificate		id-at-cACertificate	259
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 25	261
207	id-at-authorityRevocationList		id-at-authorityRevocationList	262
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 26	264
	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 27	267
213				268
214	3. Appropriate Owner Names for CERT RRs		3. Appropriate Owner Names for CERT RRs	269
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 domain	271
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 intended	272
218	to control the private key corresponding to the public key being		to control the private key corresponding to the public key being	273
219	certified. It is recommended that certificate revocation list CERT		certified. It is recommended that certificate revocation list CERT	274
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 with	277
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 1035	278
224	backslash followed by the octal representation of the ASCII code for		[2].	279
225	the character such as \000 for NULL.
226				280
227	3.1. X.509 CERT RR Names		The choice of name under which CERT RRs are stored is important to	281
			clients that perform CERT queries. In some situations, the clients	282
			may not know all information about the CERT RR object it wishes to	283
			retrieve. For example, a client may not know the subject name of an	284
			X.509 certificate, or the email address of the owner of an OpenPGP	285
			key. Further, the client might only know the hostname of a service	286
			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 owner	289
230	subjects and issuers under "Subject Alternate Name" and "Issuer		names and purpose-based owner names. A content-based owner name is	290
231	Alternate Name". For example, x.509v3 has such Alternate Names with		derived from the content of the CERT RR data; for example, the	291
232	an ASN.1 specification as follows:		Subject field in an X.509 certificate or the User ID field in OpenPGP	292
			keys. A purpose-based owner name is a name that a client retrieving	293
			CERT RRs ought to know already; for example, the host name of an	294
			X.509 protected service or the Key ID of an OpenPGP key. The	295
			content-based and purpose-based owner name may be the same; for	296
			example, when a client looks up a key based on the From: address of	297
			an incoming email.	298
				299
			Implementations SHOULD use the purpose-based owner name guidelines	300
			described in this document and MAY use CNAME RRs at content-based	301
			owner names (or other names), pointing to the purpose-based owner	302
			name.	303
				304
			Note that this section describes an application-based mapping from	305
			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 records	307
			based on similarities or differences of the DNS owner name(s) of CERT	308
			resource records. For example, if multiple labels are used when	309
			mapping from a CERT identifier to a domain name, then care must be	310
			taken in understanding wildcard record synthesis.	311
				312
			3.1. Content-Based X.509 CERT RR Names	313
				314
			Some X.509 versions, such as the PKIX profile of X.509 [8], permit	315
			multiple names to be associated with subjects and issuers under	316
			"Subject Alternative Name" and "Issuer Alternative Name". For	317
			example, the PKIX profile has such Alternate Names with an ASN.1	318
			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 priority	332
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 the	334
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 appropriate	337
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 domain	339
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 is	341
257	included, then it should be treated as described for PGP names in		included, then it ought to be treated as described below for	342
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 locations	350
266	the storage locations recommended, in priority order, would be		recommended, in priority order, would be	351
267	1. john-doe.com,		1. john-doe.com,	352
268	2. www.secure.john-doe.com, and		2. www.secure.john-doe.com, and	353
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, and	358
274	10.251.13.201, and (c) string "James Hacker		(c) string "James Hacker <[email protected]>". The	359
275	<[email protected]>". Then the storage locations		storage locations recommended, in priority order, would be	360
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, and	362
279	3. hacker.mail.widget.foo.example.		3. hacker.mail.widget.foo.example.	363
280				364
281	3.2. PGP CERT RR Names		3.2. Purpose-Based X.509 CERT RR Names	365
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 a	367
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. Recommendations	369
286	<[email protected]>". If such a format is used, the CERT should be		for purpose-based owner names vary per scenario. The following table	370
287	under the standard translation of the email address into a domain		summarizes the purpose-based X.509 CERT RR owner name guidelines for	371
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 name	374
			------------------ ----------------------------------------------	375
			S/MIME Certificate Standard translation of an RFC 2822 email	376
			address. Example: An S/MIME certificate for	377
			"[email protected]" will use a standard	378
			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 IPv4	384
			or IPv6 addresses, the fully qualified domain	385
			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 Names	390
				391
			OpenPGP signed keys (certificates) use a general character string	392
			User ID [5]. However, it is recommended by OpenPGP that such names	393
			include the RFC 2822 [7] email address of the party, as in "Leslie	394
			Example <[email protected]>". If such a format is used, the CERT	395
			ought to be under the standard translation of the email address into	396
			a domain name, which would be leslie.host.example in this case. If	397
			no RFC 2822 name can be extracted from the string name, no specific	398
			domain name is recommended.	399
				400
			If a user has more than one email address, the CNAME type can be used	401
			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 smith	406
			js IN CNAME smith	407
				408
			3.4. Purpose-Based OpenPGP CERT RR Names	409
				410
			Applications that receive an OpenPGP packet containing encrypted or	411
			signed data but do not know the email address of the sender will have	412
			difficulties constructing the correct owner name and cannot use the	413
			content-based owner name guidelines. However, these clients commonly	414
			know the key fingerprint or the Key ID. The key ID is found in	415
			OpenPGP packets, and the key fingerprint is commonly found in	416
			auxiliary data that may be available. In this case, use of an owner	417
			name identical to the key fingerprint and the key ID expressed in	418
			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 use	426
			of CNAME may help avoid data duplication. Note that CNAME is not	427
			always applicable, because it maps one owner name to the other for	428
			all purposes, which may be sub-optimal when two keys with the same	429
			Key ID are stored.	430
				431
			3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX	432
				433
			These types are stored under the same owner names, both purpose- and	434
			content-based, as the PKIX, SPKI, PGP, and ACPKIX types.	435
291				436
292	4. Performance Considerations		4. Performance Considerations	437
293				438
294	Current Domain Name System (DNS) implementations are optimized for		The Domain Name System (DNS) protocol was designed for small	439
295	small transfers, typically not more than 512 bytes including		transfers, typically below 512 octets. While larger transfers will	440
296	overhead. While larger transfers will perform correctly and work is		perform correctly and work is underway to make larger transfers more	441
297	underway to make larger transfers more efficient, it is still		efficient, it is still advisable at this time that every reasonable	442
298	advisable at this time to make every reasonable effort to minimize		effort be made to minimize the size of certificates stored within the	443
299	the size of certificates stored within the DNS. Steps that can be		DNS. Steps that can be taken may include using the fewest possible	444
300	taken may include using the fewest possible optional or extensions		optional or extension fields and using short field values for	445
301	fields and using short field values for variable length fields that		necessary variable-length fields.	446
302	must be included.
303				447
304	5. IANA Considerations		The RDATA field in the DNS protocol may only hold data of size 65535	448
			octets (64kb) or less. This means that each CERT RR MUST NOT contain	449
			more than 64kb of payload, even if the corresponding certificate or	450
			certificate revocation list is larger. This document addresses this	451
			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 the	454
307	only be assigned by an IETF standards action [7] (and this document		access patterns of DNS lookups from per-domain to per-user. If	455
308	assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE). Certificate		digitally signed email and a key/certificate lookup based on CERT RRs	456
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
314	6. Security Considerations		5. Contributors	461
				462
			The majority of this document is copied verbatim from RFC 2538, by	463
			Donald Eastlake 3rd and Olafur Gudmundsson.	464
				465
			6. Acknowledgements	466
				467
			Thanks to David Shaw and Michael Graff for their contributions to	468
			earlier works that motivated, and served as inspiration for, this	469
			document.	470
				471
			This document was improved by suggestions and comments from Olivier	472
			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, Samuel	475
			Weiler, Florian Weimer, and the IANA. No doubt the list is	476
			incomplete. We apologize to anyone we left out.	477
				478
			7. Security Considerations	479
315				480
316	By definition, certificates contain their own authenticating		By definition, certificates contain their own authenticating	481
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 DNS	483
319	checking not implemented or deferred for efficiency. The results MAY		security checking not implemented or deferred for efficiency. The	484
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 a	485
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 zone	488
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 without	490
326	verifying the certificate chain if this conforms with the user's		verifying the certificate chain if this conforms with the user's	491
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 of	496
			the organization. This is usually not considered desirable, for the	497
			same reason that enterprise phone listings are not often publicly	498
			published and are even marked confidential.	499
332				500
333	7. References		Using the URI type introduces another level of indirection that may	501
			open a new vulnerability. One method of securing that indirection is	502
			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 securely	506
			asserted. Without DNSSEC, this is not possible.	507
				508
			8. IANA Considerations	509
				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 Reference	514
			------- ---- ------- ---------	515
			0 Reserved RFC 4398	516
			1 PKIX X.509 as per PKIX RFC 4398	517
			2 SPKI SPKI certificate RFC 4398	518
			3 PGP OpenPGP packet RFC 4398	519
			4 IPKIX The URL of an X.509 data object RFC 4398	520
			5 ISPKI The URL of an SPKI certificate RFC 4398	521
			6 IPGP The fingerprint and URL RFC 4398	522
			of an OpenPGP packet	523
			7 ACPKIX Attribute Certificate RFC 4398	524
			8 IACPKIX The URL of an Attribute RFC 4398	525
			Certificate	526
			9-252 Available for IANA assignment	527
			by IETF Standards action	528
			253 URI URI private RFC 4398	529
			254 OID OID private RFC 4398	530
			255 Reserved RFC 4398	531
			256-65279 Available for IANA assignment	532
			by IETF Consensus	533
			65280-65534 Experimental RFC 4398	534
			65535 Reserved RFC 4398	535
				536
			Certificate types 0x0000 through 0x00FF (255) and 0xFF00 (65280)	537
			through 0xFFFF (65535) can only be assigned by an IETF standards	538
			action [6]. This document assigns 0x0001 through 0x0008 and 0x00FD	539
			(253) and 0x00FE (254). Certificate types 0x0100 (256) through	540
			0xFEFF (65279) are assigned through IETF Consensus [6] based on RFC	541
			documentation of the certificate type. The availability of private	542
			types under 0x00FD (253) and 0x00FE (254) ought to satisfy most	543
			requirements for proprietary or private types.	544
				545
			The CERT RR reuses the DNS Security Algorithm Numbers registry. In	546
			particular, the CERT RR requires that algorithm number 0 remain	547
			reserved, as described in Section 2. The IANA will reference the	548
			CERT RR as a user of this registry and value 0, in particular.	549
				550
			9. Changes since RFC 2538	551
				552
			1. Editorial changes to conform with new document requirements,	553
			including splitting reference section into two parts and	554
			updating the references to point at latest versions, and to add	555
			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 on	560
			how to deal with OpenPGP keys, and acknowledge that	561
			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 DNSSECbis	564
			terminology. Improve reference for Key Tag Algorithm	565
			calculations.	566
			6. Add examples that suggest use of CNAME to reduce bandwidth.	567
			7. In Section 3, appended the last paragraphs that discuss	568
			"content-based" vs "purpose-based" owner names. Add Section 3.2	569
			for purpose-based X.509 CERT owner names, and Section 3.4 for	570
			purpose-based OpenPGP CERT owner names.	571
			8. Added size considerations.	572
			9. The SPKI types has been reserved, until RFC 2692/2693 is moved	573
			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. References	578
				579
			10.1. Normative References	580
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 and	585
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 Requirement	588
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 IANA	598
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.509	604
359	RFC 2535, March 1999.		Public Key Infrastructure Certificate and Certificate	605
			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 Certificate	608
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, "Uniform	611
			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 References	623
				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 Internet	628
			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 Extensions	638
			(S/MIME) Version 3.1 Message Specification", RFC 3851,	639
			July 2004.	640
				641
			[18] Richardson, M., "A Method for Storing IPsec Keying Material in	642
			DNS", RFC 4025, March 2005.	643
				644
			Appendix A. Copying Conditions	645
				646
			Regarding the portion of this document that was written by Simon	647
			Josefsson ("the author", for the remainder of this section), the	648
			author makes no guarantees and is not responsible for any damage	649
			resulting from its use. The author grants irrevocable permission to	650
			anyone to use, modify, and distribute it in any way that does not	651
			diminish the rights of anyone else to use, modify, and distribute it,	652
			provided that redistributed derivative works do not contain	653
			misleading author or version information. Derivative works need not	654
			be licensed under similar terms.	655
364				656
365	Author's Address		Author's Address	657
366				658
367	Simon Josefsson		Simon Josefsson	659
368				660
369	Email: [email protected]		Email: [email protected]	661
370				662
371	Intellectual Property Statement		Intellectual Property Statement	663
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 any	665
	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 an	689
398	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS	690
399	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET	691
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 THE	693
402	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED	694
403	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.	695
404				696
405	Copyright Statement		Copyright Statement	697
406				698
407	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2006). This document is subject	699
408	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and	700
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
411	Acknowledgment		Acknowledgment	703
412				704
413	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the	705
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/