idnits 2.17.1 draft-leiba-smime-type-registry-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2013) is 3818 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 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Area B. Leiba 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track November 12, 2013 5 Expires: May 14, 2014 7 Creation of a registry for smime-type parameter values 8 draft-leiba-smime-type-registry-02 10 Abstract 12 Secure/Multipurpose Internet Mail Extensions (S/MIME) defined the 13 Content-Type parameter "smime-type". As the list of defined values 14 for that parameter has increased, it has become clear that a registry 15 is needed to document those values. This document creates that 16 registry, registers the current values, and specifies the policies 17 for registration of new values. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 14, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Normative References . . . . . . . . . . . . . . . . . . . 3 57 4.2. Informative References . . . . . . . . . . . . . . . . . . 3 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1. Introduction 62 Secure/Multipurpose Internet Mail Extensions (S/MIME) defined the 63 Content-Type "application/pkcs7-mime" and the parameter "smime-type", 64 along with four valid values for the parameter [RFC3851]. 65 Certificate Management over CMS (CMC) added two new parameter values 66 [RFC5273]. [RFC5751] replaced RFC 3851 and registered the 67 application/pkcs7-mime media type, but did not create a registry for 68 the smime-type values. 70 Enhanced Security Services for S/MIME [RFC2634] and Securing X.400 71 Content with S/MIME [RFC3854] also add smime-type values. 73 When Enrollment over Secure Transport [RFC7030] added another 74 parameter value, it became clear that a registry for smime-type 75 parameter values is necessary. Section 2 creates that registry, 76 registers the current values that are defined in the three previous 77 documents, and specifies the policies for registration of new values. 79 2. IANA Considerations 81 This document requests two IANA actions. 83 IANA is asked to change the reference field for the media type 84 "application/pkcs7-mime" to "[RFC5751], [RFC-leiba-smime-type- 85 registry]", replacing the latter with the RFC number for this RFC. 86 This replaces the references to RFC5273 and RFC7030 with this 87 document, as those references are no longer needed. 89 IANA is asked to create a new sub-registry under the Multipurpose 90 Internet Mail Extensions (MIME) and Media Types top-level registry. 91 The new registry is "Parameter values for the smime-type parameter", 92 the reference for the registry is "[RFC-leiba-smime-type-registry], 93 [RFC5751]", and the initial values for the registry are as follows: 95 +----------------------+-----------------------------------+ 96 | smime-type value | Reference | 97 +----------------------+-----------------------------------+ 98 | certs-only | [RFC5751] Section 3.2.2 | 99 | CMC-Request | [RFC5273] Section 3 | 100 | CMC-Response | [RFC5273] Section 3 | 101 | compressed-data | [RFC5751] Section 3.2.2 | 102 | enveloped-data | [RFC5751] Section 3.2.2 | 103 | enveloped-x400 | [RFC3854] Section 3.3.1 | 104 | server-generated-key | [RFC7030] Section 4.4.2 | 105 | signed-data | [RFC5751] Section 3.2.2 | 106 | signed-receipt | [RFC2634] Section 2.4, bullet 10 | 107 | signed-x400 | [RFC3854] Section 3.2.1 | 108 +----------------------+-----------------------------------+ 109 New values can be registered using the RFC Required policy, as 110 defined in [RFC5226]. The S/MIME Message Specification [RFC5751], 111 Section 3.2.2, specifies guidelines for assigning new smime-type 112 parameter values, and those guidelines apply to the assignment of 113 values in this registry. 115 3. Security Considerations 117 This document is purely administrative, and presents no security 118 issues. 120 4. References 122 4.1. Normative References 124 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 125 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 126 May 2008. 128 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 129 Mail Extensions (S/MIME) Version 3.2 Message 130 Specification", RFC 5751, January 2010. 132 4.2. Informative References 134 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 135 2634, June 1999. 137 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 138 Extensions (S/MIME) Version 3.1 Message Specification", 139 RFC 3851, July 2004. 141 [RFC3854] Hoffman, P., Bonatti, C. and A. Eggen, "Securing X.400 142 Content with Secure/Multipurpose Internet Mail Extensions 143 (S/MIME)", RFC 3854, July 2004. 145 [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS 146 (CMC): Transport Protocols", RFC 5273, June 2008. 148 [RFC7030] Pritikin, M., Yee, P. and D. Harkins, "Enrollment over 149 Secure Transport", RFC 7030, October 2013. 151 Author's Address 153 Barry Leiba 154 Huawei Technologies 156 Phone: +1 646 827 0648 157 Email: barryleiba@computer.org 158 URI: http://internetmessagingtechnology.org/