idnits 2.17.1 draft-turner-application-pkcs10-media-type-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2986, but the abstract doesn't seem to directly say this. It does mention RFC2986 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended Status: Informational Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) (Using the creation date from RFC2986, updated by this document, for RFC5378 checks: 2000-07-12) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 3, 2010) is 5196 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) ** Downref: Normative reference to an Informational RFC: RFC 2986 -- Obsolete informational reference (is this intentional?): RFC 2633 (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Turner 2 Internet Draft IECA 3 Intended Status: Informational Track February 3, 2010 4 Updates: 2986 (once approved) 5 Expires: August 3, 2010 7 The application/pkcs10 Media Type 8 draft-turner-application-pkcs10-media-type-00.txt 10 Abstract 12 This document specifies a media type used to carry PKCS#10 13 certification requests as defined in RFC 2986. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 3, 2010. 48 Copyright Notice 50 Copyright (c) 2010 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 1. Introduction 65 [RFC2311] first defined the application/pkcs10 media type. When 66 [RFC2633] was published, the application/pkcs10 section was dropped, 67 but for some reason the text was not incorporated in to PKCS#10 68 [RFC2986]. [RFC2311] was moved to historic status by [RFC5751]. To 69 ensure the IANA media type registration points to a non-historic 70 document, this document updates [RFC2986] with the application/pkcs10 71 mime media type registration. 73 The text for Section 2 is taken directly from Section 3.7 of 74 [RFC2311]. 76 1.1. Requirements Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 2. Creating a Certification Request 84 A typical application which allows a user to generate cryptographic 85 information has to submit that information to a certification 86 authority, who transforms it into a certificate. PKCS #10 describes 87 a syntax for certification requests. The application/pkcs10 body type 88 MUST be used to transfer a PKCS #10 certification request. 90 The details of certification requests and the process of obtaining a 91 certificate are beyond the scope of this memo. Instead, only the 92 format of data used in application/pkcs10 is defined. 94 2.1. Format of the application/pkcs10 Body 96 PKCS #10 defines the ASN.1 type CertificationRequest for use in 97 submitting a certification request. Therefore, when the MIME content 98 type application/pkcs10 is used, the body MUST be a 99 CertificationRequest, encoded using the Basic Encoding Rules (BER) 100 [X.690]. 102 Although BER is specified, instead of the more restrictive DER 103 [X.690], a typical application will use DER since the 104 CertificationRequest's CertificationRequestInfo has to be DER-encoded 105 in order to be signed. 107 A robust application SHOULD output DER, but allow BER or DER on 108 input. 110 Data produced by BER or DER is 8-bit, but many transports are limited 111 to 7-bit data. Therefore, a suitable 7-bit Content-Transfer-Encoding 112 SHOULD be applied. The base64 Content-Transfer-Encoding [RFC4648] 113 SHOULD be used with application/pkcs10, although any 7-bit transfer 114 encoding may work. 116 2.2. Sending and Receiving an application/pkcs10 Body Part 118 For sending a certificate-signing request, the application/pkcs10 119 message format MUST be used to convey a PKCS #10 certificate-signing 120 request. Note that for sending certificates and CRLs messages without 121 any signed content, the application/pkcs7-mime message format MUST be 122 used to convey a degenerate PKCS #7 signedData "certs-only" message 123 [RFC5751]. 125 To send an application/pkcs10 body, the application generates the 126 cryptographic information for the user. The details of the 127 cryptographic information are beyond the scope of this memo. 129 Step 1. The cryptographic information is placed within a PKCS #10 130 CertificationRequest. 132 Step 2. The CertificationRequest is encoded according to BER or DER 133 (typically, DER). 135 Step 3. As a typical step, the DER-encoded CertificationRequest is 136 also base64 encoded so that it is 7-bit data suitable for transfer in 137 SMTP. This then becomes the body of an application/pkcs10 body part. 139 The result might look like this: 141 Content-Type: application/pkcs10; name=smime.p10 142 Content-Transfer-Encoding: base64 143 Content-Disposition: attachment; filename=smime.p10 145 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 146 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H 147 f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 148 0GhIGfHfQbnj756YT64V 150 A typical application only needs to send a certification request. It 151 is a certification authority that has to receive and process the 152 request. The steps for recovering the CertificationRequest from the 153 message are straightforward but are not presented here. The 154 procedures for processing the certification request are beyond the 155 scope of this document. 157 3. IANA Considerations 159 The media type for a PKCS#10 certification request is 160 application/pkc10. 162 Type name: application 164 Subtype name: pkcs10 166 Required parameters: None 168 Optional parameters: None 170 Encoding considerations: See Section 2. 172 Security considerations: 174 Clients use a certification request to request that a 175 Certification Authority certify a public key. The certification 176 request is digitally signed. 178 Interoperability considerations: See Section 2. 180 Published specification: RFC 2986 182 Applications which use this media type: 184 The content type is used with MIME-complaint transport to 185 transfer PKCS#10 certification requests [PKCS#10]. 187 Additional information: 189 Magic number(s): None 190 File extension(s): .p10 191 Macintosh File Type Code(s): none 193 Person & email address to contact for further information: 194 Sean Turner 195 turners@ieca.com 197 Restrictions on usage: none 199 Author: 200 Sean Turner 202 Intended usage: COMMON 204 Change controller: 205 The IESG 207 4. Security Considerations 209 The security considerations of [RFC2986] and [RFC5751] apply; 210 however, no new security considerations are introduced by this 211 document. 213 5. References 215 5.1. Normative References 217 [RFC2986] Nystrom, M, and B. Kaliski, " PKCS #10: Certification 218 Request Syntax Specification Version 1.7", RFC 2986, 219 November 2000. 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, March 1997. 224 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 225 Encodings", RFC 4648, October 2006. 227 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 228 1:2002. Information Technology - ASN.1 encoding rules: 229 Specification of Basic Encoding Rules (BER), Canonical 230 Encoding Rules (CER) and Distinguished Encoding Rules 231 (DER). 233 5.2. Informative References 235 [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., 236 and L. Repka, "S/MIME Version 2 Message Specification", 237 RFC 2311, March 1998. 239 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 240 RFC 2633, June 1999. 242 [RFC5751] Turner, S. and B. Ramsdell, "Secure/Multipurpose 243 Internet Mail Extensions (S/MIME) Version 3.2 Message 244 Specification", RFC 5751, January 2010. 246 Acknowledgements 248 I wish to thank the authors of RFC 2311, Steve Dusse, Paul Hoffman, 249 Blake Ramsdell, Laurence Lundblade, and Lisa Repka. 251 Authors' Addresses 253 Sean Turner 255 IECA, Inc. 256 3057 Nutley Street, Suite 106 257 Fairfax, VA 22031 258 USA 260 EMail: turners@ieca.com