idnits 2.17.1 draft-ietf-pkix-srvsan-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 431. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2006) is 6549 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3280 (ref. 'N2') (Obsoleted by RFC 5280) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. 'N5') ** Obsolete normative reference: RFC 3490 (ref. 'N6') (Obsoleted by RFC 5890, RFC 5891) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Santesson (Microsoft) 3 Intended Status: Proposed Standard 4 Expires November 2007 May 2006 6 Internet X.509 Public Key Infrastructure 7 Subject Alternative Name for expression of service name 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This document defines a new name form for inclusion in the otherName 36 field of an X.509 Subject Alternative Name extension which allows a 37 certificate subject to be associated with the service name and domain 38 name components of a DNS Service Resource Record. 40 Table of Contents 42 1 Introduction ................................................ 2 43 2 Name Definitions ............................................ 3 44 3 Internationalized Domain Names .............................. 5 45 4 Name Constraints Matching Rules ............................. 6 46 5 Security Considerations ..................................... 7 47 6 IANA Considerations ......................................... 7 48 7 Normative References ........................................ 7 49 Appendix A. ASN.1 Syntax ....................................... 8 50 Appendix A.1. 1988 ASN.1 Module ............................ 8 51 Appendix A.2. 1993 ASN.1 Module ............................ 9 52 Authors' Addresses ............................................. 11 53 Full Copyright Statement ....................................... 11 54 Intellectual Property .......................................... 11 56 1. Introduction 58 This document specifies a name form for inclusion in X.509 59 certificates that may be used by a certificate relying party to 60 verify that a particular host is authorized to provide a specific 61 service within a domain. 63 RFC 2782 [N3] Defines a DNS RR (Resource Record) for specifying the 64 location of services (SRV RR) which allows clients to ask for a 65 specific service/protocol for a specific domain and get back the 66 names of any available servers. 68 Existing name forms in X.509 certificates support authentication of a 69 host name. This is useful when the name of the host is known by the 70 client prior to authentication. 72 When a server host name is discovered through DNS RR lookup query 73 based on service name, the client may need to authenticate the 74 server's authorization to provide the requested service in addition 75 to the servers host name. 77 While DNS servers may have the capacity to provide trusted 78 information, there may be many other situations where the binding 79 between the name of the host and the provided service needs to be 80 supported by additional credentials. 82 Current dNSName GeneralName Subject Alternative name form only 83 provide for DNS host names to be expressed in "preferred name 84 syntax," as specified by RFC 1034 [N4]. This definition is therefore 85 not broad enough to allow expression of a service related to that 86 domain. 88 1.1 Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [N1]. 94 2. Name Definitions 96 This section defines the SRVName name as a form of otherName from the 97 GeneralName structure in SubjectAltName defined in RFC 3280 [N2]. 99 id-on-dnsSRV OBJECT IDENTIFIER ::= { id-on 7 } 101 SRVName ::= IA5String (SIZE (1..MAX)) 103 The SRVName, if present, MUST contain a service name and a domain 104 name in the following form: 106 _Service.Name 108 The content of the components of this name form MUST be consistent 109 with the corresponding definition of these components in an SRV RR 110 according to RFC 2782 [N3]. 112 The content of these components are: 114 Service 115 The symbolic name of the desired service, as defined in 116 Assigned Numbers [N5] or locally. An underscore (_) is 117 prepended to the service identifier to avoid collisions with 118 DNS labels that occur in nature. Some widely used services, 119 notably POP, don't have a single universal name. If Assigned 120 Numbers names the service indicated, that name is the only name 121 which is allowed in the service component of this name form. 122 The Service is case insensitive. 124 Name 125 The DNS domain name of the domain where the specified service 126 is located. 128 If the domain name is an Internationalized domain name (IDN) 129 then encoding in ASCII form SHALL be done as defined in section 130 3. 132 Even though this name form is based on the service resource record 133 (SRV RR) definition in RFC 2782 [N3] and may be used to enhance 134 subsequent authentication of DNS based service discovery, this 135 standard does not define any new conditions or requirements regarding 136 use of SRV RR for service discovery or where and when such use is 137 appropriate. 139 The format of a DNS RR according to RFC 2782 also includes a protocol 140 component (_Service._Proto.Name). This protocol component is not 141 included in the SRVName specified in this document. The purpose of 142 the SRVName is limited to authorization of service provision within a 143 domain. It is outside the scope of the SRVName to provide any means 144 to verify that the host is using any intended protocol. By omitting 145 the protocol component from the SRVName two important advantages has 146 been achieved. 148 * One certificate with a single SRVName can be issued to a host 149 that offers multiple protocol alternatives 151 * Name constraints processing rules (specified in section 4)are 152 significantly less complex to define without the protocol 153 component 155 A present SRVName in a certificate MUST NOT be used to identify a 156 host unless one of the following conditions applies: 158 * Use of this name form is specified by the security protocol 159 being used and the identified service has a defined service 160 name according to RFC 2782, or; 162 * Use of this name form is configured by local policy 164 3 Internationalized Domain Names 166 IA5String is limited to the set of ASCII characters. To accommodate 167 internationalized domain names in the current structure, conforming 168 implementations MUST convert internationalized domain names to the 169 ASCII Compatible Encoding (ACE) format as specified in section 4 of 170 RFC 3490 [N6] before storage in the Name part of SRVName. 171 Specifically, conforming implementations MUST perform the conversion 172 operation specified in section 4 of RFC 3490 [N6], with the following 173 clarifications: 175 * in step 1, the domain name SHALL be considered a "stored 176 string". That is, the AllowUnassigned flag SHALL NOT be set; 178 * in step 3, set the flag called "UseSTD3ASCIIRules"; 180 * in step 4, process each label with the "ToASCII" operation; and 182 * in step 5, change all label separators to U+002E (full stop). 184 When comparing DNS names for equality, conforming implementations 185 MUST perform a case-insensitive exact match on the entire domain 186 name. When evaluating name constraints, conforming implementations 187 MUST perform a case-insensitive exact match on a label-by-label 188 basis. 190 Implementations SHOULD convert IDNs to Unicode before display. 191 Specifically, conforming implementations SHOULD perform the 192 conversion operation specified in section 4 of RFC 3490 [N6], with 193 the following clarifications: 195 * in step 1, the domain name SHALL be considered a "stored 196 string". That is, the AllowUnassigned flag SHALL NOT be set; 198 * in step 3, set the flag called "UseSTD3ASCIIRules"; 200 * in step 4, process each label with the "ToUnicode" operation; 201 and 203 * skip step 5. 205 Note: Implementations MUST allow for increased space requirements 206 for IDNs. An IDN ACE label will begin with the four additional 207 characters "xn--" and may require as many as five ASCII characters to 208 specify a single international character. 210 4 Name Constraints Matching Rules 212 Name constraining, as specified in RFC 3280, MAY be applied to the 213 SRVName by adding name restriction in the name constraints extension 214 in the form of an SRVName. 216 SRVName restrictions are expressed as a complete SRVName 217 (_mail.example.com), just a service name (_mail) or just as a DNS 218 name (example.com). The name restriction of the service name part and 219 the DNS name part of SRVName are handled separately. 221 If a service name is included in the restriction then that 222 restriction can only be satisfied by an SRVName which includes a 223 corresponding service name. If the restriction has an absent service 224 name, then that restriction is satisfied by any SRVName that match 225 the domain part of the restriction. 227 DNS name restrictions are expressed as host.example.com. Any DNS 228 name that can be constructed by simply adding subdomains to the left 229 hand side of the name satisfies the DNS name part of the name 230 constraint. For example, www.host.example.com would satisfy the 231 constraint (host.example.com) but 1host.example.com would not. 233 Examples: 235 Name Constraints 236 SRVName restriction Matching SRVName non-matching SRVName 237 =================== ================ ==================== 238 example.com _mail.example.com _mail.1example.com 239 _ntp.example.com 240 _mail.1.example.com 242 _mail _mail.example.com _ntp.example.com 243 _mail.1example.com 245 _mail.example.com _mail.example.com _mail.1example.com 246 _mail.1.example.com _ntp.example.com 248 5 Security Considerations 250 Assignment of services to hosts may be subject to change. 251 Implementers should be aware of the need to revoke old certificates 252 that no longer reflect the current assignment of services and thus 253 make sure that all issued certificates are up to date. 255 When X.509 certificates enhanced with the name form specified in this 256 standard is used to enhance authentication of service discovery based 257 on a SRV RR query to a DNS server, all security considerations of RFC 258 2782 applies. 260 6 IANA Considerations 262 This document has no actions for IANA. 264 7 Normative References 266 [N1] S. Bradner, "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [N2] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet 270 X.509 Public Key Infrastructure: Certificate and 271 Certificate Revocation List (CRL) Profile", RFC 3280, 272 April 2002. 274 [N3] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying the 275 location of services (DNS SRV)", RFC 2782, February 2000. 277 [N4] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", 278 RFC 1034, November 1987 280 [N5] J. Reynolds, "Assigned Numbers: RFC 1700 is Replaced by 281 an On-line Database", RFC 3232, January 2002. 283 [N6] Falstrom, P., P. Hoffman and A. Costello, 284 "Internationalizing Domain Names In Applications (IDNA)", 285 RFC 3490, March 2003. 287 Appendix A. ASN.1 Syntax 289 As in RFC 2459, ASN.1 modules are supplied in two different variants 290 of the ASN.1 syntax. 292 This section describes data objects used by conforming PKI components 293 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 294 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with the 295 1993 UNIVERSAL Type UTF8String. 297 The ASN.1 syntax does not permit the inclusion of type statements in 298 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 299 the new UNIVERSAL types in modules using the 1988 syntax. As a 300 result, this module does not conform to either version of the ASN.1 301 standard. 303 Appendix A.1 may be parsed by an 1988 ASN.1-parser by replacing the 304 definitions for the UNIVERSAL Types with the 1988 catch-all "ANY". 306 Appendix A.2 may be parsed "as is" by an 1997-compliant ASN.1 parser. 308 In case of discrepancies between these modules, the 1988 module is 309 the normative one. 311 Appendix A.1. 1988 ASN.1 Module 313 PKIXServiceNameSAN88 {iso(1) identified-organization(3) dod(6) 314 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 315 id-mod-dns-srv-name-88(39) } 317 DEFINITIONS EXPLICIT TAGS ::= 319 BEGIN 321 -- EXPORTS ALL -- 323 IMPORTS 325 -- UTF8String, / move hyphens before slash if UTF8String does not 326 -- resolve with your compiler 328 id-pkix 329 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 330 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 331 id-mod(0) id-pkix1-explicit(18) } ; 332 -- from RFC3280 [N2] 334 -- Service Name Object Identifier and Syntax 335 -- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7} 337 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 339 id-on-dnsSRV OBJECT IDENTIFIER ::= { id-on 7 } 341 SRVName ::= IA5String (SIZE (1..MAX)) 343 END 345 Appendix A.2. 1993 ASN.1 Module 347 PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6) 348 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 349 id-mod-dns-srv-name-93(40) } 351 DEFINITIONS EXPLICIT TAGS ::= 353 BEGIN 355 -- EXPORTS ALL -- 357 IMPORTS 359 id-pkix 360 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 361 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 362 id-mod(0) id-pkix1-explicit(18) } ; 363 -- from RFC 3280 [N2] 365 -- In the GeneralName definition using the 1993 ASN.1 syntax 366 -- includes: 368 OTHER-NAME ::= TYPE-IDENTIFIER 370 -- Service Name Object Identifier 372 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 374 id-on-dnsSRV OBJECT IDENTIFIER ::= { id-on 7 } 375 -- Service Name 377 srvName OTHER-NAME ::= { SRVName IDENTIFIED BY { id-on-dnsSRV }} 379 SRVName ::= IA5String (SIZE (1..MAX)) 381 END 383 Authors' Addresses 385 Stefan Santesson 386 Microsoft 387 Tuborg Boulevard 12 388 2900 Hellerup 389 Denmark 391 EMail: stefans@microsoft.com 393 Full Copyright Statement 395 Copyright (C) The IETF Trust (2007). 397 This document is subject to the rights, licenses and restrictions 398 contained in BCP 78, and except as set forth therein, the authors 399 retain all their rights. 401 This document and the information contained herein are provided on an 402 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 403 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 404 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 405 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 406 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 407 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 409 Intellectual Property 411 The IETF takes no position regarding the validity or scope of any 412 Intellectual Property Rights or other rights that might be claimed to 413 pertain to the implementation or use of the technology described in 414 this document or the extent to which any license under such rights 415 might or might not be available; nor does it represent that it has 416 made any independent effort to identify any such rights. Information 417 on the procedures with respect to rights in RFC documents can be 418 found in BCP 78 and BCP 79. 420 Copies of IPR disclosures made to the IETF Secretariat and any 421 assurances of licenses to be made available, or the result of an 422 attempt made to obtain a general license or permission for the use of 423 such proprietary rights by implementers or users of this 424 specification can be obtained from the IETF on-line IPR repository at 425 http://www.ietf.org/ipr. 427 The IETF invites any interested party to bring to its attention any 428 copyrights, patents or patent applications, or other proprietary 429 rights that may cover technology that may be required to implement 430 this standard. Please address the information to the IETF at ietf- 431 ipr@ietf.org. 433 Expires November 2007