idnits 2.17.1 draft-ietf-keyprov-symmetrickeyformat-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (January 16, 2009) is 5579 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 222 == Outdated reference: A later version (-09) exists of draft-ietf-keyprov-pskc-00 -- Obsolete informational reference (is this intentional?): RFC 3852 (Obsoleted by RFC 5652) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 KEYPROV Working Group Sean Turner, IECA 2 Internet Draft Russ Housley, Vigil Security 3 Intended Status: Standard Track January 16, 2009 4 Expires: July 16, 2009 6 Symmetric Key Package Content Type 7 draft-ietf-keyprov-symmetrickeyformat-04.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on July 16, 2009. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. 44 Abstract 46 This document defines the symmetric key format content type. It is 47 transport independent. The Cryptographic Message Syntax can be used 48 to digitally sign, digest, authenticate, or encrypt this content 49 type. 51 Table of Contents 53 1. Introduction...................................................2 54 1.1. Requirements Terminology..................................2 55 1.2. ASN.1 Syntax Notation.....................................2 56 2. Symmetric Key Package Content Type.............................2 57 3. Security Considerations........................................4 58 4. IANA Considerations............................................4 59 5. References.....................................................4 60 5.1. Normative References......................................4 61 5.2. Non-Normative References..................................4 62 APPENDIX A: ASN.1 Module..........................................5 64 1. Introduction 66 This document defines the symmetric key format content type. It is 67 transport independent. The Cryptographic Message Syntax [RFC3852] can 68 be used to digitally sign, digest, authenticate, or encrypt this 69 content type. 71 The uses cases that motivated this work are elaborated in [PSKC]. 72 They are omitted to avoid duplication. 74 1.1. Requirements Terminology 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 1.2. ASN.1 Syntax Notation 82 The key package is defined using the ASN.1 [X.680, X.681, X.682, 83 X.683]. 85 2. Symmetric Key Package Content Type 87 The symmetric key package content type is used to transfer one or 88 more plaintext symmetric keys from one party to another. A symmetric 89 key package MAY be encapsulated in one or more CMS protecting content 90 types. This content type must be DER encoded [X.690]. 92 The symmetric key package content type has the following syntax: 94 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 96 symmetric-key-package PKCS7-CONTENT-TYPE ::= 97 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 99 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= | 100 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 101 smime(16) ct(1) 25 } 103 SymmetricKeyPackage ::= SEQUENCE { 104 version KeyPkgVersion DEFAULT v1, 105 sKeyPkgAtts [0] SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 106 sKeys SymmetricKeys } 108 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 110 OneSymmetricKey ::= SEQUENCE { 111 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 112 sKey OCTET STRING OPTIONAL 113 -- At least sKeyAttrs or sKey MUST be present. 114 } 116 KeyPkgVersion ::= INTEGER { v1(1), ... } 118 The SymmetricKeyPackage fields are used as follows: 120 - version identifies version of the symmetric key package content 121 structure. For this version of the specification, the default 122 value, v1, MUST be used. 124 - sKeyPkgAttrs optionally provides attributes that apply to all of 125 the symmetric keys in the package. If an attribute appears here it 126 MUST NOT also be included in sKeyAttrs. 128 - sKeys contains a sequence of OneSymmetricKey values. This 129 structure is discussed below. 131 The OneSymmetricKey fields are used as follows: 133 - sKeyAttrs optionally provides attributes that apply to one 134 symmetric key. If an attribute appears here it MUST NOT also be 135 included in sKeyPkgAttrs. 137 - sKey optionally contains the key value encoded as an OCTET STRING. 139 The OneSymmetricKey field MUST include either sKeyAttrs, sKey, or 140 sKeyAttrs and sKey. 142 3. Security Considerations 144 The symmetric key package contents are not protected. This content 145 type can be combined with a security protocol to protect the contents 146 of the package. 148 4. IANA Considerations 150 None: All identifiers are already registered. Please remove this 151 section prior to publication as an RFC. 153 5. References 155 5.1. Normative References 157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 158 Requirement Levels", BCP 14, RFC 2119, March 1997. 160 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 161 Information Technology - Abstract Syntax Notation One. 163 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 164 Information Technology - Abstract Syntax Notation One: Information 165 Object Specification. 167 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 168 Information Technology - Abstract Syntax Notation One: Constraint 169 Specification. 171 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 172 Information Technology - Abstract Syntax Notation One: 173 Parameterization of ASN.1 Specifications. 175 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 176 Information Technology - ASN.1 encoding rules: Specification of Basic 177 Encoding Rules (BER), Canonical Encoding Rules (CER) and 178 Distinguished Encoding Rules (DER). 180 5.2. Non-Normative References 182 [PSKC] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key 183 Container (PSKC), draft-ietf-keyprov-pskc-00.txt, work-in-progress. 185 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC3852, 186 July 2004. 188 APPENDIX A: ASN.1 Module 190 This appendix provides the normative ASN.1 definitions for the 191 structures described in this specification using ASN.1 as defined in 192 [X.680] through [X.683]. 194 SymmetricKeyPackageModulev1 195 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 196 smime(16) modules(0) 33 } 198 DEFINITIONS IMPLICIT TAGS ::= 200 BEGIN 202 -- EXPORTS ALL 204 -- IMPORTS NOTHING 206 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 208 KeyPackageContentTypes PKCS7-CONTENT-TYPE ::= { 209 symmetric-key-package | 210 ... -- Expect additional content types -- 211 } 213 symmetric-key-package PKCS7-CONTENT-TYPE ::= 214 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 216 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= 217 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 218 smime(16) ct(1) 25 } 220 SymmetricKeyPackage ::= SEQUENCE { 221 version KeyPkgVersion DEFAULT v1, 222 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 223 sKeys SymmetricKeys } 225 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 227 OneSymmetricKey ::= SEQUENCE { 228 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 229 sKey OCTET STRING OPTIONAL 230 -- At least sKeyAttrs or sKey MUST be present. 231 } 232 KeyPkgVersion ::= INTEGER { v1(1), ... } 234 Attribute ::= SEQUENCE { 235 type ATTRIBUTE.&id ({SupportedAttributes}), 236 values SET SIZE (1..MAX) OF ATTRIBUTE.&Type 237 ({SupportedAttributes}{@type}) } 239 SupportedAttributes ATTRIBUTE ::= { ... } 241 ATTRIBUTE ::= CLASS { 242 &derivation ATTRIBUTE OPTIONAL, 243 &Type OPTIONAL, 244 -- either &Type or &derivation required 245 &equality-match MATCHING-RULE OPTIONAL, 246 &ordering-match MATCHING-RULE OPTIONAL, 247 &substrings-match MATCHING-RULE OPTIONAL, 248 &single-valued BOOLEAN DEFAULT FALSE, 249 &collective BOOLEAN DEFAULT FALSE, 250 -- operational extensions 251 &no-user-modification BOOLEAN DEFAULT FALSE, 252 &usage AttributeUsage DEFAULT userApplications, 253 &id OBJECT IDENTIFIER UNIQUE } 254 WITH SYNTAX { 255 [ SUBTYPE OF &derivation ] 256 [ WITH SYNTAX &Type ] 257 [ EQUALITY MATCHING RULE &equality-match ] 258 [ ORDERING MATCHING RULE &ordering-match ] 259 [ SUBSTRINGS MATCHING RULE &substrings-match ] 260 [ SINGLE VALUE &single-valued ] 261 [ COLLECTIVE &collective ] 262 [ NO USER MODIFICATION &no-user-modification ] 263 [ USAGE &usage ] 264 ID &id } 266 MATCHING-RULE ::= CLASS { 267 &AssertionType OPTIONAL, 268 &id OBJECT IDENTIFIER UNIQUE } 269 WITH SYNTAX { 270 [ SYNTAX &AssertionType ] 271 ID &id } 273 AttributeType ::= ATTRIBUTE.&id 275 AttributeValue ::= ATTRIBUTE.&Type 276 AttributeUsage ::= ENUMERATED { 277 userApplications (0), 278 directoryOperation (1), 279 distributedOperation (2), 280 dSAOperation (3) } 282 END 284 Author's Address 286 Sean Turner 288 IECA, Inc. 289 3057 Nutley Street, Suite 106 290 Fairfax, VA 22031 291 USA 293 Email: turners@ieca.com 295 Russ Housley 297 Vigil Security, LLC 298 918 Spring Knoll Drive 299 Herndon, VA 20170 300 USA 302 EMail: housley@vigilsec.com