Network Working Group J. Herzog Internet-Draft R. Khazan Intended status: Informational MIT Lincoln Laboratory Expires: May 14, 2011 November 10, 2010 A set-key attribute for symmetric-key packages draft-herzog-setkey-01 Abstract A set-key is a symmetric key (or set of keys) associated with an immutable set of participants. This document defines a set-key attribute for use in the CMS-based symmetric-key package structure defined in in RFC XXXX. {{{ RFC Editor, please replace XXXX with the number assigned to draft-ietf-keyprov-symmetrickeyformat when it is published. }}} Disclaimer This work is sponsored by the United States Air Force under Air Force Contract FA8721-05-C-0002. Opinions, interpretations, conclusions and recommendations are those of the authors and are not necessarily endorsed by the United States Government. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 14, 2011. Herzog & Khazan Expires May 14, 2011 [Page 1] Internet-Draft A set-key attribute November 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Set-keys . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Symmetric key packages . . . . . . . . . . . . . . . . . . 3 1.3. Intended Usage . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Requirements Terminology . . . . . . . . . . . . . . . . . 5 2. The set-key attribute . . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Herzog & Khazan Expires May 14, 2011 [Page 2] Internet-Draft A set-key attribute November 2010 1. Introduction This document defines a new set-key attribute for use in the symmetric-key package structure defined in [Housley-symmkey]. 1.1. Set-keys A 'set-key' is a symmetric key associated with (and to be limited to) a specific set of participants. Such a key can be used in many ways, including: o To secure broadcast or multicasts of e.g., pay-per-view movies, o To secure group-communication such as chat rooms, or o To secure data-at-rest which belongs to a group (such as on an encrypted file-system or on a server). The only requirement of a set-key is that it be associated with a specific and unchanging set of participants. That is, we make a distinction between sets and groups. Sets are immutable structures: a set S of participants is a mathematical entity and does not change. A group, on the other hand, is a mutable structure that might have a certain name or set of names; may be under the control of a given administration; and may be mapped to a sequence of sets over time according to the needs of some particular application. This document considers only sets, and therefore will not consider issues such as group-administration, adding or removing members, revoking keys, and so on. Set-keys can be used to build group-keying protocols, but such issues are outside the scope of this document. We note that the participant-set of a set-key can be partitioned into two sub-sets: the active participants and the passive participants. In some set-key applications, such as group-chat, all participants may be active: both sending and receiving. In other applications, such as multicast of pay-per-view movies, most participants are passive: only receiving. Becuase it may be important in some applications to know which partipants are active and which are passive, we will allow these two sub-sets to be explicitly distinguished from each other. 1.2. Symmetric key packages The Cryptographic Message Syntax (CMS) [RFC5652] is a standard notation and representation for cryptographic messages. CMS is based on ASN.1 [X.680], [X.681], [X.682], [X.683] and uses that notation to define a number of structures relevant to cryptography such as certificates, encrypted or signed messages, and so on. Herzog & Khazan Expires May 14, 2011 [Page 3] Internet-Draft A set-key attribute November 2010 A current Internet Draft [Housley-symmkey] uses CMS to define a structure for symmetric key packages: collections of symmetric keys which share common properties and are intended for the same participants. The syntax for this structure follows: SymmetricKeyPackage ::= SEQUENCE { version KeyPkgVersion DEFAULT v1, sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute {{ SKeyPkgAttributes }} OPTIONAL, sKeys SymmetricKeys, ... } SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey OneSymmetricKey ::= SEQUENCE { sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute {{ SKeyAttributes }} OPTIONAL, sKey OCTET STRING OPTIONAL } ( WITH COMPONENTS { ..., sKeyAttrs PRESENT } | WITH COMPONENTS { ..., sKey PRESENT } ) KeyPkgVersion ::= INTEGER { v1(1) } ( v1, ... ) SKeyPkgAttributes ATTRIBUTE ::= { ... } SKeyAttributes ATTRIBUTE ::= { ... } A key-package (SymmetricKeyPackage) contains some meta-information, including attributes (sKeyPkgAttrs) [Housley-symmkey], and a sequence of key-structures. Each individual key-structure (OneSymmetricKey) contains some attributes (sKeyAttrs) and some actual keying material (sKey). Attributes in the sKeyPkgAttrs field apply to every key in the package, while attributes in a sKeyAttrs field apply only to the key in the containing OneSymmetricKey structure. The same attribute cannot appear at both the package-level and the key-level. That is, a given attribute can: o appear in the sKeyPkgAttrs field but not in the sKeyAttrs field of any OneSymmetricKey structure, o appear in the sKeyAttrs field of one or more OneSymmetricKey structures but not the sKeyPkgAttrs field, or o not be included in the key-package at all. Herzog & Khazan Expires May 14, 2011 [Page 4] Internet-Draft A set-key attribute November 2010 Also, it is not required that every attribute be applicable at both levels. That is, [Housley-symmkey] allows a given attribute to be valid for only the sKeyPkgAttrs field or for only the sKeyAttrs field. The grammar for attributes is quite complex and given in [Housley-symmkey]. We intend to use only a small subset of this grammar, and therefore do not reproduce it here. We note, however, that it can be used to define a wide variety of attributes, such as attributes to represent the expiration date of a key or key-package, the intended cryptographic algorithm for a key, an identifier for a key or key-package, or the creator of a key or key-package. As such attributes do not apply only to set-keys, however, we will not consider them futher in this document. 1.3. Intended Usage The attribute defined in this document is meant to be embedded in a SymmetricKeyPackage structure, perhaps with other attributes as well. The resulting value will then hold a set-key in a common and standard format. This format is appropriate both for transporting set-keys and for holding set-keys computed from some higher-level protocol. That is, one could create and distribute set-keys in this format through some distribution protocol, or one could use this format to hold set-keys computed by some protocol as Logical Key Heirarchy [RFC2627]. 1.4. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. The set-key attribute The set-key attribute is used to associate a participant-set with a symmetric key-package, where the participant-set MAY be divided into the active and passive participants. It has the following syntax: Herzog & Khazan Expires May 14, 2011 [Page 5] Internet-Draft A set-key attribute November 2010 aa-setkey-information ATTRIBUTE ::= { TYPE SetKeyInformation IDENTIFIED BY id-aa-setkey-information } id-aa-setkey-information OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) XX } SetKeyInformation::= SEQUENCE { active SetKeyParticipantSet, passive SetKeyParticipantSet OPTIONAL } SetKeyParticipantSet ::= CHOICE { union [0] SEQUENCE SIZE (2..MAX) OF SetKeyParticipantSet, intersection [1] SEQUENCE SIZE (2..MAX) OF SetKeyParticipantSet, setdiff [2] SEQUENCE { orig SetKeyParticipantSet, without SetKeyParticipantSet }, community [3] Community, groupID [4] OCTET STRING, explicit [5] SEQUENCE SIZE (1..MAX) OF SetMember, ...} SetMember ::= CHOICE { issuerAndSerialNumber [0] IssuerAndSerialNumber, publicKey [1] SubjectPublicKeyInfo, participantID [2] OCTET STRING, ...} This attribute SHOULD NOT appear in the sKeyAttrs field of a OneSymmetricKey structure. That is, it is defined to apply only to symmetric-key packages, not individual keys. The 'active' and 'passive' fields jointly identify the participant- set of this set-key. The 'active' field identifies the active members of this set, meaning those which may use the key to protect data or messages. The 'passive' field identifies the passive members of this set, meaning those participants who are expected to have this key but never use it to apply cryptographic protection to messages or data. (They may use the key to process such protection, however, such as to decrypt the data or verify its integrity.) Any member which could possibly send messages or protect data in some scenario SHOULD be in the 'active' field. A member MAY appear in both fields, in which case it SHOULD be considered to be active. The 'active' and 'passive' SetKeyParticipantSet values SHOULD NOT represent an empty set: Herzog & Khazan Expires May 14, 2011 [Page 6] Internet-Draft A set-key attribute November 2010 o An empty 'active' set indicates (absurdly) that the key will never be used to encrypt any messages or data, and o An empty 'participant' set SHOULD be omitted. Both the 'active' and 'passive' field will be values of type SetKeyParticipantSet. These values can be any of: o A 'union' of other SetKeyParticipantSet values. The sequence of SetKeyParticipentSet values MUST contain at least two members. The semantics of this sequence is as follows: a participant is in the union if and only if it is any of the SetKeyParticipantSet values of the sequence. If any set in the sequence is non-empty, then the union will be non-empty. If all sets in the union sequence are empty, then the union is empty as well. o The 'intersection' of other SetKeyParticipantSet values. The sequence of SetKeyParticipentSet values MUST contain at least two members. The semantics of this sequence is as follows: a participant is in intersection if and only if it is all of the SetKeyParticipantSet values of the sequence. If any set in the sequence is empty, the intersection is empty, too. If all sets in the sequence are non-empty, the intersection might still be empty (which it would be if there is no element common to all sets in the sequence). o The set-difference ('setdiff') of two other SetKeyParticipantSet values. The semantics of this is as follows: a participant is in the set-difference if and only if it is in the set identified in the 'orig' field and not in the set identified by the 'without' field. If the set identified in the 'orig' field is empty is empty, then the set-difference will be empty. If the set identified in the 'orig' field is a subset of the set identified in the 'without' field, then the set-difference will be empty. If neither of the two previous cases apply, the set-difference will be non-empty. o A community, which is used by the Trust Anchor Management Protocol (TAMP) [RFC5934] to identify a set of 'cryptographic modules.' Community values used in set-key attributes SHOULD represent unchanging sets of participants. o A 'groupID', which is interpreted in an application-independent way. One possible use for this option is to name pre-established groups such as organizational departments or roles. The details of establishing or using such a name-space are outside the scope of this document. However, the set of participants indicated by this value SHOULD be unchanging. Herzog & Khazan Expires May 14, 2011 [Page 7] Internet-Draft A set-key attribute November 2010 o An 'explicit' list of SetMember values. In this sequence, order is not given any meaning. This sequence MAY NOT be empty. This structure may be expanded at a later date with additional types. Implementations SHOULD gracefully handle values and types which they do not recognize. Although the 'active' and 'passive' values SHOULD NOT represent empty values, sub-components of these values MAY be empty. This is becuase resource-constrained entities may wish to do the miniumum processing required to verify that the 'active' and 'passive' sets are non- empty. If the 'active' value is a 'union' value at the top level, for example, the sender may wish to terminate processing when it first finds a non-empty component of that union (as opposed to confirming that every component represents a non-empty set). Senders MAY invest the processing necessary to ensure that no component of the 'active' and 'passive' sets represent non-empty sets, but receivers of these values MUST properly handle the case that a sub- component represents an empty set. A SetMember value, meant to identify a specific unique participant, can be any of: o An IssuerAndSerialNumber value, defined in [RFC5911], o A SubjectPublicKeyInfo, defined in [RFC5912], or o A freeform ('participantID') octet-string, which is interpreted in an application-dependent way. One possible use of this option is to use pre-established names for participants. However, such values SHOULD refer to a single participant, and SHOULD have a static (unchanging) meaning. The details of establishing or using such a name-space are outside the scope of this document. As above, this structure may be expanded at a later date with additional types. Implementations SHOULD gracefully handle values and types which they do not recognize. A single entity can be defined in multiple different ways and in different locations. One example of this is that a certified key can be identified using the IssuerAndSerialNumber option, the SubjectPublicKeyInfo, or some application specific method (for example, a common name) in the freeform field. This can cause ambiguity when evaluating a SetKeyParticipantSet. Suppose that a given key is sometimes identified using the IssuerAndSerialNumber form (value 'I') and sometimes identified using the SubjectPublicKeyInfor form (value 'S'). If these two distinct values are interpreted as identifying distinct keys, then the following Herzog & Khazan Expires May 14, 2011 [Page 8] Internet-Draft A set-key attribute November 2010 structures may be misinterpreted: o The 'explicit' sequence ...I, S... may be interpreted as having more elements than it actually does, due to the participant in question being counted twice (one for the I value, one for the S value). o Similarly, the structure "union {...I...} {...S...}" may be interpreted as containing one more participant than it actually does. o Likewise, the set "setdiff {...I...} {...S...}" may be interpreted as being non-empty when it is empty. o On the other hand, the set "intersection {...I...} {...S...}" may be interpreted as being empty when it should not. (It will always contain at least one element: the participant indicated by both I and S.) For these reasons, implementations SHOULD use a single method for identification of a single individual or have a well-established method of being able to compare the different locations that an individual could be identified in. If the set-key attribute is present, it MUST contain a single value. 3. Security Considerations As with the entire symmetric-key package, the set-key attribute is not protected. The symmetric key package content type can be combined with a security protocol to protect the contents of the attribute. 4. IANA Considerations This document makes use of object identifiers. These object identifiers are defined in an arc delegated to the IETF S/MIME Working Group. This arc and its registration procedures will be transferred to IANA soon. No further action by IANA is necessary for this document or any anticipated updates. 5. Acknowledgements The authors would like to thank Jim Schaad, Russ Housely and Sean Turner for their helpful comments and suggestions. Herzog & Khazan Expires May 14, 2011 [Page 9] Internet-Draft A set-key attribute November 2010 6. References 6.1. Normative References [Housley-symmkey] Turner, S. and R. Housley, "Symmetric Key Package Content Type", Internet Draft draft-ietf-keyprov-symmetrickeyformat-11.txt, August 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009. [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, June 2010. [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010. [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, August 2010. [X.680] ITU-T, "Information Technology - Abstract Syntax Notation One", Recommendation X.680, ISO/IEC 8824-1:2002, 2002. [X.681] ITU-T, "Information Technology - Abstract Syntax Notation One: Information Object Specification", Recommendation X.681, ISO/IEC 8824-2:2002, 2002. [X.682] ITU-T, "Information Technology - Abstract Syntax Notation One: Constraint Specification", Recommendation X.682, ISO/ IEC 8824-3:2002, 2002. [X.683] ITU-T, "Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications", Recommendation X.683, ISO/IEC 8824-4:2002, 2002. 6.2. Informative References [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999. Herzog & Khazan Expires May 14, 2011 [Page 10] Internet-Draft A set-key attribute November 2010 Appendix A. ASN.1 Module This appendix provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680] through [X.683]. SetKeyAttributev1 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) XX } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS ALL IMPORTS ATTRIBUTE FROM PKIX-CommonTypes-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} IssuerAndSerialNumber FROM CryptographicMessageSyntax-2009 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41)} SubjectPublicKeyInfo FROM PKIX1Explicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } Community FROM TAMP-Protocol-v2 { joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) modules(0) 30 } ; aa-setkey-information ATTRIBUTE ::= { TYPE SetKeyInformation IDENTIFIED BY id-aa-setkey-information } id-aa-setkey-information OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) XX } SetKeyInformation::= SEQUENCE { active SetKeyParticipantSet, passive SetKeyParticipantSet OPTIONAL } Herzog & Khazan Expires May 14, 2011 [Page 11] Internet-Draft A set-key attribute November 2010 SetKeyParticipantSet ::= CHOICE { union [0] SEQUENCE SIZE (2..MAX) OF SetKeyParticipantSet, intersection [1] SEQUENCE SIZE (2..MAX) OF SetKeyParticipantSet, setdiff [2] SEQUENCE { orig SetKeyParticipantSet, without SetKeyParticipantSet }, community [3] Community, groupID [4] OCTET STRING, explicit [5] SEQUENCE SIZE (1..MAX) OF SetMember, ...} SetMember ::= CHOICE { issuerAndSerialNumber [0] IssuerAndSerialNumber, publicKey [1] SubjectPublicKeyInfo, participantID [2] OCTET STRING, ...} END Authors' Addresses Jonathan C. Herzog MIT Lincoln Laboratory 244 Wood St. Lexington, MA 02144 USA Email: jherzog@ll.mit.edu Roger Khazan MIT Lincoln Laboratory 244 Wood St. Lexington, MA 02144 USA Email: rkh@ll.mit.edu Herzog & Khazan Expires May 14, 2011 [Page 12]