Internet DRAFT - draft-herzog-setkey
draft-herzog-setkey
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]
