idnits 2.17.1 draft-schaad-plasma-cms-05.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 ([I-D.freeman-plasma-requirements], [I-D.schaad-plasma-service]), 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 == Line 278 has weird spacing: '...version is se...' == Line 280 has weird spacing: '... kekid is a ...' == Line 282 has weird spacing: '...ntifier conta...' == Line 284 has weird spacing: '... date is no...' == Line 286 has weird spacing: '... other is no...' == (40 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 12, 2014) is 3727 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1363 -- Looks like a reference, but probably isn't: '1' on line 1364 == Missing Reference: 'CMS-ASN' is mentioned on line 1415, but not defined == Missing Reference: 'RFC5652' is mentioned on line 1281, but not defined == Missing Reference: 'RFC5912' is mentioned on line 1289, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5911 ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) == Outdated reference: A later version (-11) exists of draft-freeman-plasma-requirements-08 ** Downref: Normative reference to an Informational draft: draft-freeman-plasma-requirements (ref. 'I-D.freeman-plasma-requirements') -- Obsolete informational reference (is this intentional?): RFC 3369 (Obsoleted by RFC 3852) -- Obsolete informational reference (is this intentional?): RFC 2630 (Obsoleted by RFC 3369, RFC 3370) == Outdated reference: A later version (-05) exists of draft-schaad-plasma-service-04 == Outdated reference: A later version (-02) exists of draft-housley-smime-oids-00 Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Intended status: Standards Track February 12, 2014 5 Expires: August 16, 2014 7 Plasma Service Cryptographic Message Syntax (CMS) Processing 8 draft-schaad-plasma-cms-05 10 Abstract 12 Secure MIME (S/MIME) defined a method of placing security labels on a 13 Cryptographic Message Syntax (CMS) object. These labels are placed 14 as part of the data signed and validated by the parties. This means 15 that the message content is visible to the recipient prior to the 16 label enforcement. A new model for enforcement of policy using a 17 third party is described in RFC TBD 18 [I-D.freeman-plasma-requirements]. This is the Policy Augmented S/ 19 MIME (PLASMA) system. This document provides the details needed to 20 implement the new Plasma model in the CMS infrastructure. 22 An additional benefit of using the Plasma module is that the server, 23 based on policy, manages who has access to the message and how the 24 keys are protected. 26 The document details how the client encryption and decryption 27 processes are performed, defines how to construct the CMS recipient 28 info structure, a new content to hold the data required for the 29 Plasma server to store the keys and policy information. The document 30 does not cover the protocol between the client and the Plasma policy 31 enforcement server. One example of the client/server protocol can be 32 found in RFC TBD [I-D.schaad-plasma-service]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 16, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 4 70 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Recipient Info Encoding . . . . . . . . . . . . . . . . . . . 5 72 3.1. PLASMA Encrypted Key . . . . . . . . . . . . . . . . . . 7 73 3.2. PLASMA Content Type . . . . . . . . . . . . . . . . . . . 9 74 3.3. CMS Signed Data signed attributes . . . . . . . . . . . . 14 75 3.3.1. PLASMA URL Authenticated Attribute . . . . . . . . . 14 76 3.3.2. PLASMA Encrypted Content Hash Attribute . . . . . . . 16 77 3.4. Plasma Lockbox Attributes . . . . . . . . . . . . . . . . 17 78 3.4.1. Audit Trail Identifier Attribute . . . . . . . . . . 17 79 3.4.2. Signer Info Attribute . . . . . . . . . . . . . . . . 18 80 3.4.3. XACML Generic Attribute . . . . . . . . . . . . . . . 19 81 4. Sender Processing Rules . . . . . . . . . . . . . . . . . . . 20 82 4.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 5. Recipient Processing Rules . . . . . . . . . . . . . . . . . 21 84 5.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 5.2. Reply Processing . . . . . . . . . . . . . . . . . . . . 23 86 6. S/MIME Capability . . . . . . . . . . . . . . . . . . . . . . 23 87 7. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . 24 88 7.1. Plasma Servers . . . . . . . . . . . . . . . . . . . . . 24 89 7.2. Plasma Clients . . . . . . . . . . . . . . . . . . . . . 24 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 94 10.2. Informative References . . . . . . . . . . . . . . . . . 27 95 Appendix A. 2009 ASN.1 Module . . . . . . . . . . . . . . . . . 28 96 Appendix B. Policy Encoding Techniques . . . . . . . . . . . . . 32 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 99 1. Introduction 101 In the traditional S/MIME (Secure MIME) e-mail system, the sender of 102 a message is responsible for determining the list of recipients for a 103 message, obtaining a valid public or group key for each recipient, 104 applying a security label to a message, and sending the message. The 105 recipient of a message is responsible for the enforcement of any 106 security labels on the message. While this system works in theory, 107 in practice it has some difficulties that have led to problems in 108 getting S/MIME mail widely deployed. This document is part of an 109 effort to provide an alternative method of allocating the 110 responsibilities above to different entities in an attempt to make 111 the process work better. 113 In a Policy Augmented S/MIME (PLASMA) deployment of S/MIME, the 114 sender of the message is still responsible for determining the list 115 of recipients for the message and determining the security label to 116 be applied to the message; however the Plasma server is now 117 responsible for obtaining valid keys for recipients and checking the 118 policy access for the recipients. The recipient is no longer 119 responsible for enforcement of the policy as this is off-loaded to 120 the Plasma server component. Doing this allows for the following 121 changes in behavior of the system: 123 o The sender is no longer responsible for finding and validating the 124 set of public keys used for the message. This simplifies the 125 complexity of the sender and lowers the resources required by the 126 sender. This is especially true when a large number of recipients 127 are involved. 129 o The set of recipients that can decrypt the message can be change 130 dynamically after the message is sent, without resorting to a 131 group keying strategy. 133 o The enforcement of the policy is done centrally, this means that 134 updates to the policy are instantaneous and the enforcement policy 135 can be centrally audited. 137 o The label enforcement is done before the message is decrypted; 138 this means there are no concerns about the message contents being 139 leaked by poor client implementations. 141 o Many of the same components used in a web-based deployment of 142 policy enforcement in a confederation can be used for e-mail based 143 deployment of information. This includes using credentials other 144 than X.509 certificates. 146 While this document describes the processes in terms of dealing with 147 email system, a Plasma server can be used with any number of clients 148 that need to protected content. Thus the same system could be used 149 for protection of documents without having to specify in advance the 150 individuals who should be able to open the document; it would just be 151 allowed by the server based on the policy applied to the document. 153 This document is laid out as follows: 155 o In Section 2 a more complete description of the components 156 involved in the model are discussed. 158 o In Section 3 is description the new ASN.1 structures that are used 159 to carry the additional information, and the way that these 160 structures are used in a recipient info structure. 162 o In Section 4 is a description of the modifications from the sender 163 processing rules outlined in [RFC5751]. 165 o In Section 5 is a description of the modification from the 166 recipient processing rules outlined in [RFC5751]. 168 1.1. Vocabulary 170 Some of the terms used in this document include: 172 Authenticated Encryption with Additional Data (AEAD): Are a set of 173 encryption algorithms where an authentication method stronger than 174 the PKCS #1 packing method is used for authentication and, 175 optionally, a set of unencrypted attribute values are included in 176 the authentication step. 178 Content Encryption Key (CEK): The symmetric key used to encryption 179 the content of a message. 181 Key Encryption Key (KEK): A key, usually a symmetric key, which is 182 used to encrypt another key, usually a content encryption key. 184 1.2. Requirements Terminology 186 When capitalized, the key words "MUST", "MUST NOT", "REQUIRED", 187 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 188 and "OPTIONAL" in this document are to be interpreted as described in 189 [RFC2119]. 191 2. Model 193 Details on the model and the requirements for the Plasma system can 194 be found in [I-D.freeman-plasma-requirements]. 196 3. Recipient Info Encoding 198 In order for the Plasma system to function in CMS, a method needs to 199 be chosen and described for how the CEK is to be protected and 200 carried with the message, such that the recipient will be able to 201 identified that this is a Plasma enabled message, know which Plasma 202 server to contact and be able to get back the CEK needed to decrypt 203 the message. Not all recipients of a message that has been encrypted 204 using a Plasma server will need to contact the server in order to 205 decrypt the message. There is nothing in what we are doing that 206 prevents a message sender from building recipient info structures in 207 a normal manner, except the possibly that the policy applied to the 208 encrypted content could restrict it from happening. Additionally the 209 Plasma server could return the standard recipient info structures to 210 be added to the message for recipients, if it can pre-authorize them 211 for access to the message and it can obtain the appropriate keying 212 material. 214 There are two distinct methods that were considered for identifying a 215 recipient info structure as being a Plasma enabled object. The first 216 would be to define a new recipient info structure placed in the Other 217 Recipient Info structure. The second option is to force the new 218 recipient info structure into one of the existing strucutres. 220 The use of a new recipient info structure would have been the easiest 221 to document and implement, if most major CMS implementations had kept 222 up with the latest versions. However it is known that several 223 implementations stopped with RFC 2630 [RFC2630] and it was not until 224 RFC 3369 [RFC3369] that the Other Recipient Info choice was 225 introduced along with the language stating that implementations need 226 to gracefully handle unimplemented alternatives in the recipient info 227 choice. This means that if a new recipient info structure was 228 defined and adopted, the mail message would fail decoding for many 229 recipients, even for those recipients that had a key transfer or key 230 agreement recipient info structure. 232 Given the current state of implementations, it was determined that 233 the second method would be used as it will work with more 234 implementations. After implementation it might be found that using 235 the first method is the better way to go, in that case the decision 236 can be re-visited. 238 The use of the KEKRecipientInfo type may seem to be a stretch at 239 first, it was defined for those situations where a symmetric key had 240 already been distributed and either a specific key or a specific 241 transformation on the key was to be applied in order to decrypt the 242 KEK value. However, the Plasma recipient info can be thought of as a 243 strange way to do the transformation and thus it kind of fits into 244 the model. It is in a structure that will be supported by the most 245 basic CMS implementiation and it is easy for client implementations 246 to make the determination of a Plasma recipient info by looking at 247 the OID in the key encryption algorithm identifier. 249 A recipient info structure as defined in this document MUST be 250 created by a Plasma server and MUST NOT be created by client 251 software. A protocol such as the one in RFC TBD1 252 [I-D.schaad-plasma-service] is used to transport the recipient info 253 structure between the client and the server. 255 For the convenience of the reader we include the KEKRecipientInfo 256 structure pieces here (copied from [RFC5911]): 258 KEKRecipientInfo ::= SEQUENCE { 259 version CMSVersion, -- always set to 4 260 kekid KEKIdentifier, 261 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 262 encryptedKey EncryptedKey } 264 KEKIdentifier ::= SEQUENCE { 265 keyIdentifier OCTET STRING, 266 date GeneralizedTime OPTIONAL, 267 other OtherKeyAttribute OPTIONAL } 269 OtherKeyAttribute ::= SEQUENCE { 270 keyAttrId KEY-ATTRIBUTE. 271 &id({SupportedKeyAttributes}), 272 keyAttr KEY-ATTRIBUTE. 273 &Type({SupportedKeyAttributes}{@keyAttrId})} 275 For a Plasma KEKRecipientInfo structure, the fields are filled in as 276 follows: 278 version is set to the value of 4. 280 kekid is a sequence where the fields are: 282 keyIdentifier contains the constant string "Plasma". 284 date is not used and is omitted. 286 other is not used and is omitted. 288 keyEncryptionAlgorithm contains the value id-kek-plasma-token. The 289 parameter field MUST be omitted. 291 encryptedKey contains the Plasma Encrypted Key object. The details 292 of this are covered in Section 3.1 294 3.1. PLASMA Encrypted Key 296 We defined a new Key Wrapping algorithm which uses the Plasma server 297 to wrap the CEK in an encrypted lock box. In addition to the KEK, 298 the lock box also contains the information that is needed by the 299 Plasma Server to know the policy(s) applied to the encrypted data and 300 possible parameters for the policy and for the client to validate 301 that the lock box applies to the encrypted content. 303 The relevant section from the ASN.1 module which contains the content 304 is: 306 -- 307 -- New key wrap algorithm object for Plasma 308 -- 310 kwa-plasma-lockbox KEY-WRAP ::= { 311 IDENTIFIER id-alg-plasma-lockbox 312 PARAMS ARE absent 313 SMIME-CAPS { IDENTIFIED BY id-alg-plasma-lockbox } 314 } 316 -- SignedData IDENTIFIED BY id-keyatt-plasma-token 318 id-alg-plasma-lockbox OBJECT IDENTIFIER ::= {iso(1) member-body(2) 319 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) TBD2 } 321 We define a new KEW-WRAP object called kwa-plasma-lockbox. This key 322 wrap algorithm is identified by the id-kwa-plasma-lockbox OID. The 323 key wrap algorithm has no parameters and the parameters field MUST be 324 absent the algorithm identifier is encoded. The encypted key object 325 which is emitted by the algorithm is a CMS SignedData structure. The 326 CMS SignedData structure is used directly without a CMS ContentInfo 327 structure wrapping it. 329 The SignedData structure fields are filled as follows (some less 330 significant fields are omitted): 332 encapContentInfo is a structure containing the fields: 334 eContentType is id-ct-authEnvelopedData. 336 eContent is CMS AuthEnvelopedData [RFC5083] structure with the 337 following fields: 339 recipientInfos contains the lock box(s) for the Plasma 340 servers(s) to get access to the encrypted data. There MUST 341 NOT be recipient info structures added for any entity not 342 trusted to correctly perform the policy decision processing. 343 See below for some additional discussion on what lock boxes 344 need to be created. 346 authEncryptedContentInfo is a structure containing the 347 following elements: 349 contentType is id-ct-plasma-LockBox. 351 contentEncryptionAlgorithm contains the identifier and 352 parameters for the content encryption algorithm. This 353 algorithm only needs to be understood by the Plasma 354 service. 356 encryptedContent contains the encrypted PLASMA LockBox 357 content. Details on this type are in the next section. 359 certificates SHOULD contain the set of certificates (up to but not 360 including the trust anchor) needed to validate the set of signer 361 info structures. 363 signerInfos will contain one or more signer info structures. In 364 each signature the signed attributes: 366 * MUST contain the signing time, the message digest, the content 367 type, the PLASMA hash attribute and the PLASMA url attributes. 369 * SHOULD contain the multiple signature attribute [RFC5752] if 370 more than one signature exists. 372 * MAY contain the ESS security label attribute. 374 * other attributes can also be included. 376 When creating the recipient info structures for the AuthEnvelopedData 377 structure, there will normally only need to be a single entry in the 378 sequence as the only entity that needs to decrypt the PLASMA Lockbox 379 is the Plasma Service. In the event that the service is distributed 380 over multiple servers then multiple lock boxes may need to be 381 created. One of the implications of the fact that the originator of 382 the message is the only recipient is that, although the signing key 383 needs to be contained in a certificate, there is no corresponding 384 requirement that the encryption key needs to be in a certificate. 385 Instead of using a certificate, a subject key identifier that is 386 meaningful only to the Plasma Service can be used. 388 There are a number of circumstances that a Plasma server would apply 389 multiple signatures to a single lockbox. These circumstances include 390 during key rollover while a certificate is approaching expiration, 391 esp. if there is going to be a change in the trust anchor being used. 392 Another circumstance would be if a new signature algorithm is being 393 rolled out, having the old and the new algorithm on the message 394 during the rollout period increases the chances that the signature 395 can be validated. In these circumstances, the multiple signature 396 attribute defined in RFC 5752 [RFC5752] allows for a client to 397 determine that a signature has been removed which might be attempted 398 as part of an attack to use a more insecure algorithm. 400 3.2. PLASMA Content Type 402 The inner-most content type for a Plasma Key Wrap Algorithm is a 403 Plasma Lockbox. This content is contained in an encrypted CMS object 404 which is encrypted by and for the Plasma server itself, as such the 405 contents and structure is known just to the Plasma server. 407 The content type is designed so that the Plasma server does not need 408 to keep any state dealing with a message on the server itself. This 409 allows for minimal information to be kept on the server, it only 410 needs the state of it's current transactions, and the message can be 411 processed by any of a number of servers without needing to replicate 412 state about the message between them. 414 The relevant section from the ASN.1 module which defines this content 415 is: 417 -- 418 -- PLASMA Content Type 419 -- 421 ct-plasma-LockBox CONTENT-TYPE ::= { 422 TYPE PLASMA-LockBox 423 IDENTIFIED BY id-ct-plasma-LockBox 424 } 426 id-ct-plasma-LockBox OBJECT IDENTIFIER ::= {iso(1) member-body(2) 427 us(840) rsadsi(113549) pkcs(1) pkcs7(7) TBD1} 429 PLASMA-LockBox ::= SEQUENCE { 430 policy OCTET STRING, 431 keyList KeyList, 432 attrList AttributeList OPTIONAL 433 } 435 KeyList ::= SEQUENCE { 436 namedRecipients [0] SEQUENCE SIZE (1..MAX) OF 437 NamedRecipient OPTIONAL, 438 defaultRecipients [1] SEQUENCE SIZE (1..MAX) OF 439 OneCek OPTIONAL, 440 ... 441 } 442 (WITH COMPONENTS { 443 ..., 444 namedRecipients PRESENT 445 } | 446 WITH COMPONENTS { 447 ..., 448 defaultRecipients PRESENT 449 }) 451 NamedRecipient ::= SEQUENCE { 452 recipientName UTF8String, -- name of the recipient 453 keyPolicy [0] OCTET STRING OPTIONAL, 454 keyIdentifier OCTET STRING OPTIONAL, 455 keyValue [1] ProtectedKey, 456 ... 457 } 459 ProtectedKey ::= CHOICE { 460 cms [0] RecipientInfo, 461 xml [1] OCTET STRING, 462 ... 463 } 465 OneCek ::= SEQUENCE { 466 keyPolicy [0] OCTET STRING OPTIONAL, 467 keyIdentifier [1] OCTET STRING OPTIONAL, 468 keyValue OCTET STRING, 469 ... 470 } 472 AttributeList ::= SEQUENCE SIZE (1..MAX) OF 473 SingleAttribute{{PlasmaLockboxAttributes}} 475 PlasmaLockboxAttributes ATTRIBUTE ::= { 476 aa-plasma-AuditTrailIdentifier | aa-plasma-SignerInfo | 477 aa-plasma-Xacml-Attribute, ... } 479 PlasmaSignedAttributes ATTRIBUTE ::= { 480 aa-plasma-url | aa-plasma-econtent-hash 481 } 483 In the above ASN.1, the following items are defined: 485 ct-plasma-LockBox is a new CMS content type object, this object is 486 added to the set of content type objects in ContentSet (defined in 487 the ASN.1 module in [RFC5911]). The content type associates the 488 object identifier id-ct-plasma-LockBox with the data type PLASMA- 489 LockBox. 491 id-ct-plasma-LockBox is the identifier defined for the new content 492 type. 494 PLASMA-LockBox is the new type defined for new content type. This 495 is a sequence with the following fields: 497 policy contains the policy label that is to be applied to the KEK 498 values in the keyList field. The exact content of the field 499 will be specific to the set of Plasma servers involved. 500 Servers MUST be able to deal with an XML encoding of the policy 501 in this location. See Appendix B for some alternate encodings. 503 keyList contains the key values. 505 attrList contains a set of attributes which are considered as 506 significant by the Plasma server internally. One example of an 507 attribute that goes into this location is the audit trail 508 identifier attribute. This attribute allows for an identifier 509 to tagged to the message that can be used by all entities that 510 are going to create entries in an audit log. Since they all 511 have access to a unique identifier for this message, they can 512 all use that identifier when creating their respective log 513 entries for creation, granting of access and refusing access. 514 The identifier can then be used to correlate all of these audit 515 trail events back to a single message. This document defines 516 three attributes to be placed in this location: Audit Trail 517 Identifier Section 3.4.1, Signer Info Section 3.4.2 and XACML 518 attribute Section 3.4.3. 520 KeyList is a new type that contains CEK values or KeyRecipientInfo 521 structures. This allows for messages to be sent with either 522 early-binding, where a RecipientInfo structure is filled out for 523 the receiving agent, or late-binding, where the CEK value is sent 524 from the Plasma Service to the receiving agent. It is required 525 that at least one of these fields is populated. 527 namedRecipients contains the recipient info structures for 528 individually identified recipients. 530 defaultRecipients contains the CEK keys for those recipients that 531 are not individual identified with their own recipient info 532 structures. 534 NamedRecipient contains the information identifying a single named 535 recipient along with the recipient info structures for that 536 recipient. 538 recipientName contains the name of the name of the recipient in 539 the form of an RFC5321 email address. 541 keyPolicy contains a policy string specific to this key. If 542 present the policy MUST be evaluated as accept before this 543 recipient info structure is released. Servers MUST be able to 544 deal with an XML encoding of the policy in this location. See 545 Appendix B for some alternate encodings. 547 keyIdentifier contains the identification value for the CEK. 549 keyValue contains the encrypted key for the named recipient. The 550 ProtectedKey structure is marked as extensible. If an 551 unrecognized choice is made in the ProtectedKey structure, the 552 NamedRecipient structure is to fail returning the key as it's 553 type will not be recognized. There could be another named key 554 with a different return type which can be returned 555 successfully. 557 This structure is tagged as extensible; this was done because 558 there may be a need to add additional fields such as other name 559 types in the future. 561 ProtectedKey contains the CEK encrypted in some manner. The choice 562 has the following fields: 564 cms contains a CMS recipient info structure for the named 565 recipient. 567 xml contains an XML EncryptedKey structure from the XML 568 Encryption standard [W3C.WD-xmlenc-core1-20101130]. 570 The structure is marked as extensible. Servers MUST be able to 571 deal with unrecognized encrypted key fields from future versions. 573 OneCek contains the information that defines a single CEK to be 574 used. The sequence has the fields: 576 keyPolicy contains a policy string specific to this key. If 577 present the policy MUST be evaluated as accept before this key 578 is released. Servers MUST be able to deal with an XML encoding 579 of the policy in this location. See Appendix B for some 580 alternate encodings. 582 keyIdentifier contains the identification value for the CEK. 584 keyValue contains the CEK value. 586 This structure is tagged as extensible; this was done because 587 there may be a need to add additional fields such as other name 588 types in the future. 590 AttributeList defines a structure where a set of attributes can be 591 included. 593 PLASMAAttributes defines an Object Set of attributes which can be 594 included. The object set is intentionally open ended for later 595 expansion. The object set is initialized with the three 596 attributes defined in this document. 598 PlasmaSignedAttributes defines an Object Set of attributes that are 599 intended for use as signed attributes for CMS SignedData objects. 600 This item is intended to be added to the SignedAttributesSet in 601 the CMS module in [RFC5911]. 603 The recipientName field of the NamedRecipient structure is designed 604 so that a client can build a CMS recipient info structure targeted to 605 a specific recipient. In order for the Plasma server to know which 606 of these named recipient structure to return it requires that the 607 sender identify the recipient for the CMS recipient info structure 608 and that the recipient identify itself so that the Plasma server can 609 find the correct structure. We are using Email names in the form of 610 internationalized RFC 5321 [RFC5321] address names. There are a 611 number of issues that are associated with the use of this name form 612 for comparison purposes. As stated in Section 2.3.11 of RFC 5321, 614 the local-part MUST be interpreted and assigned semantics only by 615 the host specified in the domain part of the address. 617 While many platforms do case-insensitive comparisons of mailbox 618 names, there is not a way for an independent server to know if this 619 is appropriate behavior. A similar issue exists with Unicode 620 normalization as pointed out in Section 10.1 of RFC 6530 [RFC6530]. 621 The server that holds the mailbox can have a consistent rule for 622 normalization, but a Plasma server in separate domain may not know 623 the appropriate rules to use. 625 Plasma servers SHOULD do the following when comparing the Email 626 addresses found in the recipientName field: 628 1. The domain name portion is compared using procedure in 629 Section 2.3.2.4 of [RFC5890]. The rules are: 631 * Exact (bit-string identity) matches between pairs of U-labels. 633 * Matches between a pair of A-labels, using normal DNS case- 634 insensitive matching rules. 636 * Equivalence between a U-label and an A-label determined by 637 translating the U-label form into an A-label form and then 638 testing for a match between the A-labels using normal DNS 639 case-insensitive rules. 641 2. The local name portion of the name is compared using bit-string 642 identity. Plasma servers MAY apply appropriate transformations 643 for local domain names, Plasma servers MAY provide for 644 administration configuration to allow for appropriate 645 transformations to non-local domains, but SHOULD NOT apply any 646 transformations in the absence of administrative configureation. 648 3.3. CMS Signed Data signed attributes 650 3.3.1. PLASMA URL Authenticated Attribute 652 It is required that the name of the Plasma Server be securely 653 communicated to the message recipient. For this purpose a URL is 654 used as this can communicate both a server name as well as additional 655 parameters that can be used to identify a specific service on the 656 server. 658 The relevant section from the ASN.1 module for this attribute is: 660 -- 661 -- Define the Signed Attribute to carry the 662 -- Email Policy Server URL 663 -- 664 -- This attribute is added to the SignedAttributSet set of 665 -- attributes in [CMS-ASN] 666 -- 668 aa-plasma-url ATTRIBUTE ::= { 669 TYPE UTF8String IDENTIFIED BY id-aa-plasma-url 670 } 672 id-aa-plasma-url OBJECT IDENTIFIER ::= { iso(1) member-body(2) 673 us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD3} 675 From this we can see the following: 677 A new attribute aa-plasma-url has been defined. 679 The OID value of id-aa-plasma-url has been created to identify the 680 new attribute. 682 The type of the value associated with the attribute is a 683 UTF8String which contains the URL for the Plasma Server. The URL 684 defines both the destination server and the protocol to be used. 685 When the schema for the URL is "plasma", then the protocol used is 686 [I-D.schaad-plasma-service]. 688 The new attribute is to appear only as a Signed Attribute in a 689 SignedData structure. It is therefore to be added to the 690 attribute set SignedAttributeSet in the update ASN.1 module 691 contained in [RFC5911]. 693 The attribute structure defined for signed attributes allows for 694 multiple values to be carried in a single attribute. For this 695 attribute there MUST be at least one value. If there is more than 696 one value, each value MUST be unique. Multiple values are allowed as 697 there can be multiple Plasma servers that can be used to evaluate the 698 policy. Since the URLs will be sorted during encoding, the order of 699 URLs does not indicate any order of priority, any of the values may 700 be used. 702 This attribute is only included in a SignedData object by a Plasma 703 Server. There are no processing rules for the sender of a message. 704 The processing rules for a recipient can be found in Section 5. 706 3.3.2. PLASMA Encrypted Content Hash Attribute 708 For privacy reasons, it is highly desirable that the recipient of a 709 message can validate that the Plasma lock box embedded in a message 710 is associated with encrypted data it is attached to. For this 711 reason, in addition to the requirement that a recipient validate the 712 signature of the Plasma server over the lock box, a new attribute is 713 defined which contains the hash of the encrypted content. 715 -- 716 -- Define the Signed Attribute to carry the 717 -- hash of encrypted data 718 -- 719 -- This attribute is added to the SignedAttributeSet set of 720 -- attributes in [CMS-ASN] 721 -- 723 aa-plasma-econtent-hash ATTRIBUTE ::= { 724 TYPE HashValue IDENTIFIED BY id-aa-plasma-econtent-hash 725 } 727 id-aa-plasma-econtent-hash OBJECT IDENTIFIER ::= {iso(1) 728 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD4} 730 HashValue ::= SEQUENCE { 731 hashAlgorithm DigestAlgorithmIdentifier, 732 hashValue OCTET STRING 733 } 735 The above ASN.1 fragment defines the following items: 737 aa-plasma-econtent-hash defines a new ATTRIBUTE object describing 738 the encrypted content hash attribute. This attribute is always a 739 signed object and is to be added to the SignedAttributeSet in the 740 CMS ASN.1 mdoule contained in [RFC5911]. 742 id-aa-plasma-econtent-hash defines the unique identifier of the 743 attribute. 745 HashValue defines the data value to be associated with the 746 attribute. The fields of this type are: 748 hashAlgorithm contains the identifier and parameters of the hash 749 function used. 751 hashValue contains the value of the hash operation. 753 The hash is computed over the encrypted content, without including 754 any of the ASN.1 wrapping around the content. Thus this value does 755 not cover the content type identifier, the encryption algorithm and 756 parameters or any authenticated attributes for AEAD algorithms. 758 3.4. Plasma Lockbox Attributes 760 3.4.1. Audit Trail Identifier Attribute 762 The Audit Trail Identifier attribute allows for a unique and 763 persistent identifier to be carried as part of a Plasma Lockbox 764 message. This identifier can then be used by Plasma servers when 765 creating log entries in the audit trail to designate a single Plasma 766 message. This use of a single identifier allows for better 767 correlation to occur by auditors, however as the identifier is hidden 768 from all viewers except the Plasma server, the message itself is not 769 locatable from the log entries. 771 The relevant section from the ASN.1 module which defines this 772 attribute is: 774 -- 775 -- Attribute to hold an Audit Trail Identifier 776 -- 778 aa-plasma-AuditTrailIdentifier ATTRIBUTE ::= { 779 TYPE OCTET STRING 780 IDENTIFIED BY id-aa-plasma-Audit-Trail-Identifier 781 } 783 id-aa-plasma-Audit-Trail-Identifier OBJECT IDENTIFIER ::= { 784 iso(1) member-body(2) 785 us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD6} 787 In this ASN.1, the following items are defined: 789 aa-plasma-AuditTrailIdentifier 790 This is an object of type ATTRIBUTE that associates the identifier 791 id-aa-plasma-Audit-Trail-Identifier with the type OCTET STRING. 792 When used in attrList field of a PLASMA-LockBox, the values set 793 MUST contain a single value. The value is the audit trail 794 identifier value. 796 id-aa-plasma-Audit-Trail-Identifier 797 This is the OID used to identifier this attribute. 799 The use of OCTET STRING for the content allows for the greatest 800 flexibility for Plasma Servers in devising the value to use. The 801 content of the Audit Tail Identifier is intended to be an opaque 802 value to all entities, all Plasma servers MUST be able to ignore how 803 the value is structured. 805 3.4.2. Signer Info Attribute 807 Some policies require that the inner content of an encrypted message 808 be signed as well. However the encrypted data stream of the message 809 is not provided to the Plasma server for it to verify that it was 810 done successfully. The only places to check is in the audit trail 811 for the message and/or to allow the client to do the check that the 812 signature is present. This attribute provides a location for the 813 Plasma server to place the provided CMS SignerInfo structure(s) 814 provided by the client to be carried with the message. The server 815 can then push the structure(s) to the client and the client can 816 validate that the actual signatures on the message match the 817 signatures provided by the server. All servers MUST be able to parse 818 this attribute and convert it to an appropriate XACML attribute to 819 return to clients. 821 The relevant section from the ASN.1 module which defines this 822 attribute is: 824 -- 825 -- Attribute to hold a SignerInfo structure 826 -- 828 aa-plasma-SignerInfo ATTRIBUTE ::= { 829 TYPE SignerInfo IDENTIFIED BY id-aa-plasma-signerInfo 830 } 832 id-aa-plasma-signerInfo OBJECT IDENTIFIER ::= {iso(1) 833 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD7} 835 In this ASN.1, the following items are defined: 837 aa-plasma-SignerInfo 838 This is an object of type ATTRIBUTE that associates the identifier 839 id-aa-plasma-SignerInfo with the type SignerInfo. 841 id-aa-plasma-SignerInfo 842 This OID is used to identify the attribute, it's associated type 843 and it's semantics. 845 There can be one or more attribute values in the attribute set. Each 846 of the values is to be treated independently and returned to the 847 client. The values may be returned in a single Attributes XML 848 element. 850 3.4.3. XACML Generic Attribute 852 Many times Plasma servers be in situation where they will need to 853 return various values to the clients. These decisions will 854 frequently be taken by the originating Plasma server, since it may be 855 the only one that has the data to be returned. This attribute allows 856 for any data to be carried in the form of an XACML [XACML] attribute 857 XML structure. Since the content is an XACML attribute, it can be 858 pushed to the client without the client needing to understand or 859 evaluate the content being presented. The Signer Info attribute 860 presented in the previous section could have been implemented using 861 this attribute rather than defining it's own attribute, however the 862 space savings was deemed sufficient to justify the creation of the 863 new attribute. 865 The relevant section from the ASN.1 module which defines this 866 attribute is: 868 -- 869 -- Attribute to hold an arbitrary XACML XML attribute 870 -- structure 871 -- 873 aa-plasma-Xacml-Attribute ATTRIBUTE ::= { 874 TYPE OCTET STRING IDENTIFIED BY id-aa-plasma-Xacml-Attribute 875 } 877 id-aa-plasma-Xacml-Attribute OBJECT IDENTIFIER ::= {iso(1) 878 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD8} 880 In this ASN.1, the following items are defined: 882 aa-plasma-Xacml-Attribute 883 This is an object of type ATTRIBUTE that associates the identifier 884 of id-aa-plasma-Xacml-Attribute with the type OCTET STRING. 886 id-aa-plasma-Xacml-Attribute 887 This OID is used to identify the attribute, its associated type 888 and it's semantics. 890 There can be one or more attributes values associated with the 891 attribute set. Each of the values is to be treated independently and 892 returned as separate items to the client. 894 The data type is an OCTET STRING to allow for alternate XML encodings 895 to be used. All servers MUST be able to deal with a UTF8 string XML 896 encoding of the policy in this location. See Appendix B for 897 alternate encoding methods. If a server cannot understand the 898 encoding presented, the server MUST fail processing of the lockbox. 899 If the server cannot understand the attribute, and the attribute is 900 required for processing the access control statement, the server MUST 901 fail that portion of the access control evaluation. 903 4. Sender Processing Rules 905 4.1. Flow 907 This is the set of processing steps that a sender needs to do (the 908 order of the steps is not normative): 910 1. Sender Agent obtains the set of policies under which it can send 911 a message. 913 2. Sender Agent composes the message content. 915 3. Sender Agent determines the policy label to be applied to the 916 message. 918 4. Sender Agent determines the set of recipients for the message. 920 5. Sender Agent selects the content encryption algorithm (with 921 input from the policies chosen) and randomly creates the CEK. 923 6. Sender Agent encrypts the content with the CEK and computes the 924 encrypted hash value. 926 7. Sender Agent may optionally create lock boxes for one or more 927 message recipients. (These are for the early-bind recipients 928 that are protected by the policy server.) 930 8. Sender Agent transmits the CEK, the list of recipients, the set 931 of policy protected recipient lock boxes, the encrypted hash 932 value and the policy label to the PLASMA server. 934 9. Sender Agent receives a set of recipient info structures from 935 the policy server. If the policy validation fails then the 936 sender agent cannot send the message under the current policy 937 label. 939 10. Sender Agent verifies the signature on the signed data structure 940 inside of the PLASMA-KEK attribute. 942 A. Signature is current and passes cryptographic processing. 944 B. Signed attributes contains the PLASMA URL attribute and the 945 PLASMA Encrypted Hash attribute. 947 C. The certificate used to validate the signature MUST have the 948 Plasma XXXX EKU (defined in Section X.Y of RFC XXXX). 950 D. Other standard signature checks. 952 The Sender Agent SHOULD validate all of the signatures if more 953 than one signature exists. 955 11. Sender Agent adds the recipient info structures returned from 956 the Plasma server to those it creates for early bind recipients 957 which are not protected by policy. 959 12. Sender Agent finishes encoding the message and transmits it to 960 the MTA. 962 5. Recipient Processing Rules 964 5.1. Flow 966 When looking at the validation steps that are given here, the results 967 need to be the same but the order that the steps are taken can be 968 different. As an example, it can make sense to do the policy check 969 in step Paragraph 5 before doing the signature validation as this 970 would not require any network access. 972 This is the set of processing that the recipient needs to do: 974 1. The Receiving Agent obtains the message from a Mail Transfer 975 Agent using IMAP, POP or a similar protocol. 977 2. The Receiving Agent recognizes that a KEK recipient info exists 978 with a PLASMA-KEK attribute. It is recommended that the entire 979 list of recipient info structures be checked for one that can be 980 processed directly before processing a Plasma receipient 981 structure. 983 3. The Receiving Agent validates the PLASMA-KEK attribute. The 984 following steps need to be taken for validation. 986 A. The signature on the SignedData structure is validated. If 987 the validation fails then processing ends. If more than one 988 SignerInfo element exists on the structure, then the 989 validation needs to succeed only on one SignerInfo element, 990 the signed attributes from that SignerInfo structure are 991 used. The order of performing the validation of the 992 SignerInfo structures may be influenced by the content of 993 PLASMA URL attribute. 995 B. The certificate used to validate the signature MUST contain 996 the XXXX value in the EKU extension. The certificate MUST 997 NOT contain the anyPolicy value in the EKU extension. Local 998 policy can dictate that content of the Plasma URL attribute 999 be used in selecting trust anchors for the signing 1000 certificate. 1002 C. If an ESS security label attribute ([RFC2634]) is present, 1003 then it must be evaluated and processing ends if the security 1004 label processing fails or is denied. 1006 D. If the PLASMA URL attribute is absent, then processing fails. 1008 E. The URL value in the PLASMA URL attribute is checked against 1009 local policy. If the check fails then processing fails. 1010 This check is performed so that information about the user is 1011 not given to a random Plasma server. The schema of the URL 1012 MUST be one that the client implements. (For example the 1013 "plasma" schema associated with RFC XXX 1014 [I-D.schaad-plasma-service].) As discussed in Section 4.5 of 1015 [I-D.freeman-plasma-requirements], policy can be enforced on 1016 the edge of an enterprise, this means that if multiple URLs 1017 are present in the Plasma URL attribute they all need to be 1018 checked for policy and ability to use before this step fails. 1020 F. The PLASMA Encrypted Hash attribute value is checked against 1021 the encrypted content. If this attribute is absent then 1022 processing fails. If the value does not matched the computed 1023 value on the encrypted content then processing fails. 1025 4. The recipient gathers the necessary identity and attribute 1026 statements, usual certificates or SASL statements. 1028 5. The recipient establishing a secure connection to the Plasma 1029 server and passes in the identity and attribute statements and 1030 receives back the CEK or a lock box to allow it to obtain the CEK 1031 value. 1033 5.2. Reply Processing 1035 In some circumstances a message recipient may be permitted to read a 1036 message sent under a certan policy, but it not permitted to send a 1037 message for that policy. In the event that a complex policy is used 1038 the recipient may be permitted to read under one policy, but not have 1039 any rights under a second policy. In both of these case a recipient 1040 of a message would be unable to either reply or forward a message 1041 using the same policy as they received it under. For this reason, 1042 the protocol used to communicate with the Plasma server will 1043 frequently return a single purpose policy that permits a recipient to 1044 reply to a message using the same policy as the original message. 1046 6. S/MIME Capability 1048 The SMIMECapabilities attribute was defined by S/MIME in [RFC5751] so 1049 that the abilities of a client can be advertised to the recipients of 1050 an S/MIME message. This information can be advertised either 1051 directly in an S/MIME message sent from a client to a recipient, or 1052 more indirectly by publishing the information in an LDAP directory 1053 [RFC4262]. 1055 A new S/MIME capability is defined by this document so that a client 1056 can advertise to others that it understands how to deal with Plasma 1057 recipient information. The ASN.1 for this attribute is: 1059 -- 1060 -- Create an S/MIME capability for advertising that 1061 -- a client can understand the PLASMA recipient info 1062 -- structure information 1063 -- 1065 cap-Plasma-RecipientInfo SMIME-CAPS ::= { 1066 IDENTIFIED BY id-cap-plasma-recipientInfo 1067 } 1069 id-cap-plasma-recipientInfo OBJECT IDENTIFIER ::= { 1070 id-cap TBD5 1071 } 1073 We define a new SMIME-CAPS object called cap-Plasma-RecipentInfo. 1074 This attribute is identified by the the OID id-cap-plasma- 1075 recipientInfo and has no data structure associated with it. When 1076 encoded as an S/MIME capability the parameters MUST to be absent and 1077 not NULL. 1079 7. Mandatory Algorithms 1081 7.1. Plasma Servers 1083 Servers MUST implement AES-GCC-128 [RFC5084] for the content 1084 encryption algorithm in section 3.1. Other authenticated encryption 1085 algorithms MAY be implemented. 1087 Servers MUST implement RSA v1.5 as a key transport algorithm for 1088 lockboxes created in section 3.1 and for pre-authenticated lock boxes 1089 returned in step 8 of section 4.1. Servers SHOULD implement RSA OAEP 1090 as a key transport algorithm in the same locations. Other key 1091 transport algorithms MAY be implemented. 1093 Servers MUST implement EC-DH as a key agreement algorithm for 1094 lockboxes created in section 3.1 and for pre-authenticated lock boxes 1095 returned in step 8 of section 4.1. Servers MAY implement other key 1096 agreement algorithms. 1098 Servers MUST implement the RSA v1.5 signature algorithm with SHA-256 1099 and SHA-512. Servers MUST implement the EC-DSA signature algorithm 1100 with SHA-256 and SHA-512 for producing signature on the Plasma lock 1101 box. Other signature algorithms MAY be implemented as well. 1103 7.2. Plasma Clients 1105 Clients MUST implement the mandatory algorithms defined for S/MIME 1106 [RFC5751] for the lock boxes created in step 7 and transmitted to the 1107 server in step 8 of Section 4. Other algorithms MAY be implemented. 1109 Clients MUST implement SHA-256 and SHA-512 for computation of the 1110 Plasma Encrypted Content Hash in section 3.4. Other algorithms MAY 1111 be implemented, but doing so can cause clients that do not implement 1112 this algorithm to not attempt to read the message. 1114 When verifying signatures on the Plasma lock boxes, clients MUST be 1115 able to verify the RSA v1.5 signature algorithm with SHA-256 and 1116 SHA-512. Clients MUST also be able to verify the EC-DSA signature 1117 algorithm with SHA-256 and SHA-512 signature algorithm. Clients MAY 1118 be able to verify other signature algorithms. 1120 8. Security Considerations 1122 Man in the middle attack on the protocol from the sending agent to 1123 the email policy server. 1125 Man in the middle attack on the protocol from the receiving agent to 1126 the email policy server. 1128 Still more expansion.... 1130 The hash computed for the Plasma Encrypted Content Hash attribute has 1131 different security concerns that a hash used for signature 1132 computation. This hash value is used to get a degree of assurance 1133 that the encrypted content is associated with Plasma lock box. In 1134 the event that a collision exists, then the client will go and talk 1135 to the server to get a content encryption key when that key will not 1136 successfully decrypt the content. However this does not affect the 1137 privacy of the client as the client's decision to talk to the server 1138 is based on the URL(s) of the server and the validation of the 1139 server's signature. This means that an attacker that substitutes an 1140 encrypted content needs not only to have the hash of the encrypted 1141 content be correct, but the decrypted content needs to make sense. 1142 In order for an attacker to have the client talk to it, it needs to 1143 attack the certificates or signature produced on the lock box and not 1144 the encrypted content itself. 1146 9. IANA Considerations 1148 This document requires that a number of Object Identifiers be 1149 assigned. These are now under the control of IANA following 1150 [I-D.housley-smime-oids]. 1152 IANA is requested to assign the following identifiers: 1154 o TBD9 is to be assigned from the "SMI Security for S/MIME Module 1155 Identifer" registry. The description for the entry is suggested 1156 as id-mod-plasma-2013. 1158 o TBD1 is to be assigned from the "SMI Security for S/MIME CMS 1159 Content Type" registry. The description for the entry is 1160 suggested as id-ct-plasma-LockBox. 1162 o TBD2 is to be assigned from the "SMI Security for S/MIME 1163 Algorithms" registry. The description for the entry is suggested 1164 as id-alg-plasma-lockbox. 1166 o TBD3 is to be assigned from the "SMI Security for S/MIME 1167 Attributes" registry. The description for the entry is suggested 1168 as id-aa-plasma-url. 1170 o TBD4 is to be assigned from the "SMI Security for S/MIME 1171 Attributes" registry. The description for the entry is suggested 1172 as id-aa-plasma-econtent-hash. 1174 o TBD5 is to be assigned from the "SMI Security for S/MIME 1175 Capabilities" registry. The description for the entry is 1176 suggested as id-cap-plasma-recipientInfo. 1178 o TBD6 is to be assigned from the "SMI Security for S/MIME 1179 Attributes" registry. The description for the entyr is suggested 1180 as id-aa-plasma-Audit-Trail-Identifier. 1182 o TBD7 is to be assigned from the "SMI Security for S/MIME 1183 Attributes" registry. The description for the entry is suggested 1184 as id-aa-plasma-signerInfo. 1186 o TBD8 is to be assigned from the "SMI Security for S/MIME 1187 Attributes" registry. THe description for the entry is suggested 1188 as id-aa-plasma-Xacml-Attribute. 1190 10. References 1192 10.1. Normative References 1194 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 1195 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 1196 June 2010. 1198 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 1199 Authenticated-Enveloped-Data Content Type", RFC 5083, 1200 November 2007. 1202 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 1203 2634, June 1999. 1205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1206 Requirement Levels", BCP 14, RFC 2119, March 1997. 1208 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1209 Mail Extensions (S/MIME) Version 3.2 Message 1210 Specification", RFC 5751, January 2010. 1212 [RFC5752] Turner, S. and J. Schaad, "Multiple Signatures in 1213 Cryptographic Message Syntax (CMS)", RFC 5752, January 1214 2010. 1216 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1217 October 2008. 1219 [RFC5890] Klensin, J., "Internationalized Domain Names for 1220 Applications (IDNA): Definitions and Document Framework", 1221 RFC 5890, August 2010. 1223 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 1224 Internationalized Email", RFC 6530, February 2012. 1226 [I-D.freeman-plasma-requirements] 1227 Freeman, T., Schaad, J., and P. Patterson, "Requirements 1228 for Message Access Control", draft-freeman-plasma- 1229 requirements-08 (work in progress), October 2013. 1231 [W3C.WD-xmlenc-core1-20101130] 1232 Roessler, T., Reagle, J., Hirsch, F., and D. Eastlake, 1233 "XML Encryption Syntax and Processing Version 1.1", World 1234 Wide Web Consortium LastCall WD-xmlenc-core1-20101130, 1235 November 2010, 1236 . 1238 10.2. Informative References 1240 [RFC3369] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 1241 3369, August 2002. 1243 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, 1244 June 1999. 1246 [RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/ 1247 Multipurpose Internet Mail Extensions (S/MIME) 1248 Capabilities", RFC 4262, December 2005. 1250 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 1251 Encryption in the Cryptographic Message Syntax (CMS)", RFC 1252 5084, November 2007. 1254 [I-D.schaad-plasma-service] 1255 Schaad, J., "Plasma Service Trust Processing", draft- 1256 schaad-plasma-service-04 (work in progress), January 2013. 1258 [XACML] Rissanen, E., Ed., "eXtensible Access Control Markup 1259 Language (XACML) Version 3.0", OASIS Standard 1260 xacml-201008, August 2010, . 1263 [EXI] Kamiya, T. and J. Schneider, "Efficient XML Interchange 1264 (EXI) Format 1.0", World Wide Web Consortium CR CR- 1265 exi-20091208, December 2009, 1266 . 1268 [I-D.housley-smime-oids] 1269 Housley, R., "Object Identifier Registry for the S/MIME 1270 Mail Security Working Group", draft-housley-smime-oids-00 1271 (work in progress), October 2013. 1273 Appendix A. 2009 ASN.1 Module 1275 PolicySMime-2008 { iso(1) member-body(2) us(840) rsadsi(113549) 1276 pkcs(1) pkcs-9(9) smime(16) modules(0) 1277 id-mod-plasma-2013(TBD9) } 1278 DEFINITIONS IMPLICIT TAGS ::= 1279 BEGIN 1280 IMPORTS 1281 -- Cryptographic Message Syntax (CMS) [RFC5652] 1283 CONTENT-TYPE, RecipientInfo, SignedData, 1284 DigestAlgorithmIdentifier, SignerInfo, KEY-WRAP 1285 FROM CryptographicMessageSyntax-2010 1286 { iso(1) member-body(2) us(840) rsadsi(113549) 1287 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 1289 -- Common PKIX structures [RFC5912] 1291 SMIME-CAPS 1292 FROM AlgorithmInformation-2009 1293 { iso(1) identified-organization(3) dod(6) internet(1) 1294 security(5) mechanisms(5) pkix(7) id-mod(0) 1295 id-mod-algorithmInformation-02(58)} 1297 ATTRIBUTE, SingleAttribute{} 1298 FROM PKIX-CommonTypes-2009 1299 { iso(1) identified-organization(3) dod(6) internet(1) 1300 security(5) mechanisms(5) pkix(7) id-mod(0) 1301 id-mod-pkixCommon-02(57) } 1303 ESSSecurityLabel 1304 FROM ExtendedSecurityServices-2009 1305 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1306 smime(16) modules(0) id-mod-ess-2006-02(42) } 1308 id-cap 1309 FROM SecureMimeMessage 1310 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1311 smime(16) modules(0) id-mod-msg-v3dot1-02(39) } 1312 ; 1314 -- 1315 -- PLASMA Content Type 1316 -- 1318 ct-plasma-LockBox CONTENT-TYPE ::= { 1319 TYPE PLASMA-LockBox 1320 IDENTIFIED BY id-ct-plasma-LockBox 1321 } 1323 id-ct-plasma-LockBox OBJECT IDENTIFIER ::= {iso(1) member-body(2) 1324 us(840) rsadsi(113549) pkcs(1) pkcs7(7) TBD1} 1326 PLASMA-LockBox ::= SEQUENCE { 1327 policy OCTET STRING, 1328 keyList KeyList, 1329 attrList AttributeList OPTIONAL 1330 } 1332 KeyList ::= SEQUENCE { 1333 namedRecipients [0] SEQUENCE SIZE (1..MAX) OF 1334 NamedRecipient OPTIONAL, 1335 defaultRecipients [1] SEQUENCE SIZE (1..MAX) OF 1336 OneCek OPTIONAL, 1337 ... 1338 } 1339 (WITH COMPONENTS { 1340 ..., 1341 namedRecipients PRESENT 1342 } | 1343 WITH COMPONENTS { 1344 ..., 1345 defaultRecipients PRESENT 1346 }) 1348 NamedRecipient ::= SEQUENCE { 1349 recipientName UTF8String, -- name of the recipient 1350 keyPolicy [0] OCTET STRING OPTIONAL, 1351 keyIdentifier OCTET STRING OPTIONAL, 1352 keyValue [1] ProtectedKey, 1353 ... 1354 } 1356 ProtectedKey ::= CHOICE { 1357 cms [0] RecipientInfo, 1358 xml [1] OCTET STRING, 1359 ... 1360 } 1362 OneCek ::= SEQUENCE { 1363 keyPolicy [0] OCTET STRING OPTIONAL, 1364 keyIdentifier [1] OCTET STRING OPTIONAL, 1365 keyValue OCTET STRING, 1366 ... 1367 } 1369 AttributeList ::= SEQUENCE SIZE (1..MAX) OF 1370 SingleAttribute{{PlasmaLockboxAttributes}} 1372 PlasmaLockboxAttributes ATTRIBUTE ::= { 1373 aa-plasma-AuditTrailIdentifier | aa-plasma-SignerInfo | 1374 aa-plasma-Xacml-Attribute, ... } 1376 PlasmaSignedAttributes ATTRIBUTE ::= { 1377 aa-plasma-url | aa-plasma-econtent-hash 1378 } 1380 -- 1381 -- New key wrap algorithm object for Plasma 1382 -- 1384 kwa-plasma-lockbox KEY-WRAP ::= { 1385 IDENTIFIER id-alg-plasma-lockbox 1386 PARAMS ARE absent 1387 SMIME-CAPS { IDENTIFIED BY id-alg-plasma-lockbox } 1388 } 1390 -- SignedData IDENTIFIED BY id-keyatt-plasma-token 1392 id-alg-plasma-lockbox OBJECT IDENTIFIER ::= {iso(1) member-body(2) 1393 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) TBD2 } 1395 -- 1396 -- Define the Signed Attribute to carry the 1397 -- Email Policy Server URL 1398 -- 1399 -- This attribute is added to the SignedAttributSet set of 1400 -- attributes in [CMS-ASN] 1401 -- 1403 aa-plasma-url ATTRIBUTE ::= { 1404 TYPE UTF8String IDENTIFIED BY id-aa-plasma-url 1405 } 1407 id-aa-plasma-url OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1408 us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD3} 1410 -- 1411 -- Define the Signed Attribute to carry the 1412 -- hash of encrypted data 1413 -- 1414 -- This attribute is added to the SignedAttributeSet set of 1415 -- attributes in [CMS-ASN] 1416 -- 1418 aa-plasma-econtent-hash ATTRIBUTE ::= { 1419 TYPE HashValue IDENTIFIED BY id-aa-plasma-econtent-hash 1420 } 1422 id-aa-plasma-econtent-hash OBJECT IDENTIFIER ::= {iso(1) 1423 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD4} 1425 HashValue ::= SEQUENCE { 1426 hashAlgorithm DigestAlgorithmIdentifier, 1427 hashValue OCTET STRING 1428 } 1430 -- 1431 -- Create an S/MIME capability for advertising that 1432 -- a client can understand the PLASMA recipient info 1433 -- structure information 1434 -- 1436 cap-Plasma-RecipientInfo SMIME-CAPS ::= { 1437 IDENTIFIED BY id-cap-plasma-recipientInfo 1438 } 1440 id-cap-plasma-recipientInfo OBJECT IDENTIFIER ::= { 1441 id-cap TBD5 1442 } 1444 -- 1445 -- Attribute to hold an Audit Trail Identifier 1446 -- 1448 aa-plasma-AuditTrailIdentifier ATTRIBUTE ::= { 1449 TYPE OCTET STRING 1450 IDENTIFIED BY id-aa-plasma-Audit-Trail-Identifier 1451 } 1453 id-aa-plasma-Audit-Trail-Identifier OBJECT IDENTIFIER ::= { 1454 iso(1) member-body(2) 1455 us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD6} 1457 -- 1458 -- Attribute to hold a SignerInfo structure 1459 -- 1461 aa-plasma-SignerInfo ATTRIBUTE ::= { 1462 TYPE SignerInfo IDENTIFIED BY id-aa-plasma-signerInfo 1463 } 1465 id-aa-plasma-signerInfo OBJECT IDENTIFIER ::= {iso(1) 1466 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD7} 1468 -- 1469 -- Attribute to hold an arbitrary XACML XML attribute 1470 -- structure 1471 -- 1473 aa-plasma-Xacml-Attribute ATTRIBUTE ::= { 1474 TYPE OCTET STRING IDENTIFIED BY id-aa-plasma-Xacml-Attribute 1475 } 1477 id-aa-plasma-Xacml-Attribute OBJECT IDENTIFIER ::= {iso(1) 1478 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD8} 1480 END 1482 Appendix B. Policy Encoding Techniques 1484 This appendix is informative. 1486 The fields for encoding a policy expression is an ASN.1 OCTET STRING. 1487 This field type was chosen so that servers would have the widest 1488 choice of methods to encode the policy expressions. For stand alone 1489 servers, the only issue is that the server will be able to correctly 1490 extract and use the policy expression, as such it can be kept in XML 1491 or converted into a format that is more natural to the policy 1492 evaluation engine used by the server. When one wants to use multiple 1493 servers, then all of the servers involved need to be able to use the 1494 encoded format(s) and re-map them into the internal versions that are 1495 used locally. This is far more complicated when the servers are 1496 hosted by different organizations that might be using different local 1497 policy evaluation engines. 1499 It is RECOMMENDED that what ever encoding method is used normally, a 1500 provision exist for the XML version of the policy string as presented 1501 in RFC XXX [I-D.schaad-plasma-service] exist without change. Doing 1502 so allows for a single common format to be shared among all Plasma 1503 servers independent of the organization providing the server and the 1504 one operating the server. The server will be able to determine the 1505 set of other servers that will be able to process the content, as the 1506 server must be configured with that information in order to create 1507 the appropriate lock boxes for the other servers to access the 1508 encrypted content. 1510 There are two different methods that exist where the XML encoding can 1511 be compressed before placing it into the OCTET STRING. The first 1512 would be to use the Efficient XML Interchange (EXI) Format documented 1513 in [EXI]. A second method would be to use the standard DEFLATE 1514 algorithm either with or without a pre-defined library. 1516 A possible method of encoding would to be use the first byte to 1517 identify the encoding technique, reserving 0x3C for vanilla XML 1518 strings. Following bytes could be used to determine which pre- 1519 defined table was used and then the compressed encoding. 1521 Author's Address 1523 Jim Schaad 1524 Soaring Hawk Consulting 1526 Email: ietf@augustcellars.com