idnits 2.17.1 draft-ietf-smime-certcapa-03.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 198. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines 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 (August 2005) is 6829 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 3280' is defined on line 171, 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 (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Stefan Santesson 3 Microsoft Security Center of Excellence (SCOE) 5 S/MIME Working Group S. Santesson (Microsoft) 6 INTERNET-DRAFT 7 Expires August 2005 8 February 2005 10 Certificate extension for S/MIME Capabilities 11 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668 18 Status of this Memo 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than a "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This document defines a certificate extension for inclusion of S/MIME 39 capabilities in public key certificates defined by RFC 3280. 41 S/MIME Capabilities provides an optional method to communicate 42 cryptographic capabilities of the certified subject as a complement 43 to use of the S/MIME Capabilities signed attribute in S/MIME messages 44 according to RFC 3851. 46 Table of Contents 48 1 Introduction ................................................ 2 49 1.1 Terminology ............................................... 3 50 2 S/MIME Capabilities Extension ............................... 3 51 3 Use in applications ......................................... 3 52 4 Security Considerations ..................................... 4 53 5 References .................................................. 4 54 Authors' Addresses ............................................. 5 55 Disclaimer ..................................................... 5 56 Copyright Statement ............................................ 5 58 1 Introduction 60 This document defines a certificate extension for inclusion of S/MIME 61 capabilities in public key certificates defined by RFC 3280 [RFC 62 3280]. 64 The S/MIME Capabilities attribute is defined in RFC 3851 for 65 specifying cryptographic capabilities of the sender of a signed 66 S/MIME message. This information can be used by the recipient in 67 subsequent S/MIME secured exchanges to select appropriate 68 cryptographic properties for future exchange with the opponent. 70 The use of S/MIME does however introduce the scenario where e.g. a 71 sender of an encrypted message has no prior established knowledge of 72 the recipient's cryptographic capabilities through recent S/MIME 73 exchanges. 75 In such case the sender is forced to rely on its default 76 configuration for encrypted messages to recipients with unknown 77 capabilities. The problem is however that this default configuration 78 may not be compatible with the recipient's capabilities and/or 79 security policy. 81 The solution defined in this specification leverages on the fact that 82 S/MIME encryption requires possession of the recipient's public key 83 certificate. This certificate contains information about the 84 recipient's public key and the cryptographic capabilities of this 85 key. Through the extension mechanism defined in this specification 86 the certificate will also have the capacity to identify the subject's 87 cryptographic capabilities for use with S/MIME, to be used as an 88 optional additional information resource when knowledge about the 89 subject capabilities is considered insufficient. 91 This document is limited to the "static" approach where asserted 92 cryptographic capabilities remain unchanged until the certificate 93 expires or is revoked. Other "dynamic" approaches which allow 94 retrieval of certified dynamically updatable capabilities during the 95 lifetime of a certificate are out of scope of this document. 97 1.1 Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [STDWORDS]. 103 2 S/MIME Capabilities Extension 105 This section defines the S/MIME Capabilities extension. 107 The S/MIME capabilities extension data structure used in this 108 specification is identical to the data structure of the 109 SMIMECapabilities attribute defined in RFC 3851 [RFC 3851]. 111 The S/MIME Capabilities extension MUST follow the requirements and 112 definitions defined in RFC 3851. (The ASN.1 structure of 113 smimeCapabilities is included below for illustrative purposes only) 115 smimeCapabilities OBJECT IDENTIFIER ::= 116 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 117 pkcs-9(9) 15} 119 sMIMECapabilitiesExt EXTENSION ::= { 120 SYNTAX SMIMECapabilities 121 IDENTIFIED BY smimeCapabilities } 123 SMIMECapabilities ::= SEQUENCE OF SMIMECapability 125 SMIMECapability ::= SEQUENCE { 126 capabilityID OBJECT IDENTIFIER, 127 parameters ANY DEFINED BY capabilityID OPTIONAL } 129 This extension is expected to hold the same type of capability data 130 as the SMIMECapabilities attribute defined in RFC 3851. 132 This extension MUST NOT be marked critical. 134 3 Use in applications 136 Applications using the S/MIME Capabilities extension SHOULD NOT use 137 information in the extension if more reliable and relevant 138 authenticated capabilities information are available to the 139 application. 141 It is outside the scope of this specification to define what is, or 142 is not, regarded as more reliable source of information by the 143 encrypting application. 145 4 Security Considerations 147 The S/MIME capabilities extension contains a statement about the 148 subject's capabilities made at the time of certificate issuance. 149 Implementers should therefore take into account any effect caused by 150 the change of these capabilities during the lifetime of the 151 certificate. 153 Change in the subject's capabilities during the lifetime of a 154 certificate may require revocation of the certificate. Revocation 155 should however only be motivated if a listed algorithm is considered 156 broken and/or considered too weak to use for the adopted encryption 157 policy. 159 Implementers should take into account that the use of this extension 160 does not change the fact that it is always the responsibility of the 161 sender to choose sufficiently strong encryption for its information 162 disclosure. 164 5 References 166 Normative references: 168 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 169 Requirement Levels", BCP 14, RFC 2119, March 1997. 171 [RFC 3280] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet 172 X.509 Public Key Infrastructure: Certificate and 173 Certificate Revocation List (CRL) Profile", RFC 3280, 174 April 2002. 176 [RFC 3851] B. Ramsdell, "Secure/Multipurpose Internet Mail 177 Extensions (S/MIME) Version 3.1 Message Specification", 178 RFC 3851, July 2004 180 Authors' Addresses 182 Stefan Santesson 183 Microsoft 184 Tuborg Boulevard 12 185 2900 Hellerup 186 Denmark 188 EMail: stefans@microsoft.com 190 Disclaimer 192 This document and the information contained herein are provided on an 193 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 194 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 195 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 196 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 197 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 198 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 200 Copyright Statement 202 Copyright (C) The Internet Society (2004). This document is subject 203 to the rights, licenses and restrictions contained in BCP 78, and 204 except as set forth therein, the authors retain all their rights. 206 Expires August 2005