idnits 2.17.1 draft-ietf-smime-certcapa-00.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 180. ** 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 5 longer pages, the longest (page 3) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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 (April 2005) is 6950 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 146, but no explicit reference was found in the text == Unused Reference: 'RFC 3280' is defined on line 149, but no explicit reference was found in the text == Unused Reference: 'RFC 3851' is defined on line 154, 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 (~~), 8 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 April 2005 4 October 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 A ASN.1 definitions ........................................... 4 50 Authors' Addresses ............................................. 4 51 Disclaimer ..................................................... 5 52 Copyright Statement ............................................ 5 54 1. Introduction 56 The purpose of this specification is to specify means to minimize the 57 need to revert to default cryptographic settings in encrypted S/MIME 58 exchanges due to lack of knowledge about the opponents cryptographic 59 capabilities. 61 The S/MIME Capabilities attribute is defined in RFC 3851 to identify 62 the 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 for future exchange with the opponent. 67 The use of S/MIME does however introduce the scenario where a sender 68 of 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 its default 73 configuration for encrypted messages to recipients with unknown 74 capabilities. The problem is however that this default configuration 75 may not be compatible with the recipient's capabilities and/or 76 security policy. 78 The solution defined in this specification leverage on the fact that 79 S/MIME encryption requires possession of the recipient's public key 80 certificate. This certificate 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 will also have the capacity to identify the subject's 84 cryptographic capabilities for use with S/MIME, to be used as an 85 optional additional information resource when knowledge about the 86 subject capabilities is considered insufficient. 88 2. S/MIME Capabilities Extension 90 This section defines the S/MIME Capabilities extension. 92 The S/MIME capabilities extension data structure used in this 93 specification is identical to the data structure of the S/MIME 94 capabilities attribute defined in RFC 3633. 96 The S/MIME Capabilities extension MUST have the following definition: 98 smimeCapabilities OBJECT IDENTIFIER ::= 99 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 100 pkcs-9(9) 15} 102 sMIMECapabilitiesExt EXTENSION ::= { 103 SYNTAX SMIMECapabilities 104 IDENTIFIED BY smimeCapabilities } 106 SMIMECapabilities ::= SEQUENCE OF SMIMECapability 108 SMIMECapability ::= SEQUENCE { 109 capabilityID OBJECT IDENTIFIER, 110 parameters ANY DEFINED BY capabilityID OPTIONAL } 112 Algorithms should be ordered by preference 114 3. Use in applications 116 Applications using the S/MIME Capabilities extension SHOULD NOT use 117 information in the extension if more reliable and relevant 118 authenticated capabilities information are available to the 119 application. 121 It is outside the scope of this specification to define what is, or 122 is not, regarded as more reliable source of information by the 123 encrypting application. 125 4 Security Considerations 127 The S/MIME capabilities extension contains a statement about the 128 subject's capabilities made at the time of certificate issuance. 129 Implementers should therefore take into account any effect caused by 130 the change of these capabilities during the lifetime of the 131 certificate. 133 Change in the subject's capabilities during the lifetime of a 134 certificate may require revocation of the certificate. Revocation 135 should however only be motivated if a listed algorithm is considered 136 broken and/or considered too week to use for the adopted encryption 137 policy. 139 Implementers should take into account that the use of this extension 140 does not change the fact that it is always the responsibility of the 141 sender to choose sufficiently strong encryption for its information 142 disclosure. 144 5 References 146 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 147 Requirement Levels", BCP 14, RFC 2119, March 1997. 149 [RFC 3280] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet 150 X.509 Public Key Infrastructure: Certificate and 151 Certificate Revocation List (CRL) Profile", RFC 3280, 152 April 2002. 154 [RFC 3851] B. Ramsdell, "Secure/Multipurpose Internet Mail 155 Extensions (S/MIME) Version 3.1 Message Specification", 156 RFC 3851, July 2004 158 A. ASN.1 definitions 160 TBD 162 Authors' Addresses 164 Stefan Santesson 165 Microsoft 166 Tuborg Boulevard 12 167 2900 Hellerup 168 Denmark 170 EMail: stefans@microsoft.com 172 Disclaimer 174 This document and the information contained herein are provided on an 175 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 176 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 177 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 178 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 179 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 180 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 182 Copyright Statement 184 Copyright (C) The Internet Society (2004). This document is subject 185 to the rights, licenses and restrictions contained in BCP 78, and 186 except as set forth therein, the authors retain all their rights. 188 Expires April 2005