idnits 2.17.1 draft-herzog-setkey-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6031]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 4, 2012) is 4219 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 851 -- Looks like a reference, but probably isn't: '1' on line 852 -- Looks like a reference, but probably isn't: '2' on line 853 -- Looks like a reference, but probably isn't: '3' on line 845 -- Looks like a reference, but probably isn't: '4' on line 846 -- Looks like a reference, but probably isn't: '5' on line 847 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Herzog 3 Internet-Draft R. Khazan 4 Intended status: Experimental MIT Lincoln Laboratory 5 Expires: April 7, 2013 October 4, 2012 7 A set-key attribute for symmetric-key packages 8 draft-herzog-setkey-07 10 Abstract 12 A set-key is a symmetric key (or set of keys) associated with an 13 immutable set of participants. This document defines a set-key 14 attribute for use in the CMS-based symmetric-key package structure 15 [RFC6031]. 17 Disclaimer 19 This work is sponsored by the United States Air Force under Air Force 20 Contract FA8721-05-C-0002. Opinions, interpretations, conclusions 21 and recommendations are those of the authors and are not necessarily 22 endorsed by the United States Government. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 7, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Set-keys . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Symmetric key packages . . . . . . . . . . . . . . . . . . 4 61 1.3. Intended Usage . . . . . . . . . . . . . . . . . . . . . . 5 62 1.4. Requirements Terminology . . . . . . . . . . . . . . . . . 5 63 2. The set-key attribute . . . . . . . . . . . . . . . . . . . . 5 64 3. Attribute generation . . . . . . . . . . . . . . . . . . . . . 9 65 4. Attribute processing . . . . . . . . . . . . . . . . . . . . . 12 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 72 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18 73 Appendix B. ASN.1 structures for Attributes . . . . . . . . . . . 19 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 76 1. Introduction 78 This document defines a new set-key attribute for use in the 79 symmetric-key package structure defined in [RFC6031]. 81 1.1. Set-keys 83 A 'set-key' is a symmetric key associated with (and to be limited to) 84 a specific set of participants (entities). The exact definition of 85 'participant', in the context of a particular key, will depend on the 86 key's intended application. Roughly speaking, however, the set of 87 participants corresponds to the collection of individual agents which 88 must possess and use the key for the key's intended purpose. In 89 practice, a 'participant' will often be an entity with a certified 90 public key, but other definitions of 'participant' are possible. 92 A set-key can be used in many ways, including: 94 o To secure broadcast or multicasts of e.g., pay-per-view movies, 96 o To secure group-communication such as chat rooms, or 98 o To secure data-at-rest which belongs to a group (such as on an 99 encrypted file-system or on a server). 101 The only requirement of a set-key is that it be associated with a 102 specific and unchanging set of participants. That is, this document 103 draws a distinction between sets and groups. 105 o Sets are immutable structures: a set S of participants is a 106 mathematical entity and does not change. 108 o A group, on the other hand, is a mutable structure that might have 109 a certain name or set of names; may be under the control of a 110 given administration; and may be mapped to a sequence of sets over 111 time according to the needs of some particular application. 113 This document considers only sets, and therefore will not consider 114 issues such as group-administration, adding or removing members, 115 revoking keys, and so on. Set-keys can be used to build group-keying 116 protocols, but such issues are outside the scope of this document. 118 By the 'participant-set' of a set-key, we mean the set of 119 participants associated with the set-key. We further note that the 120 participant-set of a set-key can be partitioned into two sub-sets: 121 the active participants and the passive participants. In some set- 122 key applications, such as group-chat, all participants may be active: 123 both sending and receiving. In other applications, such as multicast 124 of pay-per-view movies, most participants are passive: only 125 receiving. Because it may be important in some applications to know 126 which partipants are active and which are passive, we will allow 127 these two sub-sets to be explicitly distinguished from each other. 129 1.2. Symmetric key packages 131 The Cryptographic Message Syntax (CMS) [RFC5652] is a standard 132 notation and representation for cryptographic messages. CMS is based 133 on ASN.1 [X.680], [X.681], [X.682], [X.683] and uses that notation to 134 define a number of structures relevant to cryptography such as 135 certificates, encrypted or signed messages, and so on. 137 [RFC6031] uses CMS to define a structure for symmetric key packages: 138 collections of symmetric keys which share common properties and are 139 intended for the same participants. The syntax for this structure 140 follows: 142 SymmetricKeyPackage ::= SEQUENCE { 143 version KeyPkgVersion DEFAULT v1, 144 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute 145 {{ SKeyPkgAttributes }} OPTIONAL, 146 sKeys SymmetricKeys, 147 ... } 149 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 151 OneSymmetricKey ::= SEQUENCE { 152 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute 153 {{ SKeyAttributes }} OPTIONAL, 154 sKey OCTET STRING OPTIONAL } 155 ( WITH COMPONENTS { ..., sKeyAttrs PRESENT } | 156 WITH COMPONENTS { ..., sKey PRESENT } ) 158 KeyPkgVersion ::= INTEGER { v1(1) } ( v1, ... ) 160 SKeyPkgAttributes ATTRIBUTE ::= { ... } 162 SKeyAttributes ATTRIBUTE ::= { ... } 164 A key-package (SymmetricKeyPackage) contains some meta-information, 165 including attributes (sKeyPkgAttrs) [RFC6031], and a sequence of key- 166 structures. Each individual key-structure (OneSymmetricKey) contains 167 some attributes (sKeyAttrs) and some actual keying material (sKey). 168 Attributes in the sKeyPkgAttrs field apply to every key in the 169 package, while attributes in a sKeyAttrs field apply only to the key 170 in the containing OneSymmetricKey structure. The same attribute 171 cannot appear at both the package-level and the key-level. That is, 172 a given attribute can: 174 o appear in the sKeyPkgAttrs field but not in the sKeyAttrs field of 175 any OneSymmetricKey structure, 177 o appear in the sKeyAttrs field of one or more OneSymmetricKey 178 structures but not the sKeyPkgAttrs field, or 180 o not be included in the key-package at all. 182 Also, it is not required that every attribute be applicable at both 183 levels. That is, [RFC6031] allows a given attribute to be valid for 184 only the sKeyPkgAttrs field or for only the sKeyAttrs field. 186 The grammar for attributes is quite complex and given in [RFC5912]. 187 (We also reproduce the relevant portion in Appendix B.) We intend to 188 use only a small subset of this grammar, and therefore do not 189 consider the full definition of attributes in this document. 191 1.3. Intended Usage 193 The attribute defined in this document is meant to be embedded in a 194 SymmetricKeyPackage structure, perhaps with other attributes as well. 195 The resulting value will then hold a set-key in a common and standard 196 format. This format is appropriate both for transporting set-keys 197 and for holding set-keys computed from some higher-level protocol. 198 That is, one could create and distribute set-keys in this format 199 through some distribution protocol, or one could use this format to 200 hold set-keys computed by some protocol as Logical Key Hierarchy 201 [RFC2627]. 203 1.4. Requirements Terminology 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 2. The set-key attribute 211 The set-key attribute is used to associate a participant-set with a 212 symmetric key-package, where the participant-set MAY be divided into 213 the active and passive participants. It has the following syntax: 215 aa-setkey-information ATTRIBUTE ::= { 216 TYPE SetKeyInformation 217 IDENTIFIED BY id-aa-setKeyInformation } 219 id-aa-setKeyInformation OBJECT IDENTIFIER ::= { 220 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 221 smime(16) aa(2) 53 } 223 SetKeyInformation::= SEQUENCE { 224 active SetKeyParticipantSet, 225 passive SetKeyParticipantSet OPTIONAL } 227 This attribute MUST NOT appear in both the sKeyPkgAttrs field of a 228 SymmetricKeyPackage structure and the sKeyAttrs field of a 229 OneSymmetricKey structure. Furthermore, the sKeyPkgAttrs field of a 230 SymmetricKeyPackage MUST contain either zero or one instance of a 231 set-key attribute. 233 The 'active' and 'passive' fields jointly identify the participant- 234 set of this set-key. The 'active' field identifies the active 235 members of this set, meaning those which may use the key to protect 236 data or messages. The 'passive' field identifies the passive members 237 of this set, meaning those participants who are expected to have this 238 key but never use it to apply cryptographic protection to messages or 239 data. (They may use the key to process such protection, however, 240 such as to decrypt the data or verify its integrity.) 242 Both the 'active' and 'passive' field will be values of type 243 SetKeyParticipantSet, which has the following syntax: 245 SetKeyParticipantSet ::= CHOICE { 246 union [0] SEQUENCE SIZE (2..MAX) OF SetKeyParticipantSet, 247 intersection [1] SEQUENCE SIZE (2..MAX) OF SetKeyParticipantSet, 248 setdiff [2] SEQUENCE { 249 orig SetKeyParticipantSet, 250 without SetKeyParticipantSet }, 251 community [3] Community, 252 groupID [4] OCTET STRING, 253 explicit [5] SEQUENCE SIZE (1..MAX) OF SetMember, 254 ...} 256 These values can be any of: 258 o A 'union' of other SetKeyParticipantSet values. The sequence of 259 SetKeyParticipantSet values MUST contain at least two members. 261 The semantics of this sequence is as follows: a participant is in 262 the union if and only if it is in any of the SetKeyParticipantSet 263 values of the sequence. If any set in the sequence is non-empty, 264 then the union will be non-empty. If all sets in the union 265 sequence are empty, then the union is empty as well. 267 o The 'intersection' of other SetKeyParticipantSet values. The 268 sequence of SetKeyParticipantSet values MUST contain at least two 269 members.The semantics of this sequence is as follows: a 270 participant is in intersection if and only if it is in all of the 271 SetKeyParticipantSet values of the sequence. If any set in the 272 sequence is empty, the intersection is empty, too. If all sets in 273 the sequence are non-empty, the intersection might still be empty 274 (which it would be if there is no element common to all sets in 275 the sequence). 277 o The set-difference ('setdiff') of two other SetKeyParticipantSet 278 values. The semantics of this is as follows: a participant is in 279 the set-difference if and only if it is in the set identified in 280 the 'orig' field and not in the set identified by the 'without' 281 field. If the set identified in the 'orig' field is empty, then 282 the set-difference will be empty. If the set identified in the 283 'orig' field is a subset of the set identified in the 'without' 284 field, then the set-difference will be empty. If neither of the 285 two previous cases apply, the set-difference will be non-empty. 287 o A community, which is used by the Trust Anchor Management Protocol 288 (TAMP) [RFC5934] to identify a set of 'cryptographic modules.' 289 Community values used in set-key attributes MUST represent 290 unchanging sets of participants. 292 o A 'groupID', which is interpreted in an application-independent 293 way. One possible use for this option is to name pre-established 294 groups such as organizational departments or roles. The details 295 of establishing or using such a name-space are outside the scope 296 of this document. However, groupID values used in set-key 297 attributes MUST represent unchanging sets of participants. 299 o An 'explicit' list of SetMember values. Order has no meaning in 300 this sequence. This sequence MUST NOT be empty. 302 This structure may be expanded at a later date with additional types. 304 A SetMember value, meant to identify a specific unique participant, 305 has the following syntax: 307 SetMember ::= CHOICE { 308 issuerAndSerialNumber [0] IssuerAndSerialNumber, 309 publicKey [1] SubjectPublicKeyInfo, 310 participantID [2] OCTET STRING, 311 ...} 313 A SetMember value can be any of: 315 o An IssuerAndSerialNumber value, defined in [RFC5911], 317 o A SubjectPublicKeyInfo, defined in [RFC5912], or 319 o A free form ('participantID') octet-string, which is interpreted 320 in an application-dependent way. One possible use of this option 321 is to use pre-established names for participants. However, such 322 values MUST refer to a single participant, and MUST have a static 323 (unchanging) meaning. The details of establishing or using such a 324 name-space are outside the scope of this document. 326 As above, this structure may be expanded at a later date with 327 additional types. Implementations SHOULD gracefully handle values 328 and types which they do not recognize. 330 A single entity can be identified in multiple different ways. One 331 example of this is that a certified key can be identified using the 332 IssuerAndSerialNumber option, the SubjectPublicKeyInfo, or some 333 application specific method (for example, a common name) in the free 334 form field. This can cause ambiguity when evaluating a 335 SetKeyParticipantSet. Suppose that a given key is sometimes 336 identified using the IssuerAndSerialNumber form (value 'I') and 337 sometimes identified using the SubjectPublicKeyInfo form (value 'S'). 338 If these two distinct values are interpreted as identifying distinct 339 keys, then the following structures may be misinterpreted: 341 o The 'explicit' sequence ...I, S... may be interpreted as having 342 more elements than it actually does, due to the participant in 343 question being counted twice (one for the I value, one for the S 344 value). 346 o Similarly, the structure "union {...I...} {...S...}" may be 347 interpreted as containing one more participant than it actually 348 does. 350 o Likewise, the set "setdiff {...I...} {...S...}" may be interpreted 351 as being non-empty when it is empty. 353 o On the other hand, the set "intersection {...I...} {...S...}" may 354 be interpreted as being empty when it should not. (It will always 355 contain at least one element: the participant indicated by both I 356 and S.) 358 For these reasons, implementations SHOULD use a single method for 359 identification of a single individual or have a well-established 360 method of being able to compare the different locations that an 361 individual could be identified in. We expand on this issue in 362 Section 3. 364 3. Attribute generation 366 When creating a set-key attribute, the attribute generator (which 367 will often also be the key source) begins with a set S of 368 participants compromising the participant-set of the set-key. (This 369 set MUST include the key-source.) The initial representation of this 370 set or its members is beyond the scope of this document. The 371 generator may also inherit, from context or application, an 372 environment in which some sets S1, S2, S3... have been assigned names 373 N1, N2, N3... Lastly, the attribute generator may know, from context 374 or application, that some members of S will be passive users of the 375 key. (That is, they will use the key to process messages created by 376 others but not to create messages of their own using that key.) 378 First, the attribute generator must decide whether to use the 379 optional passive field of the SetKeyInformation structure: 381 o If the generator knows that some members of S will be passive 382 users, then it collects these members into a set P. The set P 383 SHOULD only contain those participants in S which are known to be 384 passive. 386 The attribute generator then calculates the set A = S \ P (i.e., 387 members of S not in P). The set A MUST NOT be empty. (This would 388 indicate, absurdly, that the key will never be used to apply 389 cryptographic protection.) The generator MUST ensure that the set 390 A contains at least one member. If the set A is computed to be 391 empty, the generator MUST NOT generate the set-key attribute. 393 The attibute generator will then create a representation of P, 394 generated as described below, and emplace it in the passive field 395 of the set-key attribute. The generator then generates a 396 representation of A as described below and stores this 397 representation in the active field. 399 o Otherwise, the generator creates a representation of S as 400 described below, stores it in the active field. Also, the 401 generator MUST omit the passive field. 403 If the generator uses some other method to compute the sets to be 404 represented in the active and passive fields, then: 406 o The generator SHOULD ensure that each element of S is contained 407 either in the active field or the passive field, but not both. 409 o The generator MUST ensure that the set represented in the active 410 field contains at least one member. 412 o If the generator uses the optional passive field, it MUST ensure 413 that the value of that field represents a set containing at least 414 one element. That is, the passive field MUST either be omitted or 415 contain a value representing a non-empty set. 417 To emplace a set in either the active or passive fields of the set- 418 key attribute, the attribute generator must construct a 419 SetKeyParticipantSet value which represents that set. In general, 420 the 'best' representation of a set S' (which may be S, A or P) will 421 depend on the higher-level application being executed by the 422 attribute generator. For example: 424 o Suppose that the set S' is small, or there is no mapping from 425 names N1, N2, N3... to sets S1, S2, S3... available to the 426 attribute generator. In this case the generator can create an 427 explicit list of the set members. That is, the attribute 428 generator represents each member of S' by a SetMember value as 429 described above. It then collects these SetMember values into a 430 sequence of SetMember values, and emplaces that sequence into a 431 SetKeyParticipantSet value (using the 'explicit' option). 433 o As another example, suppose that purpose of the set-key is to re- 434 key a group which is changing over time. If the current 435 membership definition of this group has been given a name, then 436 the attribute generator can simply emplace this name in a 437 SetKeyParticipantValue (using the 'groupID' option). 439 o To elaborate on the previous example: Suppose that the membership- 440 set of a group had been given a name at some point in the past, 441 but the group's membership has changed since then. Because the 442 sets represented by SetKeyParticipantSet values represent 443 unchanging sets, the name represents the prior membership-set, not 444 the current one. However, the name in question can be used to 445 represent the current membership set in a way which may be more 446 compact than the explicit list described in the first example 447 above. Suppose that the group's prior membership-set was assigned 448 the name N. Then the attribute generator can create two explicit 449 lists of participants: 451 * In the first list, L1, the generator lists all participants 452 which are currently in the group but were not in the group when 453 it received the name N. 455 * In the second list, L2, the generator lists all participants 456 which were in the group when it received the name N but are not 457 in the group currently. 459 In both cases, the attribute generator resolves each participant 460 in the list to a SetMember value as described below, gathers all 461 SetMember values into a sequence, and emplaces the sequence into a 462 SetKeyParticipantSet value (using the 'explicit' option). The 463 attribute generator can then represent the current membership of 464 the group by the value: 466 setdiff { orig: (union (groupID: N) L1), 467 without: l2 } 469 That is, it first emplaces the name N in a SetKeyParticipantSet 470 value using the 'groupID' option. It then creates a sequence 471 compromised of this value and the SetKeyParticipantSet 472 representing L1, and emplaces that in a SetKeyParticipantSet value 473 (using the 'union' option). It then creates a 474 SetKeyParticipantSet value using the 'setdiff' option, where the 475 previously-mentioned SetKeyParticipantSet value is in the 'orig' 476 field and the SetKeyParticipantSet value representing L2 is in the 477 'without' field. In this way, the attribute-generator can 478 represent the current membership-set of the group by describing 479 the changes since it was given the name N, which may be a more 480 compact representation than explicitly listing the entire current 481 membership. 483 Regardless of how the attribute generator chooses to represent the 484 set: 486 o If a representation includes a Community value (the 'community' 487 option) or an octet string (the 'groupID' option), then the 488 attribute generator MUST know (through some method beyond the 489 scope of this document) that this octet string unambiguously 490 indicates the participant in question to every participant in the 491 set key's participant-set. 493 o If a representation requires that a participant be explicitly 494 described by a SetMember value, then it SHOULD be represented by 495 exactly one such value. That is, the participant may be 496 'mentioned' multiple times in the representation. In this case, 497 though, the same value should be used in each such instance. 498 Specifically, the attribute-generator SHOULD select a SetMember 499 representation for the participant in this order: 501 1. An IssuerAndSerialNumber value, if the participant possesses a 502 certificate. If more than one IssuerAndSerialNumber value is 503 associated with that participant, the attribute generator MAY 504 choose one using any criteria it likes. 506 2. A SubjectPublicKeyInfo value. However, the attribute- 507 generator MUST know (though some method beyond the scope of 508 this document) that the associated private key is known to the 509 participant and only that participant. 511 3. An octet string (the 'participantID' option). However, the 512 attribute generator MUST know (through some method beyond the 513 scope of this document) that this octet string unambiguously 514 indicates the participant in question to every participant in 515 the set key's participant-set. 517 o Although the sets represented by the 'active' and 'passive' fields 518 cannot be empty, sub-components of these values MAY be empty. 519 This is because resource-constrained entities may wish to do the 520 minimum processing required to verify that the 'active' and 521 'passive' sets are non-empty. If the 'active' value is a 'union' 522 value at the top level, for example, the sender may wish to 523 terminate processing when it first finds a non-empty component of 524 that union (as opposed to confirming that every component 525 represents a non-empty set). Senders MAY invest the processing 526 necessary to ensure that no component of the 'active' and 527 'passive' sets represent non-empty sets, but receivers of these 528 values MUST properly handle the case that a sub-component 529 represents an empty set. 531 4. Attribute processing 533 As with attribute generation, attribute processing will be heavily 534 dependent on the intended application of the attribute and the set 535 key. However, we describe here two common cases: reconstruction of 536 the described set, and testing set-membership. 538 o Suppose the attribute processor wishes to reconstruct the set 539 represented in either the 'active' or 'passive' field. The 540 processor's final, internal representation of this set is beyond 541 the scope of this document. However, one possible process for 542 constructing this set mirrors the semantics of the attribute: 544 * If the SetKeyParticipantSet is of the 'union' option, then the 545 processor recursively resolves each SetKeyParticipantSet value 546 in the sequence into participant sets. The final participant 547 set is the union of each set in the sequence. 549 * If the SetKeyParticipantSet is of the 'intersection' option, 550 then the processor recursively resolves each 551 SetKeyParticipantSet value in the sequence into participant 552 sets. The final participant set is the intersection of these 553 sets. 555 * If the SetKeyParticipantSet is of the 'setdiff' option, then 556 the processor recursively resolves the SetKeyParticipantSet 557 values of the 'orig' and 'without' fields into sets. The final 558 participant set contains exactly those participants in the 559 'orig' set and not in the 'without' set. 561 * If the SetKeyParticipantSet is of the 'community' or 'groupID' 562 option, then the attribute processor resolves the Community 563 value or octet string, respectively, into a participant set. 564 The methods by which the attribute-processor performs this 565 operation are beyond the scope of this document. However, if 566 the identifier in question cannot unambiguously be resolved to 567 a set of participants, then the attempt to reconstruct the set 568 represented by this attribute MUST fail with an error. 570 * If the SetKeyParticipantSet is of the 'explicit' option, then 571 the attribute processor resolves each SetMember value in the 572 sequence into a participant. The resulting participant set 573 contains exactly those participants. To resolve a SetMember 574 value into a participant, the attribute processor might use the 575 following process: 577 + If the SetMember value is of the 'issuerAndSerialNumber' 578 option, then the participant is the entity indicated in the 579 name field of the indicated certificate [RFC5280]. 581 + If the SetMember value is of the 'publicKey' option, then 582 the participant is the entity who knows the associated 583 private key. If the number of such entities is other than 584 exactly one, then the attempt to reconstruct the set 585 represented by this attribute MUST fail with an error. 587 + If the SetMember value of the 'participantID' option, then 588 the attribute processor resolves the octet string into a 589 participant. The method by which the attribute-processor 590 performs this operation is beyond the scope of this 591 document. However, if the identifier in question cannot 592 unambiguously be resolved to exactly one participant, then 593 the attempt to reconstruct the set represented by this 594 attribute MUST fail with an error. 596 This process SHOULD return an error if either the 'active' or 597 'passive' fields are resolved to empty sets. 599 o Suppose, on the other hand, the attribute processor wishes test 600 whether a particular participant is a member of the indicated set. 601 To do so, the processor must receive as input both the 602 SetKeyParticipantSet value and the participant in question (the 603 'target' participant). The representation of this participant is 604 beyond the scope of this document, so long as the attribute 605 processor can match it against SetMember values (see below). 607 To test set-membership of the target participant, the attribute 608 processor can again follow a process which mirrors the underlying 609 semantics of the attribute: 611 * If the SetKeyParticipantSet is of the 'union' option, then the 612 processor iterates over the sequence. For each 613 SetKeyParticipantSet value in the sequence, the attribute 614 processor recursively tests the membership of the target 615 participant in the represented set. This recursive test MAY 616 return true, false, or an error. If any recursive test returns 617 true, then the current test (for this 'union' value) will also 618 return true. Furthermore, the attribute processor MAY 619 immediately terminate iteration over the sequence upon 620 receiving a 'true' value from a recursive test. If the 621 attribute processor finishes iterating over the sequence, 622 however, and each recursive test returned 'false', then the 623 current test returns 'false' as well. If any recursive test 624 returned 'error' and no recursive test returned 'true', then 625 the current test also returns 'error'. 627 * If the SetKeyParticipantSet is of the 'intersection' option, 628 then the processor iterates over the sequence. For each 629 SetKeyParticipantSet value in the sequence, the attribute 630 processor recursively tests the membership of the target 631 participant in the represented set. This recursive test MAY 632 return true, false, or an error. If any recursive test returns 633 false, then the current test (for this 'intersection' value) 634 will also return false. Furthermore, the attribute processor 635 MAY immediately terminate iteration over the sequence upon 636 receiving a 'false' value from a recursive test. If the 637 attribute processor finishes iterating over the sequence, 638 however, and each recursive test returned 'true', then the 639 current test returns 'true' as well. If any recursive test 640 returned 'error' and no recursive test returned 'false', then 641 the current test also returns 'error'. 643 * If the SetKeyParticipantSet is of the 'setdiff' option, then 644 the processor recursively resolves the SetKeyParticipantSet 645 values of the 'orig' and 'without' fields into sets. It then 646 recursively tests membership of the target participant in these 647 two sets. It returns 'true' if the test of the 'orig' set 648 returns 'true' and the test for the 'without' set returns 649 'false'. If either test returned 'error', then the current 650 test (for this 'setdiff' value) returns 'error' as well. Else, 651 the current test returns 'false'. 653 * If the SetKeyParticipantSet is of the 'community' or 'groupID' 654 option, then the attribute processor resolves the Community 655 value or octet string, respectively, into a participant set. 656 It then returns success if participant is the set, and failure 657 if not. The methods by which the attribute-processor resolves 658 the identifier into a set are beyond the scope of this 659 document. However, if the identifier in question cannot 660 unambiguously be resolved to a set of participants, then the 661 attempt to reconstruct the set represented by this attribute 662 MUST fail with an error. 664 * If the SetKeyParticipantSet is of the 'explicit' option, then 665 processor iterates over the sequence. That is, the attribute 666 processor attempts to match the target participant against each 667 SetMember value in the sequence. This matching can return 668 true, false, or an error. If any matching returns true, then 669 the current test (for this 'explicit' value) will also return 670 true. Furthermore, the attribute processor MAY immediately 671 terminate iteration over the sequence upon receiving a 'true' 672 value from a matching. If the attribute processor finishes 673 iterating over the sequence, however, and each matching 674 returned 'false', then the current test returns 'false' as 675 well. If any matching returned 'error' and no recursive test 676 returned 'true', then the current test also returns 'error'. 678 If the attribute processor further wishes to determine whether the 679 target participant is active or passive, it recursively tests 680 whether the target participant is in the set represented by the 681 SetKeyParticipantSet value in the 'active' field of the attribute. 682 If so, the target participant MUST be considered active. If not, 683 the attribute processor tests whether the target participant is in 684 the set represented by the SetKeyParticipantSet value in the 685 'passive' field of the attribute. If so, the participant MUST be 686 considered passive. If not, the target participant is not in the 687 participant set of the key. 689 If the attribute processor uses some other method to process the set- 690 key attribute, then: 692 o An attribute processor MUST gracefully handle the case where a 693 given participant is the set represented by the 694 SetKeyParticipantSet value of the 'active' field and the value of 695 the 'passive' field. In this case, the participant in question 696 MUST be considered to be active. 698 o The attribute processor MUST gracefully handle 699 SetKeyParticipantSet values in which a given participant is 700 represented by two different values. Specifically, if the 701 attribute processor ever fails to resolve a SetMember value 702 unambiguously to a single participant, it MUST produce an error 703 that it either handles itself or returns to a higher-level caller. 704 Furthermore, the attribute processor MUST NOT use purely syntactic 705 equality-tests for participants. That is, attribute processors 706 must internally represent participants in such a way that two 707 different SetMember values will be recognized as representing the 708 same participant (if, in fact, they do). 710 o If the SetKeyParticipantSet value of either the 'active' or 711 'passive' field is resolved as representing an empty set, the 712 attribute processor MUST consider this to be an invalid value and 713 return an error. 715 o The attribute processor SHOULD gracefully handle values and types 716 which they do not recognize (for sets and members). 718 5. Security Considerations 720 As with the entire symmetric-key package, the set-key attribute is 721 not protected. The symmetric key package content type can be 722 combined with a security protocol to protect the contents of the 723 attribute. 725 6. IANA Considerations 727 This document makes use of object identifiers. These object 728 identifiers are defined in an arc delegated to the IETF S/MIME 729 Working Group. This arc and its registration procedures will be 730 transferred to IANA soon. No further action by IANA is necessary for 731 this document. Future extensions may require action by IANA, but 732 such actions will be described at the time of extension. 734 7. Acknowledgments 736 The authors would like to thank Jim Schaad, Russ Housley, Sean 737 Turner, Carl Wallace, Menachem Dodge, and Alexey Melnikov for their 738 helpful comments and suggestions. 740 8. References 742 8.1. Normative References 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", RFC 2119, March 1997. 747 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 748 Housley, R., and W. Polk, "Internet X.509 Public Key 749 Infrastructure Certificate and Certificate Revocation List 750 (CRL) Profile", Request For Comments 5280, May 2008. 752 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 753 RFC 5652, September 2009. 755 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 756 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 757 June 2010. 759 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 760 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 761 June 2010. 763 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 764 Management Protocol (TAMP)", RFC 5934, August 2010. 766 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 767 (CMS) Symmetric Key Package Content Type", RFC 6031, 768 December 2010. 770 [X.680] ITU-T, "Information Technology - Abstract Syntax Notation 771 One", Recommendation X.680, ISO/IEC 8824-1:2002, 2002. 773 [X.681] ITU-T, "Information Technology - Abstract Syntax Notation 774 One: Information Object Specification", 775 Recommendation X.681, ISO/IEC 8824-2:2002, 2002. 777 [X.682] ITU-T, "Information Technology - Abstract Syntax Notation 778 One: Constraint Specification", Recommendation X.682, ISO/ 779 IEC 8824-3:2002, 2002. 781 [X.683] ITU-T, "Information Technology - Abstract Syntax Notation 782 One: Parameterization of ASN.1 Specifications", 783 Recommendation X.683, ISO/IEC 8824-4:2002, 2002. 785 8.2. Informative References 787 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 788 Multicast: Issues and Architectures", RFC 2627, June 1999. 790 Appendix A. ASN.1 Module 792 This appendix provides the normative ASN.1 definitions for the 793 structures described in this specification using ASN.1 as defined in 794 [X.680] through [X.683]. 796 SetKeyAttributeV1 797 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 798 mechanisms(5) pkix(7) id-mod(0) id-mod-setKeyAttributeV1(62) } 800 DEFINITIONS IMPLICIT TAGS ::= 802 BEGIN 804 -- EXPORTS ALL 806 IMPORTS 808 ATTRIBUTE 809 FROM PKIX-CommonTypes-2009 810 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 811 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 812 IssuerAndSerialNumber 813 FROM CryptographicMessageSyntax-2009 814 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 815 smime(16) modules(0) id-mod-cms-2004-02(41)} 816 SubjectPublicKeyInfo 817 FROM PKIX1Explicit-2009 818 { iso(1) identified-organization(3) dod(6) internet(1) 819 security(5) mechanisms(5) pkix(7) id-mod(0) 820 id-mod-pkix1-explicit-02(51) } 821 Community 822 FROM TAMP-Protocol-v2 823 { joint-iso-ccitt(2) country(16) us(840) organization(1) 824 gov(101) dod(2) infosec(1) modules(0) 30 } 825 ; 827 aa-setkey-information ATTRIBUTE ::= { 828 TYPE SetKeyInformation 829 IDENTIFIED BY id-aa-setKeyInformation } 831 id-aa-setKeyInformation OBJECT IDENTIFIER ::= { 832 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 833 smime(16) aa(2) 53 } 835 SetKeyInformation::= SEQUENCE { 836 active SetKeyParticipantSet, 837 passive SetKeyParticipantSet OPTIONAL } 839 SetKeyParticipantSet ::= CHOICE { 840 union [0] SEQUENCE SIZE (2..MAX) OF SetKeyParticipantSet, 841 intersection [1] SEQUENCE SIZE (2..MAX) OF SetKeyParticipantSet, 842 setdiff [2] SEQUENCE { 843 orig SetKeyParticipantSet, 844 without SetKeyParticipantSet }, 845 community [3] Community, 846 groupID [4] OCTET STRING, 847 explicit [5] SEQUENCE SIZE (1..MAX) OF SetMember, 848 ...} 850 SetMember ::= CHOICE { 851 issuerAndSerialNumber [0] IssuerAndSerialNumber, 852 publicKey [1] SubjectPublicKeyInfo, 853 participantID [2] OCTET STRING, 854 ...} 856 END 858 Appendix B. ASN.1 structures for Attributes 860 ATTRIBUTE values are defined in the ASN.1 module PKIX-CommonTypes- 861 2009 of [RFC5912]. For information purposes, we reproduce the 862 relevant portion of this module here: 864 ATTRIBUTE ::= CLASS { 865 &id OBJECT IDENTIFIER UNIQUE, 866 &Type OPTIONAL, 867 &equality-match MATCHING-RULE OPTIONAL, 868 &minCount INTEGER DEFAULT 1, 869 &maxCount INTEGER OPTIONAL 870 } WITH SYNTAX { 871 [TYPE &Type] 872 [EQUALITY MATCHING RULE &equality-match] 873 [COUNTS [MIN &minCount] [MAX &maxCount]] 874 IDENTIFIED BY &id 875 } 877 MATCHING-RULE ::= CLASS { 878 &ParentMatchingRules MATCHING-RULE OPTIONAL, 879 &AssertionType OPTIONAL, 880 &uniqueMatchIndicator ATTRIBUTE OPTIONAL, 881 &id OBJECT IDENTIFIER UNIQUE 882 } 883 WITH SYNTAX { 884 [PARENT &ParentMatchingRules] 885 [SYNTAX &AssertionType] 886 [UNIQUE-MATCH-INDICATOR &uniqueMatchIndicator] 887 ID &id 888 } 890 Authors' Addresses 892 Jonathan C. Herzog 893 MIT Lincoln Laboratory 894 244 Wood St. 895 Lexington, MA 02144 896 USA 898 Email: jherzog@ll.mit.edu 900 Roger Khazan 901 MIT Lincoln Laboratory 902 244 Wood St. 903 Lexington, MA 02144 904 USA 906 Email: rkh@ll.mit.edu