[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07

Network Working Group                                          J. Herzog
Internet-Draft                                                 R. Khazan
Intended status: Experimental                     MIT Lincoln Laboratory
Expires: April 7, 2013                                   October 4, 2012


             A set-key attribute for symmetric-key packages
                         draft-herzog-setkey-07

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
   [RFC6031].

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 in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 7, 2013.

Copyright Notice

   Copyright (c) 2012 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



Herzog & Khazan           Expires April 7, 2013                 [Page 1]

Internet-Draft             A set-key attribute              October 2012


   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 Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Set-keys . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Symmetric key packages . . . . . . . . . . . . . . . . . .  4
     1.3.  Intended Usage . . . . . . . . . . . . . . . . . . . . . .  5
     1.4.  Requirements Terminology . . . . . . . . . . . . . . . . .  5
   2.  The set-key attribute  . . . . . . . . . . . . . . . . . . . .  5
   3.  Attribute generation . . . . . . . . . . . . . . . . . . . . .  9
   4.  Attribute processing . . . . . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 18
   Appendix B.  ASN.1 structures for Attributes . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
























Herzog & Khazan           Expires April 7, 2013                 [Page 2]

Internet-Draft             A set-key attribute              October 2012


1.  Introduction

   This document defines a new set-key attribute for use in the
   symmetric-key package structure defined in [RFC6031].

1.1.  Set-keys

   A 'set-key' is a symmetric key associated with (and to be limited to)
   a specific set of participants (entities).  The exact definition of
   'participant', in the context of a particular key, will depend on the
   key's intended application.  Roughly speaking, however, the set of
   participants corresponds to the collection of individual agents which
   must possess and use the key for the key's intended purpose.  In
   practice, a 'participant' will often be an entity with a certified
   public key, but other definitions of 'participant' are possible.

   A set-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, this document
   draws a distinction between sets and groups.

   o  Sets are immutable structures: a set S of participants is a
      mathematical entity and does not change.

   o  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.

   By the 'participant-set' of a set-key, we mean the set of
   participants associated with the set-key.  We further 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



Herzog & Khazan           Expires April 7, 2013                 [Page 3]

Internet-Draft             A set-key attribute              October 2012


   of pay-per-view movies, most participants are passive: only
   receiving.  Because 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.

   [RFC6031] 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) [RFC6031], 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



Herzog & Khazan           Expires April 7, 2013                 [Page 4]

Internet-Draft             A set-key attribute              October 2012


   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.

   Also, it is not required that every attribute be applicable at both
   levels.  That is, [RFC6031] 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 [RFC5912].
   (We also reproduce the relevant portion in Appendix B.)  We intend to
   use only a small subset of this grammar, and therefore do not
   consider the full definition of attributes 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 Hierarchy
   [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 April 7, 2013                 [Page 5]

Internet-Draft             A set-key attribute              October 2012


   aa-setkey-information ATTRIBUTE ::= {
        TYPE SetKeyInformation
        IDENTIFIED BY id-aa-setKeyInformation }

   id-aa-setKeyInformation     OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
            smime(16) aa(2) 53 }

   SetKeyInformation::= SEQUENCE {
        active     SetKeyParticipantSet,
        passive    SetKeyParticipantSet OPTIONAL }


   This attribute MUST NOT appear in both the sKeyPkgAttrs field of a
   SymmetricKeyPackage structure and the sKeyAttrs field of a
   OneSymmetricKey structure.  Furthermore, the sKeyPkgAttrs field of a
   SymmetricKeyPackage MUST contain either zero or one instance of a
   set-key attribute.

   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.)

   Both the 'active' and 'passive' field will be values of type
   SetKeyParticipantSet, which has the following syntax:


   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,
        ...}


   These values can be any of:

   o  A 'union' of other SetKeyParticipantSet values.  The sequence of
      SetKeyParticipantSet values MUST contain at least two members.



Herzog & Khazan           Expires April 7, 2013                 [Page 6]

