idnits 2.17.1 draft-ietf-smime-certcapa-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 203. ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 6883 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 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3851 (Obsoleted by RFC 5751) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group S. Santesson (Microsoft) 3 INTERNET-DRAFT 4 Expires November 2005 May 2005 6 X.509 Certificate Extension for S/MIME Capabilities 7 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than a "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document defines a certificate extension for inclusion of S/MIME 35 capabilities in X.509 public key certificates, as defined by RFC 36 3280. 38 This certificate extension provides an optional method to indicate 39 the cryptographic capabilities of an entity as a complement to the 40 S/MIME Capabilities signed attribute in S/MIME messages according to 41 RFC 3851. 43 Table of Contents 45 1 Introduction ................................................ 2 46 1.1 Terminology ............................................... 3 47 2 S/MIME Capabilities Extension ............................... 3 48 3 Use in applications ......................................... 4 49 4 Security Considerations ..................................... 4 50 5 References .................................................. 5 51 Authors' Addresses ............................................. 5 52 Disclaimer ..................................................... 5 53 Copyright Statement ............................................ 5 55 1 Introduction 57 This document defines a certificate extension for inclusion of S/MIME 58 capabilities in X.509 public key certificates, as defined by RFC 3280 59 [RFC 3280]. 61 The S/MIME Capabilities attribute, defined in RFC 3851, is defined to 62 indicate cryptographic capabilities of the sender of a signed S/MIME 63 message. This information can be used by the recipient in subsequent 64 S/MIME secured exchanges to select appropriate cryptographic 65 properties. 67 S/MIME does however involve also the scenario where e.g. a sender of 68 an encrypted message has no prior established knowledge of the 69 recipient's cryptographic capabilities through recent S/MIME 70 exchanges. 72 In such case the sender is forced to rely on out-of-band means or its 73 default configuration to select content encryption algorithm for 74 encrypted messages to recipients with unknown capabilities. Such 75 default configuration may however be incompatible with the 76 recipient's capabilities and/or security policy. 78 The solution defined in this specification leverages the fact that 79 S/MIME encryption requires possession of the recipient's public key 80 certificate. This certificate already contains information about the 81 recipient's public key and the cryptographic capabilities of this 82 key. Through the extension mechanism defined in this specification 83 the certificate may also identify the subject's cryptographic S/MIME 84 capabilities. This may then be used as an optional information 85 resource to select appropriate encryption settings for the 86 communication. 88 This document is limited to the "static" approach where asserted 89 cryptographic capabilities remain unchanged until the certificate 90 expires or is revoked. Other "dynamic" approaches which allow 91 retrieval of certified dynamically updatable capabilities during the 92 lifetime of a certificate are out of scope of this document. 94 1.1 Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [STDWORDS]. 100 2 S/MIME Capabilities Extension 102 This section defines the S/MIME Capabilities extension. 104 The S/MIME capabilities extension data structure used in this 105 specification is identical to the data structure of the 106 SMIMECapabilities attribute defined in RFC 3851 [RFC 3851] (The ASN.1 107 structure of smimeCapabilities is included below for illustrative 108 purposes only). 110 smimeCapabilities OBJECT IDENTIFIER ::= 111 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 112 pkcs-9(9) 15} 114 SMIMECapabilities ::= SEQUENCE OF SMIMECapability 116 SMIMECapability ::= SEQUENCE { 117 capabilityID OBJECT IDENTIFIER, 118 parameters ANY DEFINED BY capabilityID OPTIONAL } 120 All content requirements defined for the SMIMECapabilities attribute 121 in RFC 3851 applies also to this extension. 123 There are numerous different types of S/MIME capabilities that have 124 been defined in various documents. While all of the different 125 capabilities can be placed in this extension, the intended purpose of 126 this specification is mainly to support inclusion of S/MIME 127 capabilities specifying content encryption algorithms. 129 CAs SHOULD limit the type of included S/MIME capabilities in this 130 extension to types that are considered relevant to the intended use 131 of the certificate. 133 Client applications processing this extensions MAY at its own 134 discretion ignore any present S/MIME capabilities and SHOULD always 135 gracefully ignore any present S/MIME capabilities that is not 136 consider relevant to its particular use of the certificate. 138 This extension MUST NOT be marked critical. 140 3 Use in applications 142 Applications using the S/MIME Capabilities extension SHOULD NOT use 143 information in the extension if more reliable and relevant 144 authenticated capabilities information are available to the 145 application. 147 It is outside the scope of this specification to define what is, or 148 is not, regarded as more reliable source of information by the 149 certificate using application. 151 4 Security Considerations 153 The S/MIME capabilities extension contains a statement about the 154 subject's capabilities made at the time of certificate issuance. 155 Implementers should therefore take into account any effect caused by 156 the change of these capabilities during the lifetime of the 157 certificate. 159 Change in the subject's capabilities during the lifetime of a 160 certificate may require revocation of the certificate. Revocation 161 should however only be motivated if a listed algorithm is considered 162 broken or considered too weak for the governing security policy. 164 Implementers should take into account that the use of this extension 165 does not change the fact that it is always the responsibility of the 166 sender to choose sufficiently strong encryption for its information 167 disclosure. 169 5 References 171 Normative references: 173 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, March 1997. 176 [RFC 3280] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet 177 X.509 Public Key Infrastructure: Certificate and 178 Certificate Revocation List (CRL) Profile", RFC 3280, 179 April 2002. 181 [RFC 3851] B. Ramsdell, "Secure/Multipurpose Internet Mail 182 Extensions (S/MIME) Version 3.1 Message Specification", 183 RFC 3851, July 2004 185 Authors' Addresses 187 Stefan Santesson 188 Microsoft 189 Tuborg Boulevard 12 190 2900 Hellerup 191 Denmark 193 EMail: stefans@microsoft.com 195 Disclaimer 197 This document and the information contained herein are provided on an 198 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 199 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 200 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 201 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 202 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 203 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 205 Copyright Statement 207 Copyright (C) The Internet Society (2005). 209 This document is subject to the rights, licenses and restrictions 210 contained in BCP 78, and except as set forth therein, the authors 211 retain all their rights. 213 Expires November 2005