idnits 2.17.1 draft-ietf-smime-certcapa-01.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. ** There is 1 instance of too long lines in the document, the longest one being 29 characters in excess of 72. 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 (May 2005) is 6914 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 155, 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 3851 (Obsoleted by RFC 5751) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group S. Santesson (Microsoft) 2 INTERNET-DRAFT 3 Expires May 2005 4 November 2004 6 Certificate extension for S/MIME Capabilities 7 9 By submitting this Internet-Draft, I certify that any applicable 10 patent or other IPR claims of which I am aware have been disclosed, 11 or will be disclosed, and any of which I become aware will be 12 disclosed, in accordance with RFC 3668 14 Status of this Memo 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 public key certificates defined by RFC 3280. 37 S/MIME Capabilities provides an optional method to communicate 38 cryptographic capabilities of the certified subject as a complement 39 to use of the S/MIME Capabilities signed attribute in S/MIME messages 40 according to RFC 3851. 42 Table of Contents 44 1 Introduction ................................................ 2 45 2 S/MIME Capabilities Extension ............................... 3 46 3 Use in applications ......................................... 3 47 4 Security Considerations ..................................... 3 48 5 References .................................................. 4 49 Authors' Addresses ............................................. 4 50 Disclaimer ..................................................... 5 51 Copyright Statement ............................................ 5 53 1. Introduction 55 The purpose of this specification is to specify a simple approach to 56 store cryptographic capabilities in public key certificates. 58 The S/MIME Capabilities attribute is defined in RFC 3851 to identify 59 the cryptographic capabilities of the sender of a signed S/MIME 60 message. This information can be used by the recipient in subsequent 61 S/MIME secured exchanges to select appropriate cryptographic 62 properties for future exchange with the opponent. 64 The use of S/MIME does however introduce the scenario where a sender 65 of an encrypted message has no prior established knowledge of the 66 recipient's cryptographic capabilities through recent S/MIME 67 exchanges. 69 In such case the sender is forced to rely on its default 70 configuration for encrypted messages to recipients with unknown 71 capabilities. The problem is however that this default configuration 72 may not be compatible with the recipient's capabilities and/or 73 security policy. 75 The solution defined in this specification leverages on the fact that 76 S/MIME encryption requires possession of the recipient's public key 77 certificate. This certificate contains information about the 78 recipient's public key and the cryptographic capabilities of this 79 key. Through the extension mechanism defined in this specification 80 the certificate will also have the capacity to identify the subject's 81 cryptographic capabilities for use with S/MIME, to be used as an 82 optional additional information resource when knowledge about the 83 subject capabilities is considered insufficient. 85 This document is limited to the "static" approach where asserted 86 cryptographic capabilities remain unchanged until the certificate 87 expires or is revoked. Other "dynamic" approaches which allow 88 retrieval of certified dynamically updatable capabilities during the 89 lifetime of a certificate are out of scope of this document. 91 2. S/MIME Capabilities Extension 93 This section defines the S/MIME Capabilities extension. 95 The S/MIME capabilities extension data structure used in this 96 specification is identical to the data structure of the S/MIME 97 capabilities attribute defined in RFC 3851. 99 The S/MIME Capabilities extension MUST follow the definition defined 100 in RFC 3851. (The ASN.1 structure of smimeCapabilities is included 101 below for illustrative purposes only) 103 smimeCapabilities OBJECT IDENTIFIER ::= 104 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 105 pkcs-9(9) 15} 107 sMIMECapabilitiesExt EXTENSION ::= { 108 SYNTAX SMIMECapabilities 109 IDENTIFIED BY smimeCapabilities } 111 SMIMECapabilities ::= SEQUENCE OF SMIMECapability 113 SMIMECapability ::= SEQUENCE { 114 capabilityID OBJECT IDENTIFIER, 115 parameters ANY DEFINED BY capabilityID OPTIONAL } 117 Algorithms should be ordered by preference. 119 This extension MUST NOT be marked critical. 121 3. Use in applications 123 Applications using the S/MIME Capabilities extension SHOULD NOT use 124 information in the extension if more reliable and relevant 125 authenticated capabilities information are available to the 126 application. 128 It is outside the scope of this specification to define what is, or 129 is not, regarded as more reliable source of information by the 130 encrypting application. 132 4 Security Considerations 134 The S/MIME capabilities extension contains a statement about the 135 subject's capabilities made at the time of certificate issuance. 136 Implementers should therefore take into account any effect caused by 137 the change of these capabilities during the lifetime of the 138 certificate. 140 Change in the subject's capabilities during the lifetime of a 141 certificate may require revocation of the certificate. Revocation 142 should however only be motivated if a listed algorithm is considered 143 broken and/or considered too week to use for the adopted encryption 144 policy. 146 Implementers should take into account that the use of this extension 147 does not change the fact that it is always the responsibility of the 148 sender to choose sufficiently strong encryption for its information 149 disclosure. 151 5 References 153 Normative references: 155 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 156 Requirement Levels", BCP 14, RFC 2119, March 1997. 158 [RFC 159 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 May 2005 196 Attachment Converted: C:\Program Files\Qualcomm\Eudora\attachements\draft-ietf-smime-certcapa-011.nro