Internet-Draft             A set-key attribute              October 2012


      The semantics of this sequence is as follows: a participant is in
      the union if and only if it is in 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 SetKeyParticipantSet 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 in 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, 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 MUST 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, groupID values used in set-key
      attributes MUST represent unchanging sets of participants.

   o  An 'explicit' list of SetMember values.  Order has no meaning in
      this sequence.  This sequence MUST NOT be empty.

   This structure may be expanded at a later date with additional types.

   A SetMember value, meant to identify a specific unique participant,
   has the following syntax:






Herzog & Khazan           Expires April 7, 2013                 [Page 7]

Internet-Draft             A set-key attribute              October 2012


   SetMember ::= CHOICE {
        issuerAndSerialNumber  [0] IssuerAndSerialNumber,
        publicKey              [1] SubjectPublicKeyInfo,
        participantID          [2] OCTET STRING,
        ...}


   A SetMember value can be any of:

   o  An IssuerAndSerialNumber value, defined in [RFC5911],

   o  A SubjectPublicKeyInfo, defined in [RFC5912], or

   o  A free form ('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 MUST refer to a single participant, and MUST 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 identified in multiple different ways.  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 free
   form 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 SubjectPublicKeyInfo form (value 'S').
   If these two distinct values are interpreted as identifying distinct
   keys, then the following 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.





Herzog & Khazan           Expires April 7, 2013                 [Page 8]

Internet-Draft             A set-key attribute              October 2012


   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.  We expand on this issue in
   Section 3.


3.  Attribute generation

   When creating a set-key attribute, the attribute generator (which
   will often also be the key source) begins with a set S of
   participants compromising the participant-set of the set-key.  (This
   set MUST include the key-source.)  The initial representation of this
   set or its members is beyond the scope of this document.  The
   generator may also inherit, from context or application, an
   environment in which some sets S1, S2, S3... have been assigned names
   N1, N2, N3...  Lastly, the attribute generator may know, from context
   or application, that some members of S will be passive users of the
   key.  (That is, they will use the key to process messages created by
   others but not to create messages of their own using that key.)

   First, the attribute generator must decide whether to use the
   optional passive field of the SetKeyInformation structure:

   o  If the generator knows that some members of S will be passive
      users, then it collects these members into a set P. The set P
      SHOULD only contain those participants in S which are known to be
      passive.

      The attribute generator then calculates the set A = S \ P (i.e.,
      members of S not in P).  The set A MUST NOT be empty.  (This would
      indicate, absurdly, that the key will never be used to apply
      cryptographic protection.)  The generator MUST ensure that the set
      A contains at least one member.  If the set A is computed to be
      empty, the generator MUST NOT generate the set-key attribute.

      The attibute generator will then create a representation of P,
      generated as described below, and emplace it in the passive field
      of the set-key attribute.  The generator then generates a
      representation of A as described below and stores this
      representation in the active field.





Herzog & Khazan           Expires April 7, 2013                 [Page 9]

Internet-Draft             A set-key attribute              October 2012


   o  Otherwise, the generator creates a representation of S as
      described below, stores it in the active field.  Also, the
      generator MUST omit the passive field.

   If the generator uses some other method to compute the sets to be
   represented in the active and passive fields, then:

   o  The generator SHOULD ensure that each element of S is contained
      either in the active field or the passive field, but not both.

   o  The generator MUST ensure that the set represented in the active
      field contains at least one member.

   o  If the generator uses the optional passive field, it MUST ensure
      that the value of that field represents a set containing at least
      one element.  That is, the passive field MUST either be omitted or
      contain a value representing a non-empty set.

   To emplace a set in either the active or passive fields of the set-
   key attribute, the attribute generator must construct a
   SetKeyParticipantSet value which represents that set.  In general,
   the 'best' representation of a set S' (which may be S, A or P) will
   depend on the higher-level application being executed by the
   attribute generator.  For example:

   o  Suppose that the set S' is small, or there is no mapping from
      names N1, N2, N3... to sets S1, S2, S3... available to the
      attribute generator.  In this case the generator can create an
      explicit list of the set members.  That is, the attribute
      generator represents each member of S' by a SetMember value as
      described above.  It then collects these SetMember values into a
      sequence of SetMember values, and emplaces that sequence into a
      SetKeyParticipantSet value (using the 'explicit' option).

   o  As another example, suppose that purpose of the set-key is to re-
      key a group which is changing over time.  If the current
      membership definition of this group has been given a name, then
      the attribute generator can simply emplace this name in a
      SetKeyParticipantValue (using the 'groupID' option).

   o  To elaborate on the previous example: Suppose that the membership-
      set of a group had been given a name at some point in the past,
      but the group's membership has changed since then.  Because the
      sets represented by SetKeyParticipantSet values represent
      unchanging sets, the name represents the prior membership-set, not
      the current one.  However, the name in question can be used to
      represent the current membership set in a way which may be more
      compact than the explicit list described in the first example



Herzog & Khazan           Expires April 7, 2013                [Page 10]

Internet-Draft             A set-key attribute              October 2012


      above.  Suppose that the group's prior membership-set was assigned
      the name N. Then the attribute generator can create two explicit
      lists of participants:

      *  In the first list, L1, the generator lists all participants
         which are currently in the group but were not in the group when
         it received the name N.

      *  In the second list, L2, the generator lists all participants
         which were in the group when it received the name N but are not
         in the group currently.

      In both cases, the attribute generator resolves each participant
      in the list to a SetMember value as described below, gathers all
      SetMember values into a sequence, and emplaces the sequence into a
      SetKeyParticipantSet value (using the 'explicit' option).  The
      attribute generator can then represent the current membership of
      the group by the value:


             setdiff { orig: (union (groupID: N) L1),
                       without: l2 }


      That is, it first emplaces the name N in a SetKeyParticipantSet
      value using the 'groupID' option.  It then creates a sequence
      compromised of this value and the SetKeyParticipantSet
      representing L1, and emplaces that in a SetKeyParticipantSet value
      (using the 'union' option).  It then creates a
      SetKeyParticipantSet value using the 'setdiff' option, where the
      previously-mentioned SetKeyParticipantSet value is in the 'orig'
      field and the SetKeyParticipantSet value representing L2 is in the
      'without' field.  In this way, the attribute-generator can
      represent the current membership-set of the group by describing
      the changes since it was given the name N, which may be a more
      compact representation than explicitly listing the entire current
      membership.

   Regardless of how the attribute generator chooses to represent the
   set:

   o  If a representation includes a Community value (the 'community'
      option) or an octet string (the 'groupID' option), then the
      attribute generator MUST know (through some method beyond the
      scope of this document) that this octet string unambiguously
      indicates the participant in question to every participant in the
      set key's participant-set.




Herzog & Khazan           Expires April 7, 2013                [Page 11]

Internet-Draft             A set-key attribute              October 2012


   o  If a representation requires that a participant be explicitly
      described by a SetMember value, then it SHOULD be represented by
      exactly one such value.  That is, the participant may be
      'mentioned' multiple times in the representation.  In this case,
      though, the same value should be used in each such instance.
      Specifically, the attribute-generator SHOULD select a SetMember
      representation for the participant in this order:

      1.  An IssuerAndSerialNumber value, if the participant possesses a
          certificate.  If more than one IssuerAndSerialNumber value is
          associated with that participant, the attribute generator MAY
          choose one using any criteria it likes.

      2.  A SubjectPublicKeyInfo value.  However, the attribute-
          generator MUST know (though some method beyond the scope of
          this document) that the associated private key is known to the
          participant and only that participant.

      3.  An octet string (the 'participantID' option).  However, the
          attribute generator MUST know (through some method beyond the
          scope of this document) that this octet string unambiguously
          indicates the participant in question to every participant in
          the set key's participant-set.

   o  Although the sets represented by the 'active' and 'passive' fields
      cannot be empty, sub-components of these values MAY be empty.
      This is because resource-constrained entities may wish to do the
      minimum 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.


4.  Attribute processing

   As with attribute generation, attribute processing will be heavily
   dependent on the intended application of the attribute and the set
   key.  However, we describe here two common cases: reconstruction of
   the described set, and testing set-membership.

   o  Suppose the attribute processor wishes to reconstruct the set
      represented in either the 'active' or 'passive' field.  The



Herzog & Khazan           Expires April 7, 2013                [Page 12]

Internet-Draft             A set-key attribute              October 2012


      processor's final, internal representation of this set is beyond
      the scope of this document.  However, one possible process for
      constructing this set mirrors the semantics of the attribute:

      *  If the SetKeyParticipantSet is of the 'union' option, then the
         processor recursively resolves each SetKeyParticipantSet value
         in the sequence into participant sets.  The final participant
         set is the union of each set in the sequence.

      *  If the SetKeyParticipantSet is of the 'intersection' option,
         then the processor recursively resolves each
         SetKeyParticipantSet value in the sequence into participant
         sets.  The final participant set is the intersection of these
         sets.

      *  If the SetKeyParticipantSet is of the 'setdiff' option, then
         the processor recursively resolves the SetKeyParticipantSet
         values of the 'orig' and 'without' fields into sets.  The final
         participant set contains exactly those participants in the
         'orig' set and not in the 'without' set.

      *  If the SetKeyParticipantSet is of the 'community' or 'groupID'
         option, then the attribute processor resolves the Community
         value or octet string, respectively, into a participant set.
         The methods by which the attribute-processor performs this
         operation are beyond the scope of this document.  However, if
         the identifier in question cannot unambiguously be resolved to
         a set of participants, then the attempt to reconstruct the set
         represented by this attribute MUST fail with an error.

      *  If the SetKeyParticipantSet is of the 'explicit' option, then
         the attribute processor resolves each SetMember value in the
         sequence into a participant.  The resulting participant set
         contains exactly those participants.  To resolve a SetMember
         value into a participant, the attribute processor might use the
         following process:

         +  If the SetMember value is of the 'issuerAndSerialNumber'
            option, then the participant is the entity indicated in the
            name field of the indicated certificate [RFC5280].

         +  If the SetMember value is of the 'publicKey' option, then
            the participant is the entity who knows the associated
            private key.  If the number of such entities is other than
            exactly one, then the attempt to reconstruct the set
            represented by this attribute MUST fail with an error.





Herzog & Khazan           Expires April 7, 2013                [Page 13]

Internet-Draft             A set-key attribute              October 2012


         +  If the SetMember value of the 'participantID' option, then
            the attribute processor resolves the octet string into a
            participant.  The method by which the attribute-processor
            performs this operation is beyond the scope of this
            document.  However, if the identifier in question cannot
            unambiguously be resolved to exactly one participant, then
            the attempt to reconstruct the set represented by this
            attribute MUST fail with an error.

         This process SHOULD return an error if either the 'active' or
         'passive' fields are resolved to empty sets.

   o  Suppose, on the other hand, the attribute processor wishes test
      whether a particular participant is a member of the indicated set.
      To do so, the processor must receive as input both the
      SetKeyParticipantSet value and the participant in question (the
      'target' participant).  The representation of this participant is
      beyond the scope of this document, so long as the attribute
      processor can match it against SetMember values (see below).

      To test set-membership of the target participant, the attribute
      processor can again follow a process which mirrors the underlying
      semantics of the attribute:

      *  If the SetKeyParticipantSet is of the 'union' option, then the
         processor iterates over the sequence.  For each
         SetKeyParticipantSet value in the sequence, the attribute
         processor recursively tests the membership of the target
         participant in the represented set.  This recursive test MAY
         return true, false, or an error.  If any recursive test returns
         true, then the current test (for this 'union' value) will also
         return true.  Furthermore, the attribute processor MAY
         immediately terminate iteration over the sequence upon
         receiving a 'true' value from a recursive test.  If the
         attribute processor finishes iterating over the sequence,
         however, and each recursive test returned 'false', then the
         current test returns 'false' as well.  If any recursive test
         returned 'error' and no recursive test returned 'true', then
         the current test also returns 'error'.

      *  If the SetKeyParticipantSet is of the 'intersection' option,
         then the processor iterates over the sequence.  For each
         SetKeyParticipantSet value in the sequence, the attribute
         processor recursively tests the membership of the target
         participant in the represented set.  This recursive test MAY
         return true, false, or an error.  If any recursive test returns
         false, then the current test (for this 'intersection' value)
         will also return false.  Furthermore, the attribute processor



Herzog & Khazan           Expires April 7, 2013                [Page 14]

Internet-Draft             A set-key attribute              October 2012


         MAY immediately terminate iteration over the sequence upon
         receiving a 'false' value from a recursive test.  If the
         attribute processor finishes iterating over the sequence,
         however, and each recursive test returned 'true', then the
         current test returns 'true' as well.  If any recursive test
         returned 'error' and no recursive test returned 'false', then
         the current test also returns 'error'.

      *  If the SetKeyParticipantSet is of the 'setdiff' option, then
         the processor recursively resolves the SetKeyParticipantSet
         values of the 'orig' and 'without' fields into sets.  It then
         recursively tests membership of the target participant in these
         two sets.  It returns 'true' if the test of the 'orig' set
         returns 'true' and the test for the 'without' set returns
         'false'.  If either test returned 'error', then the current
         test (for this 'setdiff' value) returns 'error' as well.  Else,
         the current test returns 'false'.

      *  If the SetKeyParticipantSet is of the 'community' or 'groupID'
         option, then the attribute processor resolves the Community
         value or octet string, respectively, into a participant set.
         It then returns success if participant is the set, and failure
         if not.  The methods by which the attribute-processor resolves
         the identifier into a set are beyond the scope of this
         document.  However, if the identifier in question cannot
         unambiguously be resolved to a set of participants, then the
         attempt to reconstruct the set represented by this attribute
         MUST fail with an error.

      *  If the SetKeyParticipantSet is of the 'explicit' option, then
         processor iterates over the sequence.  That is, the attribute
         processor attempts to match the target participant against each
         SetMember value in the sequence.  This matching can return
         true, false, or an error.  If any matching returns true, then
         the current test (for this 'explicit' value) will also return
         true.  Furthermore, the attribute processor MAY immediately
         terminate iteration over the sequence upon receiving a 'true'
         value from a matching.  If the attribute processor finishes
         iterating over the sequence, however, and each matching
         returned 'false', then the current test returns 'false' as
         well.  If any matching returned 'error' and no recursive test
         returned 'true', then the current test also returns 'error'.

      If the attribute processor further wishes to determine whether the
      target participant is active or passive, it recursively tests
      whether the target participant is in the set represented by the
      SetKeyParticipantSet value in the 'active' field of the attribute.
      If so, the target participant MUST be considered active.  If not,



Herzog & Khazan           Expires April 7, 2013                [Page 15]

Internet-Draft             A set-key attribute              October 2012


      the attribute processor tests whether the target participant is in
      the set represented by the SetKeyParticipantSet value in the
      'passive' field of the attribute.  If so, the participant MUST be
      considered passive.  If not, the target participant is not in the
      participant set of the key.

   If the attribute processor uses some other method to process the set-
   key attribute, then:

   o  An attribute processor MUST gracefully handle the case where a
      given participant is the set represented by the
      SetKeyParticipantSet value of the 'active' field and the value of
      the 'passive' field.  In this case, the participant in question
      MUST be considered to be active.

   o  The attribute processor MUST gracefully handle
      SetKeyParticipantSet values in which a given participant is
      represented by two different values.  Specifically, if the
      attribute processor ever fails to resolve a SetMember value
      unambiguously to a single participant, it MUST produce an error
      that it either handles itself or returns to a higher-level caller.
      Furthermore, the attribute processor MUST NOT use purely syntactic
      equality-tests for participants.  That is, attribute processors
      must internally represent participants in such a way that two
      different SetMember values will be recognized as representing the
      same participant (if, in fact, they do).

   o  If the SetKeyParticipantSet value of either the 'active' or
      'passive' field is resolved as representing an empty set, the
      attribute processor MUST consider this to be an invalid value and
      return an error.

   o  The attribute processor SHOULD gracefully handle values and types
      which they do not recognize (for sets and members).


5.  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.


6.  IANA Considerations

   This document makes use of object identifiers.  These object
   identifiers are defined in an arc delegated to the IETF S/MIME



Herzog & Khazan           Expires April 7, 2013                [Page 16]

Internet-Draft             A set-key attribute              October 2012


   Working Group.  This arc and its registration procedures will be
   transferred to IANA soon.  No further action by IANA is necessary for
   this document.  Future extensions may require action by IANA, but
   such actions will be described at the time of extension.


7.  Acknowledgments

   The authors would like to thank Jim Schaad, Russ Housley, Sean
   Turner, Carl Wallace, Menachem Dodge, and Alexey Melnikov for their
   helpful comments and suggestions.


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", Request For Comments 5280, May 2008.

   [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.

   [RFC6031]  Turner, S. and R. Housley, "Cryptographic Message Syntax
              (CMS) Symmetric Key Package Content Type", RFC 6031,
              December 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",



Herzog & Khazan           Expires April 7, 2013                [Page 17]

Internet-Draft             A set-key attribute              October 2012


              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.

8.2.  Informative References

   [RFC2627]  Wallner, D., Harder, E., and R. Agee, "Key Management for
              Multicast: Issues and Architectures", RFC 2627, June 1999.


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) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-setKeyAttributeV1(62) }

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



