idnits 2.17.1 draft-harkins-application-csrattrs-media-type-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2012) is 4328 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-ipsec-pkix-est - is the name correct? ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2925 (Obsoleted by RFC 4560) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Harkins, Ed. 3 Internet-Draft Aruba Networks 4 Intended status: Informational S. Turner, Ed. 5 Expires: December 23, 2012 IECA, Inc 6 June 21, 2012 8 The application/csrattrs Media Type 9 draft-harkins-application-csrattrs-media-type-00 11 Abstract 13 This document specifies a media type used by Certification 14 Authorities (CAs) to indicate which attributes a client should 15 include in their Certification Request-- a PKCS#10 Certificate 16 Signing Request (CSR)-- when using Enrollment over Secure Transport 17 (EST). 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may not be modified, 23 and derivative works of it may not be created, except to format it 24 for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 23, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Distribution of Attributes . . . . . . . . . . . . . . . . . . 3 60 3. Format of the application/csrattrs Body . . . . . . . . . . . . 4 61 4. Receipt of the application/csrattrs Body . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 Enrollment over Secure Transport [EST] defines a Certificate 72 enrollment protocol that allows client to generate certification 73 request and transmit it to a server acting as a Certification 74 Authority (CA) or Registration Authority (RA). The CA then issues a 75 Certificate based on the certification request. 77 In some cases, the CA may want to include client-provided attributes 78 in certificates it issues. These attributes may describe information 79 that is not available to the CA, for instance the MAC address of a 80 client's wireless interface might be needed in a certificate used to 81 gain access to a wireless medium. The media type described here 82 allows the server to inform the client of a (set of) attribute(s) to 83 include, if possible, in its certification request. 85 This document defines a URI [RFC3986] that can be used with 86 Enrollment over Secure Transport (EST) protocol [EST]. 88 1.1. Requirements Language 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 [RFC2119]. 94 1.2. Terminology 96 The reader is assumed to be familiar with the terms and concepts of 97 [EST] and [RFC2986]. 99 Attribute 100 Any kind of identifying information that can be added to a 101 certification request. 103 2. Distribution of Attributes 105 Attribute request messages MUST be sent through the TLS-protected 106 channel [RFC5246] established as part of the [EST] protocol. 108 The request MUST be made with an HTTPS GET message to the common path 109 to the EST server-- referred to as BASEPATH-- with an OPERATIONPATH 110 extension of '/csrattrs'. For example, if BASEPATH had the value 111 arbitary/base then an example URI would be: 113 https://example.org/arbitrary/base/csrattrs 115 The server MUST reply to the client's HTTPS message with a (set of) 116 attribute(s). Responses to attribute request messsages MUST be 117 encoded as content type "application/csrattrs". 119 3. Format of the application/csrattrs Body 121 The syntax for application/csrattrs body is as follows: 123 Csrattrs ::= SEQUENCE SIZE (0..MAX) OF OBJECT IDENTIFIER { } 125 A robust application SHOULD output Distinguished Encoding Rules (DER) 126 ([X.690]) but MAY use Basic Encoding Rules (BER) ([X.680]). Data 127 produced by DER or BER is 8-bit. When the transport for the 128 application/csrattrs is limited to 7-bit data, a suitable transfer 129 encoding MUST be applied in MIME-compatible transports, the base64 130 encoding (section 4 of [RFC4648]) SHOULD be used with application/ 131 csrattrs, although any 7-bit transfer encoding may work. 133 Clients MUST encode csrattrs as an empty SEQUENCE OF. That is, no 134 object identifiers are included when the client creates an 135 application/csrattrs media type. For example, it would produce an 136 ASN.1 SEQUENCE: 138 30 00 140 and then base64 encode that ASN.1 SEQUENCE OF nothing to produce: 142 MA== 144 The resulting request would look like this: 146 Content-Type: application/csrattrs; name=attributes 147 Content-Transfer-Encoding: base64 148 Content-Disposition: attachment; filename=attributes 150 MA== 152 Servers include zero or more object identifiers that they wish the 153 client to include in their certification request. When the server 154 encodes csrattrs as an empty SEQUENCE OF it means that the server has 155 no attributes it wants in client certification requests. 157 For example, if a CA wishes to have a certification request contain 158 the MAC address [RFC2397] of a device and the pseudonym [X.520] and 159 friendly name [RFC2925] of the holder of the private analog to the 160 public key in the certification request, it takes the following 161 object identifiers: 163 o macAddress: 1.3.6.1.1.1.1.22 165 o pseudonym: 2.5.4.65 167 o friendlyName: 1.2.840.113549.1.9.20 169 and encodes them into an ASN.1 SEQUENCE to produce: 171 30 19 06 07 2b 06 01 01 01 01 16 06 03 55 04 41 06 09 2a 86 48 86 172 f7 0d 01 09 14 174 and then base64 encodes the resulting ASN.1 SEQUENCE to produce: 176 MBkGBysGAQEBARYGA1UEQQYJKoZIhvcNAQkU 178 The resulting response would look like this: 180 Content-Type: application/csrattrs; name=attributes 181 Content-Transfer-Encoding: base64 182 Content-Disposition: attachment; filename=attributes 184 MBkGBysGAQEBARYGA1UEQQYJKoZIhvcNAQkU 186 4. Receipt of the application/csrattrs Body 188 A server that obtains a non-empty SEQUENCE OF SHALL ignore the OBJECT 189 IDENTIFIERS in the application/csrattrs media type. 191 A client that obtains data using the application/csrattrs media type 192 SHALL decode the body of the data, as necessary, and parse the result 193 as an ASN.1 SEQUENCE of OBJECT IDENTIFIERS. An unknown OBJECT 194 IDENTIFIER MUST be ignored by the client and SHALL NOT be a reason to 195 not produce a certification request. A client SHOULD include every 196 known OBJECT IDENTIFIER it receives in an application/csrattrs media 197 type in its certification request with the appropriate value. 199 5. IANA Considerations 201 IANA SHALL update the Application Media Types registry with the 202 following filled-in template from [RFC4288]. 204 The media subtype for Attributes in a CertificationRequest is 205 application/csrattrs. 207 Type name: application 209 Subtype name: csrattrs 211 Required parameters: None 213 Optional parameters: None 215 Encoding considerations: binary; 217 Security Considerations: 219 Clients request a list of attributes that servers wish to be 220 in certification requests. The request/response SHOULD be done 221 in a TLS-protected tunnel. 223 Interoperability considerations: None 225 Published specification: This memo. 227 Applications which use this media type: 229 Enrollment over Secure Transport (EST) 231 Additional information: 233 Magic number(s): None 234 File extension: None 235 Macintosh File Type Code(s): 237 Person & email address to contact for further information: 239 Dan Harkins 241 Restrictions on usage: None 243 Author: Dan Harkins 245 Intentded usage: COMMON 247 Change controller: The IESG 249 6. Security Considerations 251 There are no real inherent security issues with the content being 252 conveyed but an adversary who is able to interpose herself into the 253 conversation could exclude attributes that a server may want, include 254 attributes that a server may not want, and render meaningless other 255 attributes that a server may want. 257 For this reason, this mime-type is used over a TLS-protected channel 258 established as part of the [EST] protocol. certification request 259 protocol whose Security Considerations would apply to the use of this 260 mime-type. 262 The Security Considerations of [RFC2986] and [EST] apply. 264 7. References 266 7.1. Normative References 268 [EST] Pritikin, M. and P. Yee, "Enrollment over Secure 269 Transport", draft-ietf-ipsec-pkix-est-01.txt (a work in 270 progress), March 2012. 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997. 275 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 276 Resource Identifier (URI): Generic Syntax", STD 66, 277 RFC 3986, January 2005. 279 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 280 Encodings", RFC 4648, October 2006. 282 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 283 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 285 [X.680] "ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002", 286 Information technology - Abstract Syntax Notation One 287 (ASN.1) Specification of basic notation.. 289 [X.690] "ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002", 290 Information technology - ASN.1 encoding rules: 291 Specification of Basic Encoding Rules (BER), Canonical 292 Encoding Rules (CER) and Distinguished Encoding Rules 293 (DER). 295 7.2. Informative References 297 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 298 August 1998. 300 [RFC2925] White, K., "Definitions of Managed Objects for Remote 301 Ping, Traceroute, and Lookup Operations", RFC 2925, 302 September 2000. 304 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 305 Request Syntax Specification Version 1.7", RFC 2986, 306 November 2000. 308 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 309 Registration Procedures", BCP 13, RFC 4288, December 2005. 311 [X.520] "ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005", 312 Information technology - Open Systems Interconnection The 313 Directory: Selected attribute types.. 315 Authors' Addresses 317 Dan Harkins (editor) 318 Aruba Networks 319 1322 Crossman Avenue 320 Sunnyvale, CA 94089-1113 321 United States of America 323 Email: dharkins@arubanetworks.com 325 Sean Turner (editor) 326 IECA, Inc 327 3057 Nutley Street, Suite 106 328 Fairfax, VA 22031 329 United States of America 331 Email: turners@ieca.com