idnits 2.17.1 draft-turner-symmetrickeyformat-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.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 356. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3852]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - sKeyPkgAttrs optionally provides attributes that apply to all of the symmetric keys in the package. If an attribute appears here it MUST not also be included in sKeyAttrs. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - sKeyAttrs optionally provides attributes that apply to one symmetric key. If an attribute appears here it MUST not also be included in sKeyPkgAttrs. -- 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 (July 1, 2007) is 6141 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) -- Looks like a reference, but probably isn't: '0' on line 288 -- Obsolete informational reference (is this intentional?): RFC 3852 (Obsoleted by RFC 5652) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sean Turner, IECA 2 Internet Draft Russ Housley, Vigil Security 3 Intended Status: Standard Track July 1, 2007 4 Expires: January 1, 2008 6 Symmetric Key Package Content Type 7 draft-turner-symmetrickeyformat-00.txt 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 as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on January 1, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document defines the symmetric key format content type. It is 41 transport independent. The Cryptographic Message Syntax [RFC3852] can 42 be used to digitally sign, digest, authenticate, or encrypt this 43 content type. 45 Table of Contents 47 1. Introduction...................................................2 48 1.1. Requirements Terminology..................................2 49 1.2. ASN.1 Syntax Notation.....................................2 50 2. Symmetric Key Package Content Type.............................3 51 3. Security Considerations........................................4 52 4. IANA Considerations............................................4 53 5. References.....................................................4 54 5.1. Normative References......................................4 55 5.2. Non-Normative References..................................4 56 APPENDIX A: ASN.1 Modules.........................................5 57 A.1. X.680 ASN.1 Module........................................5 58 A.2. X.208 ASN.1 Module........................................7 60 1. Introduction 62 This document defines the symmetric key format content type. It is 63 transport independent. The Cryptographic Message Syntax [RFC3852] can 64 be used to digitally sign, digest, authenticate, or encrypt this 65 content type. 67 1.1. Requirements Terminology 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 1.2. ASN.1 Syntax Notation 75 The key package is defined using the '93 ASN.1 [X.680, X.690]. A 76 module for the '88 [X.208, X.209] and the '93 ASN.1 syntax are 77 included. They result in the same encoding on the wire. 79 2. Symmetric Key Package Content Type 81 The symmetric key package content type is used to transfer one or 82 more plaintext symmetric keys from one party to another. A symmetric 83 key package MAY be encapsulated in one or more CMS protecting content 84 types. 86 The symmetric key package content type has the following syntax: 88 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 90 symmetric-key-package PKCS7-CONTENT-TYPE ::= 91 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 93 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= | 94 { TBD } 96 SymmetricKeyPackage ::= SEQUENCE { 97 version KeyPkgVersion DEFAULT v1, 98 sKeyPkgAtts [0] SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 99 sKeys SymmetricKeys } 101 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 103 OneSymmetricKey ::= SEQUENCE { 104 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 105 sKey OCTET STRING } 107 KeyPkgVersion ::= INTEGER { v1(1), ... } 109 The SymmetricKeyPackage fields are used as follows: 111 - version identifies version of the symmetric key package content 112 structure. For this version of the specification, the default 113 value, v1, MUST be used. 115 - sKeyPkgAttrs optionally provides attributes that apply to all of 116 the symmetric keys in the package. If an attribute appears here it 117 MUST not also be included in sKeyAttrs. 119 - sKeys contains a sequence of OneSymmetricKey values. This 120 structure is discussed below. 122 The OneSymmetricKey fields are used as follows: 124 - sKeyAttrs optionally provides attributes that apply to one 125 symmetric key. If an attribute appears here it MUST not also be 126 included in sKeyPkgAttrs. 128 - sKey contains the key value encoded as an OCTET STRING. 130 3. Security Considerations 132 The symmetric key package contents are not protected. This content 133 type can be combined with a security protocol to protect the contents 134 of the package. 136 4. IANA Considerations 138 None: All identifiers are already registered. Please remove this 139 section prior to publication as an RFC. 141 5. References 143 5.1. Normative References 145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 146 Requirement Levels", BCP 14, RFC 2119, March 1997. 148 [X.208] ITU-T Recommendation X.208: Information Technology - Abstract 149 Syntax Notation One, 1988. 151 [X.209] ITU-T Recommendation X.209 Information Technology - ASN.1 152 encoding rules: Specification of Basic Encoding Rules (BER), 153 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 154 (DER), 1988. 156 [X.680] ITU-T Recommendation X.680: Information Technology - Abstract 157 Syntax Notation One, 1997. 159 [X.690] ITU-T Recommendation X.690 Information Technology - ASN.1 160 encoding rules: Specification of Basic Encoding Rules (BER), 161 Canonical Encoding Rules (CER) and Distinguished Encoding Rules 162 (DER), 1997. 164 5.2. Non-Normative References 166 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC3852, 167 July 2004. 169 APPENDIX A: ASN.1 Modules 171 Appendix A.1 provides the normative ASN.1 definitions for the 172 structures described in this specification using ASN.1 as defined in 173 X.680. Appendix A.2 provides a module using ASN.1 as defined in 174 [X.208]. The module in A.2 removes usage of newer ASN.1 features 175 that provide support for limiting the types of elements that may 176 appear in certain SEQUENCE and SET constructions. Otherwise, the 177 modules are compatible in terms of encoded representation, i.e., the 178 modules are bits-on-the-wire compatible aside from the limitations on 179 SEQUENCE and SET constituents. A.2 is included as a courtesy to 180 developers using ASN.1 compilers that do not support current ASN.1. 182 A.1. X.680 ASN.1 Module 184 SymmetricKeyPackageModulev1-93 { tbd } 186 DEFINITIONS IMPLICIT TAGS ::= 188 BEGIN 190 -- EXPORTS ALL 192 -- IMPORTS NOTHING 194 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 196 KeyPackageContentTypes PKCS7-CONTENT-TYPE ::= { 197 symmetric-key-package | 198 ... -- Expect additional content types -- 199 } 201 symmetric-key-package PKCS7-CONTENT-TYPE ::= 202 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 204 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= 205 { TBD } 207 SymmetricKeyPackage ::= SEQUENCE { 208 version KeyPkgVersion DEFAULT v1, 209 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 210 sKeys SymmetricKeys } 212 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 213 OneSymmetricKey ::= SEQUENCE { 214 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 215 sKey OCTET STRING } 217 KeyPkgVersion ::= INTEGER { v1(1), ... } 219 Attribute ::= SEQUENCE { 220 type ATTRIBUTE.&id ({SupportedAttributes}), 221 values SET SIZE (1..MAX) OF ATTRIBUTE.&Type 222 ({SupportedAttributes}{@type}) } 224 SupportedAttributes ATTRIBUTE ::= { ... } 226 ATTRIBUTE ::= CLASS { 227 &derivation ATTRIBUTE OPTIONAL, 228 &Type OPTIONAL, 229 -- either &Type or &derivation required 230 &equality-match MATCHING-RULE OPTIONAL, 231 &ordering-match MATCHING-RULE OPTIONAL, 232 &substrings-match MATCHING-RULE OPTIONAL, 233 &single-valued BOOLEAN DEFAULT FALSE, 234 &collective BOOLEAN DEFAULT FALSE, 235 -- operational extensions 236 &no-user-modification BOOLEAN DEFAULT FALSE, 237 &usage AttributeUsage DEFAULT userApplications, 238 &id OBJECT IDENTIFIER UNIQUE } 239 WITH SYNTAX { 240 [ SUBTYPE OF &derivation ] 241 [ WITH SYNTAX &Type ] 242 [ EQUALITY MATCHING RULE &equality-match ] 243 [ ORDERING MATCHING RULE &ordering-match ] 244 [ SUBSTRINGS MATCHING RULE &substrings-match ] 245 [ SINGLE VALUE &single-valued ] 246 [ COLLECTIVE &collective ] 247 [ NO USER MODIFICATION &no-user-modification ] 248 [ USAGE &usage ] 249 ID &id } 251 MATCHING-RULE ::= CLASS { 252 &AssertionType OPTIONAL, 253 &id OBJECT IDENTIFIER UNIQUE } 254 WITH SYNTAX { 255 [ SYNTAX &AssertionType ] 256 ID &id } 258 AttributeType ::= ATTRIBUTE.&id 259 AttributeValue ::= ATTRIBUTE.&Type 261 AttributeUsage ::= ENUMERATED { 262 userApplications (0), 263 directoryOperation (1), 264 distributedOperation (2), 265 dSAOperation (3) } 267 END 269 A.2. X.208 ASN.1 Module 271 SymmetricKeyPackageModulev1-88 { tbd } 273 DEFINITIONS IMPLICIT TAGS ::= 275 BEGIN 277 -- EXPORTS ALL 279 -- IMPORTS NOTHING 281 -- Symmetric Key Package Content Type and Object Identifier 283 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= 284 { TBD } 286 SymmetricKeyPackage ::= SEQUENCE { 287 version KeyPkgVersion DEFAULT v1, 288 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 289 sKeys SymmetricKeys } 291 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 293 OneSymmetricKey ::= SEQUENCE { 294 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 295 sKey OCTET STRING } 297 KeyPkgVersion ::= INTEGER { v1(1), ... } 299 Attribute ::= SEQUENCE { 300 attrType OBJECT IDENTIFIER, 301 attrValues SET OF AttributeValue } 303 AttributeValue ::= ANY 305 END 306 Editor's Address 308 Sean Turner 309 IECA, Inc. 311 Email: turners (at) ieca (dot) com 313 Russ Housley 314 Vigil Security 316 Email: housley (at) vigilsec (dot) com 318 Full Copyright Statement 320 Copyright (C) The IETF Trust (2007). 322 This document is subject to the rights, licenses and restrictions 323 contained in BCP 78, and except as set forth therein, the authors 324 retain all their rights. 326 This document and the information contained herein are provided on an 327 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 328 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 329 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 330 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 331 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 332 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 334 Intellectual Property 336 The IETF takes no position regarding the validity or scope of any 337 Intellectual Property Rights or other rights that might be claimed to 338 pertain to the implementation or use of the technology described in 339 this document or the extent to which any license under such rights 340 might or might not be available; nor does it represent that it has 341 made any independent effort to identify any such rights. Information 342 on the procedures with respect to rights in RFC documents can be 343 found in BCP 78 and BCP 79. 345 Copies of IPR disclosures made to the IETF Secretariat and any 346 assurances of licenses to be made available, or the result of an 347 attempt made to obtain a general license or permission for the use of 348 such proprietary rights by implementers or users of this 349 specification can be obtained from the IETF on-line IPR repository at 350 http://www.ietf.org/ipr. 352 The IETF invites any interested party to bring to its attention any 353 copyrights, patents or patent applications, or other proprietary 354 rights that may cover technology that may be required to implement 355 this standard. Please address the information to the IETF at ietf- 356 ipr@ietf.org. 358 Acknowledgment 360 Funding for the RFC Editor function is provided by the IETF 361 Administrative Support Activity (IASA).