Herzog & Khazan           Expires April 7, 2013                [Page 18]

Internet-Draft             A set-key attribute              October 2012


     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-setKeyInformation }

id-aa-setKeyInformation     OBJECT IDENTIFIER ::= {
  iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
         smime(16) aa(2) 53 }

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,
     ...}

END


Appendix B.  ASN.1 structures for Attributes

   ATTRIBUTE values are defined in the ASN.1 module PKIX-CommonTypes-
   2009 of [RFC5912].  For information purposes, we reproduce the
   relevant portion of this module here:









Herzog & Khazan           Expires April 7, 2013                [Page 19]

Internet-Draft             A set-key attribute              October 2012


   ATTRIBUTE ::= CLASS {
       &id             OBJECT IDENTIFIER UNIQUE,
       &Type           OPTIONAL,
       &equality-match MATCHING-RULE OPTIONAL,
       &minCount       INTEGER DEFAULT 1,
       &maxCount       INTEGER OPTIONAL
   } WITH SYNTAX {
       [TYPE &Type]
       [EQUALITY MATCHING RULE &equality-match]
       [COUNTS [MIN &minCount] [MAX &maxCount]]
       IDENTIFIED BY &id
   }


   MATCHING-RULE ::= CLASS {
     &ParentMatchingRules   MATCHING-RULE OPTIONAL,
     &AssertionType         OPTIONAL,
     &uniqueMatchIndicator  ATTRIBUTE OPTIONAL,
     &id                    OBJECT IDENTIFIER UNIQUE
   }
   WITH SYNTAX {
     [PARENT &ParentMatchingRules]
     [SYNTAX &AssertionType]
     [UNIQUE-MATCH-INDICATOR &uniqueMatchIndicator]
     ID &id
   }


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 April 7, 2013                [Page 20]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/