idnits 2.17.1 draft-santesson-pkix-srvrr-00.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 on line 143. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2005) is 6914 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) == Unused Reference: 'N1' is defined on line 107, but no explicit reference was found in the text == Unused Reference: 'N2' is defined on line 110, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (ref. 'N2') (Obsoleted by RFC 5280) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Santesson (Microsoft) 3 Intended Category: Standards Track 4 Expires November 2005 May 2005 6 Internet X.509 Public Key Infrastructure 7 DNS Service Resource Record otherName 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 a "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 filed of an X.509 Subject Alternative Name extension which allows a 37 certificate subject to be associated with a DNS Service Resource 38 Record. 40 Table of Contents 42 1 Introduction ................................................ 2 43 2 SRV RR otherName ............................................ 3 44 3 Security Considerations ..................................... 3 45 4 References .................................................. 3 46 Appendix A. ASN.1 definitions .................................. 4 47 Authors' Addresses ............................................. 4 48 Disclaimer ..................................................... 5 49 Copyright Statement ............................................ 5 51 1. Introduction 53 RFC 2782 [N3] Defines a DNS RR (Resource Record) for specifying the 54 location of services (SRV RR) which allows clients to ask for a 55 specific service/protocol for a specific domain and get back the 56 names of any available servers. 58 Current defined dNSName GeneralName name forms only provide for DNS 59 host names to be expressed in "preferred name syntax," as specified 60 by RFC 1034 [N4]. This definition is not broad enough to allow 61 expression of a SRV RR. To accommodate expression of a SRV RR in 62 X.509 certificates this document therefore defines an otherName for 63 SRV RR. 65 As DNS query based on an SRV RR returns the name of the host 66 currently available for the requested service, reasonable subsequent 67 authentication of that host as the appropriate host for the service 68 will require the host to demonstrate that it is an authorized to 69 provide the requested service. 71 The ability to associate a host with a SRV RR in an X.509 certificate 72 therefore facilitates the binding of the host to the originally 73 requested SRV RR in order to protect against DNS spoofing attacks 74 where an altered DNS could return the host name of a rouge or hacked 75 host. 77 One example where expression of a SRV RR can be very useful is to 78 identify a host as a legitimate Kerberos KDC server. 80 2. SRV RR otherName 82 This section defines the SRVRRName as a form of otherName from the 83 GeneralName structure in SubjectAltName. 85 The SRVRRName if present MUST contain a Service Resource Record (SRV 86 RR) formed according to RFC 2782 [N3]. 88 The use of a SRVRRName is OPTIONAL. The SRVRRName is defined as 89 follows: 91 id-on-sRVRRName OBJECT IDENTIFIER ::= { id-on ? } 93 SRVRRName ::= IA5String 95 3 Security Considerations 97 Since assignment of services to hosts may be subject to change, 98 implementers should be aware of the issues involved with transfer and 99 suspension of services between different hosts to make sure that 100 issued certificates are up to date and that old inaccurate 101 certificates are revoked. 103 4 References 105 Normative references: 107 [N1] S. Bradner, "Key words for use in RFCs to Indicate 108 Requirement Levels", BCP 14, RFC 2119, March 1997. 110 [N2] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet 111 X.509 Public Key Infrastructure: Certificate and 112 Certificate Revocation List (CRL) Profile", RFC 3280, 113 April 2002. 115 [N3] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying the 116 location of services (DNS SRV)", RFC 2782, February 2000. 118 [N4] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", 119 RFC 1034, November 1987 121 Appendix A. ASN.1 definitions 123 TBD 125 Authors' Addresses 127 Stefan Santesson 128 Microsoft 129 Tuborg Boulevard 12 130 2900 Hellerup 131 Denmark 133 EMail: stefans@microsoft.com 135 Disclaimer 137 This document and the information contained herein are provided on an 138 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 139 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 140 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 141 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 142 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 143 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 145 Copyright Statement 147 Copyright (C) The Internet Society (2005). 149 This document is subject to the rights, licenses and restrictions 150 contained in BCP 78, and except as set forth therein, the authors 151 retain all their rights. 153 Expires November 2005