Re: New ID of potential interest
"Herzog, Jonathan - 0668 - MITLL" <[email protected]>
| Newsgroups | gmane.ietf.smime |
|---|---|
| Message-ID | <[email protected]> |
On Aug 12, 2010, at 12:27 PM, Herzog, Jonathan - 0668 - MITLL wrote: > > > While you chew on this, I'll go ahead and make the changes described above and send the new version to you. New version attached. Thanks. -- Jonathan Herzog voice: (781) 981-2356 Technical Staff fax: (781) 981-7687 Cyber Systems and Technology Group email: [email protected] MIT Lincoln Laboratory www: http://www.ll.mit.edu/CST/ 244 Wood Street Lexington, MA 02420-9185 _______________________________________________ smime mailing list [email protected] https://www.ietf.org/mailman/listinfo/smime
draft-herzog-setkey.txt
(text/plain, 23.5 KB)
Network Working Group J. Herzog
Internet-Draft R. Khazan
Intended status: Informational MIT Lincoln Laboratory
Expires: February 13, 2011 August 12, 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 February 13, 2011.
Herzog & Khazan Expires February 13, 2011 [Page 1]
Internet-Draft A set-key attribute August 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Normative References . . . . . . . . . . . . . . . . . . . 9
4.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Herzog & Khazan Expires February 13, 2011 [Page 2]
Internet-Draft A set-key attribute August 2010
1. Introduction
This document defines a new set-key attribute for 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 February 13, 2011 [Page 3]
Internet-Draft A set-key attribute August 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, ... )
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.
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.
Herzog & Khazan Expires February 13, 2011 [Page 4]
Internet-Draft A set-key attribute August 2010
The grammar for attributes is quite complex and given in
[Housley-symmkey]. We intend to use only a small subset of this
grammar, however, 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 February 13, 2011 [Page 5]
Internet-Draft A set-key attribute August 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 {
version SetKeyAttrVersion DEFAULT v1,
active SetKeyParticipantSet,
passive SetKeyParticipantSet OPTIONAL }
SetKeyAttrVersion ::= INTEGER { v1(1) } ( v1, ... )
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 SetKeyInformation fields are used as follows:
o The 'version' value identifies version of the set-key
attributestructure. For this version of the specification, the
default value, v1, MUST be used. Implementations MUST gracefully
handle unfamiliar (future) versions as if the entire attribute was
unfamiliar.
o 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 send
messages secured by the set-key. The 'passive' field identifies
the passive members of this set, meaning those participants who
Herzog & Khazan Expires February 13, 2011 [Page 6]
Internet-Draft A set-key attribute August 2010
are expected to never send a message secured by this key. (The
internal structures of these sets are described below.) Any
member which could possibly send messages under 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.
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 semanitics 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 too.
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 byt the Trust Anchor Management
Protocol (TAMP) [Housley-TAMP] to identify a set of 'cryptographic
modules.'
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.
Herzog & Khazan Expires February 13, 2011 [Page 7]
Internet-Draft A set-key attribute August 2010
o An 'explicit' list of SetMember values. In this sequence, order
is not given any meaning. This sequence MAY NOT be empty.
If a SetKeyParticipantSet is not defined in terms of a community or
groupID (that is, these options do not appear in the parse-tree of
the SetKeyParticipantSet) then the set is static and unchanging. In
this case, the attribute-creator SHOULD process the
SetKeyParticipantSet to ensure that the resulting set is non-empty.
The set of active participants SHOULD NOT be empty. If the set of
passive participants is empty, then it SHOULD be omitted. If a
SetKeyParticipantSet is defined in terms of a community or groupID,
these may refer to participant-sets that evolve over time. Thus, it
may not be possible to determine if the described set will be empty
for all points in the future. The attribute creator MAY pre-process
the SetKeyParticipantSet to ensure the set is non-empty, but MUST NOT
conclude the set to be empty unless that conclusion results from the
set-theoretic semantics described above and independently of any
specific interpretation of community-identifiers or groupID values.
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. The details of
establishing or using such a name-space are outside the scope of
this document.
This list allows a certified key to be identified in two different
ways: using the IssuerAndSerialNumber option, or the
SubjectPublicKeyInfo option. This can cause ambiguity when parsing a
SetKeyParticipantSet structure. 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 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 containgin one more participant than it actually
does.
Herzog & Khazan Expires February 13, 2011 [Page 8]
Internet-Draft A set-key attribute August 2010
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 that wish to name a certified key
SHOULD use the IssuerAndSerialNumber form rather than the
SubjectPublicKeyInfo form. However, implementations that receive and
process a SetKey attribute SHOULD NOT regard different names as
always indicating different participants. 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. References
4.1. Normative References
[Housley-TAMP]
Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Management Protocol (TAMP)", Internet
Draft draft-ietf-pkix-tamp-08.txt, April 2010.
[Housley-symmkey]
Turner, S. and R. Housley, "Symmetric Key Package Content
Type", Internet
Draft draft-ietf-keyprov-symmetrickeyformat-10.txt,
August 2010.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", Request
For Comments 5652, September 2009.
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", Request
For Comments 5911, June 2010.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", Request For
Herzog & Khazan Expires February 13, 2011 [Page 9]
Internet-Draft A set-key attribute August 2010
Comments 5912, June 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.
4.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) 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)
Herzog & Khazan Expires February 13, 2011 [Page 10]
Internet-Draft A set-key attribute August 2010
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 {
version SetKeyAttrVersion DEFAULT v1,
active SetKeyParticipantSet,
passive SetKeyParticipantSet OPTIONAL }
SetKeyAttrVersion ::= INTEGER { v1(1) } ( v1, ... )
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
Herzog & Khazan Expires February 13, 2011 [Page 11]
Internet-Draft A set-key attribute August 2010
Authors' Addresses
Jonathan C. Herzog
MIT Lincoln Laboratory
244 Wood St.
Lexington, MA 02144
USA
Email: [email protected]
Roger Khazan
MIT Lincoln Laboratory
244 Wood St.
Lexington, MA 02144
USA
Email: [email protected]
Herzog & Khazan Expires February 13, 2011 [Page 12]
smime.p7s
(application/pkcs7-signature, 3.2 KB) - not displayed