idnits 2.17.1 draft-ietf-smime-certcapa-02.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.5 on line 186. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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 (June 2005) is 6889 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: 'RFC 2119' is defined on line 156, but no explicit reference was found in the text == Unused Reference: 'RFC 3280' is defined on line 159, but no explicit reference was found in the text == Unused Reference: 'RFC 3851' is defined on line 164, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3851 (Obsoleted by RFC 5751) Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 June 2005 5 December 2004 7 Certificate extension for S/MIME Capabilities 8 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668 15 Status of this Memo 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 certificate extension for inclusion of S/MIME 36 capabilities in public key certificates defined by RFC 3280. 38 S/MIME Capabilities provides an optional method to communicate 39 cryptographic capabilities of the certified subject as a complement 40 to use of the S/MIME Capabilities signed attribute in S/MIME messages 41 according to RFC 3851. 43 Table of Contents 45 1 Introduction ................................................ 2 46 2 S/MIME Capabilities Extension ............................... 3 47 3 Use in applications ......................................... 3 48 4 Security Considerations ..................................... 3 49 5 References .................................................. 4 50 Authors' Addresses ............................................. 4 51 Disclaimer ..................................................... 5 52 Copyright Statement ............................................ 5 54 1. Introduction 56 The purpose of this specification is to specify a simple approach to 57 store cryptographic capabilities in public key certificates. 59 The S/MIME Capabilities attribute is defined in RFC 3851 for 60 specifying cryptographic capabilities of the sender of a signed 61 S/MIME message. This information can be used by the recipient in 62 subsequent S/MIME secured exchanges to select appropriate 63 cryptographic properties for future exchange with the opponent. 65 The use of S/MIME does however introduce the scenario where e.g. a 66 sender of an encrypted message has no prior established knowledge of 67 the recipient's cryptographic capabilities through recent S/MIME 68 exchanges. 70 In such case the sender is forced to rely on its default 71 configuration for encrypted messages to recipients with unknown 72 capabilities. The problem is however that this default configuration 73 may not be compatible with the recipient's capabilities and/or 74 security policy. 76 The solution defined in this specification leverages on the fact that 77 S/MIME encryption requires possession of the recipient's public key 78 certificate. This certificate contains information about the 79 recipient's public key and the cryptographic capabilities of this 80 key. Through the extension mechanism defined in this specification 81 the certificate will also have the capacity to identify the subject's 82 cryptographic capabilities for use with S/MIME, to be used as an 83 optional additional information resource when knowledge about the 84 subject capabilities is considered insufficient. 86 This document is limited to the "static" approach where asserted 87 cryptographic capabilities remain unchanged until the certificate 88 expires or is revoked. Other "dynamic" approaches which allow 89 retrieval of certified dynamically updatable capabilities during the 90 lifetime of a certificate are out of scope of this document. 92 2. S/MIME Capabilities Extension 94 This section defines the S/MIME Capabilities extension. 96 The S/MIME capabilities extension data structure used in this 97 specification is identical to the data structure of the S/MIME 98 capabilities attribute defined in RFC 3851. 100 The S/MIME Capabilities extension MUST follow the definition defined 101 in RFC 3851. (The ASN.1 structure of smimeCapabilities is included 102 below for illustrative purposes only) 104 smimeCapabilities OBJECT IDENTIFIER ::= 105 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 106 pkcs-9(9) 15} 108 sMIMECapabilitiesExt EXTENSION ::= { 109 SYNTAX SMIMECapabilities 110 IDENTIFIED BY smimeCapabilities } 112 SMIMECapabilities ::= SEQUENCE OF SMIMECapability 114 SMIMECapability ::= SEQUENCE { 115 capabilityID OBJECT IDENTIFIER, 116 parameters ANY DEFINED BY capabilityID OPTIONAL } 118 Algorithms should be ordered by preference. 120 This extension MUST NOT be marked critical. 122 3. Use in applications 124 Applications using the S/MIME Capabilities extension SHOULD NOT use 125 information in the extension if more reliable and relevant 126 authenticated capabilities information are available to the 127 application. 129 It is outside the scope of this specification to define what is, or 130 is not, regarded as more reliable source of information by the 131 encrypting application. 133 4 Security Considerations 135 The S/MIME capabilities extension contains a statement about the 136 subject's capabilities made at the time of certificate issuance. 137 Implementers should therefore take into account any effect caused by 138 the change of these capabilities during the lifetime of the 139 certificate. 141 Change in the subject's capabilities during the lifetime of a 142 certificate may require revocation of the certificate. Revocation 143 should however only be motivated if a listed algorithm is considered 144 broken and/or considered too weak to use for the adopted encryption 145 policy. 147 Implementers should take into account that the use of this extension 148 does not change the fact that it is always the responsibility of the 149 sender to choose sufficiently strong encryption for its information 150 disclosure. 152 5 References 154 Normative references: 156 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 157 Requirement Levels", BCP 14, RFC 2119, March 1997. 159 [RFC 3280] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet 160 X.509 Public Key Infrastructure: Certificate and 161 Certificate Revocation List (CRL) Profile", RFC 3280, 162 April 2002. 164 [RFC 3851] B. Ramsdell, "Secure/Multipurpose Internet Mail 165 Extensions (S/MIME) Version 3.1 Message Specification", 166 RFC 3851, July 2004 168 Authors' Addresses 170 Stefan Santesson 171 Microsoft 172 Tuborg Boulevard 12 173 2900 Hellerup 174 Denmark 176 EMail: stefans@microsoft.com 178 Disclaimer 180 This document and the information contained herein are provided on an 181 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 182 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 183 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 184 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 185 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 186 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 188 Copyright Statement 190 Copyright (C) The Internet Society (2004). This document is subject 191 to the rights, licenses and restrictions contained in BCP 78, and 192 except as set forth therein, the authors retain all their rights. 194 Expires June 2005