idnits 2.17.1 draft-housley-ct-keypackage-receipt-n-error-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 453 has weird spacing: '...errorBy ident...' -- The document date (10 December 2013) is 3790 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 1047 == Outdated reference: A later version (-08) exists of draft-turner-application-cms-media-type-07 ** Downref: Normative reference to an Informational draft: draft-turner-application-cms-media-type (ref. 'MEDIA') ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Downref: Normative reference to an Informational RFC: RFC 6268 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) R. Housley 3 Internet-Draft Vigil Security 4 Intended Status: Standards Track 10 December 2013 5 Expires: 10 June 2014 7 Cryptographic Message Syntax (CMS) 8 Key Package Receipt and Error Content Types 9 draft-housley-ct-keypackage-receipt-n-error-07.txt 11 Abstract 13 This document defines the syntax for two Cryptographic Message Syntax 14 (CMS) content types, one for key package receipts, and another for 15 key package errors. The key package receipt content type is used to 16 confirm receipt of an identified key package or collection of key 17 packages. The key package error content type is used to indicate an 18 error occurred during the processing of a key package. CMS can be 19 used to digitally sign, digest, authenticate, or encrypt these 20 content types. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 2 56 1.2. ASN.1 Syntax Notation . . . . . . . . . . . . . . . . . . . 3 57 1.3. Processing Key Package Receipt Requests . . . . . . . . . . 3 58 1.4. Processing Key Packages with Errors . . . . . . . . . . . . 3 59 2. SIR Entity Name . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Key Package Identifier and Receipt Request Attribute . . . . . 4 61 4. Key Package Receipt CMS Content Type . . . . . . . . . . . . . 6 62 5. Key Package Error CMS Content Type . . . . . . . . . . . . . . 8 63 6. Protecting the KeyPackageReceipt and KeyPackageError . . . . . 16 64 7. Using the application/cms media type . . . . . . . . . . . . . 17 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 17 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 70 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 71 Appendix A: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 19 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 74 1. Introduction 76 This document defines the syntax for two Cryptographic Message Syntax 77 (CMS) [RFC5652] content types, one for key package receipts, and 78 another for key package errors. The key package receipt content type 79 is used to confirm receipt of an identified key package or collection 80 of key packages. The key package error content type is used to 81 indicate an error occurred during the processing of a key package. 82 CMS can be used to digitally sign, digest, authenticate, or encrypt 83 these content types. 85 1.1. Requirements Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 1.2. ASN.1 Syntax Notation 93 The content types defined herein use ASN.1 [X.680], [X.681], [X.682], 94 and [X.683]. 96 The CONTENT-TYPE definition was updated to the 2008 version of ASN.1 97 by [RFC6268]; however, none of the new 2008 ASN.1 tokens are used in 98 this specification, which allows compilers that only support the 2002 99 version of ASN.1 to compile the module in Appendix A. 101 1.3. Processing Key Package Receipt Requests 103 The key package or collection of key packages [RFC4073] [RFC5958] 104 [RFC6031] [RFC6032] for which the receipt is being generated MUST be 105 signed, and the key package MUST include the key-package-identifier- 106 and-receipt-request attribute specified in Section 3. 108 1.4. Processing Key Packages with Errors 110 The key package or collection of key packages [RFC4073] [RFC5958] 111 [RFC6031] [RFC6032] for which the error is being generated might be 112 signed. The key package can be identified by a key-package- 113 identifier-and-receipt-request attribute specified in Section 3. 115 2. SIR Entity Name 117 Within a key distribution system, the source, intermediary, and 118 receiver entities are identified by a Source Intermediary Recipient 119 (SIR) entity name. The syntax for the SIR entity name does not 120 impose any particular structure, and it accommodates straightforward 121 registration of additional SIR entity name types. 123 The inclusion of the nameType object identifier ensures that two 124 identifiers of different types that happen to contain the same values 125 are not interpreted as equivalent. Additional SIR entity name types 126 are expected to be registered that represent different granularities. 127 For example, one SIR entity name type might represent the receiver 128 organization, and at a finer granularity, another SIR entity name 129 type might identify a specific device, perhaps using a manufacturer 130 identifier and serial number. The use of an object identifier avoids 131 the need for a central registry of SIR entity name types. 133 The nameValue is an OCTET STRING, which allows the canonical form of 134 any name to be carried. Two names of the same type are considered 135 equal if the octet strings are the same length and contain the same 136 string of octets. 138 SIREntityNames and SIREntityName have the following syntax: 140 SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName 141 SIR-ENTITY-NAME ::= CLASS { 142 &SIRENType OBJECT IDENTIFIER UNIQUE, 143 &SIRENValue 144 } WITH SYNTAX { 145 SYNTAX &SIRENValue IDENTIFIED BY &SIRENType } 147 SIREntityName ::= SEQUENCE { 148 sirenType SIR-ENTITY-NAME.&SIRENType({SIREntityNameTypes}), 149 sirenValue OCTET STRING (CONTAINING 150 SIR-ENTITY-NAME.&SIRENValue( 151 {SIREntityNameTypes}{@sirenType}) ) } 153 This document defines one SIR entity name type: the DN type. The DN 154 type uses a nameType of id-dn and a nameValue of a Distinguished 155 Name. The nameValue OCTET STRING carries an ASN.1 encoded Name as 156 specified in [RFC5280]. Note that other documents may define 157 additional types. 159 SIREntityNameTypes SIR-ENTITY-NAME ::= { 160 siren-dn, 161 ... -- Expect additional SIR Enitiy Name types -- } 163 siren-dn SIR-ENTITY-NAME ::= { 164 SYNTAX DistinguishedName 165 IDENTIFIED BY id-dn } 167 id-dn OBJECT IDENTIFER ::= { 168 joint-iso-ccitt(2) country(16) us(840) organization(1) 169 gov(101) dod(2) infosec(1) sir-name-types(16) 0 } 171 3. Key Package Identifier and Receipt Request Attribute 173 The key-package-identifier-and-receipt-request attribute, as its name 174 implies, allows the originator to identify the key package and 175 optionally request receipts. This attribute can appear as a signed, 176 authenticated, and content attribute. Signed attributes are carried 177 in the CMS Signed-data content type described in Section 5 of 178 [RFC5652]. Authenticated attributes are carried in the CMS 179 Authenticated-data content type described in Section 9 of [RFC5652] 180 or in the CMS Authenticated-enveloped-data content type described in 181 Section 2 of [RFC5083]. Content attributes are carried in the 182 Content-with-attributes content type described in Section 3 of 183 [RFC4073]. 185 The key-package-identifier-and-receipt-request attribute has the 186 following syntax: 188 aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= { 189 TYPE KeyPkgIdentifierAndReceiptReq 190 IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq } 192 id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= { 193 joint-iso-itu-t(2) country(16) us(840) organization(1) 194 gov(101) dod(2) infosec(1) attributes(5) 65 } 196 KeyPkgIdentifierAndReceiptReq ::= SEQUENCE { 197 pkgID KeyPkgID, 198 receiptReq KeyPkgReceiptReq OPTIONAL } 200 KeyPkgID ::= OCTET STRING 202 KeyPkgReceiptReq ::= SEQUENCE { 203 encryptReceipt BOOLEAN DEFAULT FALSE, 204 receiptsFrom [0] SIREntityNames OPTIONAL, 205 receiptsTo SIREntityNames } 207 Even though the ATTRIBUTE syntax is defined as a SET OF 208 AttributeValue, a key-package-identifier-and-receipt-request 209 attribute MUST have a single attribute value; zero or multiple 210 instances of AttributeValue are not permitted. 212 The fields in the key-package-identifier-and-receipt-request 213 attribute have the following semantics: 215 o pkgID contains an octet string, and this syntax does not impose 216 any particular structure on the identifier. 218 o receiptReq is OPTIONAL, and when it is present, it includes an 219 encryption receipt flag, an OPTIONAL indication of which 220 receivers should generate receipts, and an indication of where 221 the receipts are to be sent. 223 * The encryption receipt flag indicates whether the key package 224 originator wants the receipt to be encrypted. If the boolean 225 is set, then the receipt SHOULD be encrypted. 227 * The OPTIONAL ReceiptsFrom field provides an indication of which 228 receivers SHOULD generate receipts. When the ReceiptsFrom 229 field is absent, then all receivers of the key package are 230 expected to return receipts. When the ReceiptsFrom field is 231 present, then a list of SIR entity names indicates which 232 receivers of the key package are requested to return receipts. 234 In this case, the receiver SHOULD return a receipt only if 235 their SIR entity name appears on the list. 237 * The receipt request does not include any key management 238 information; however, the list of SIR entity names in the 239 receiptsTo field can be used to select symmetric or asymmetric 240 keying material for the receipt receivers. 242 A receiver SHOULD ignore the nameValue associated with any 243 unrecognized nameType in either the receiptsFrom field or the 244 receiptsTo field. 246 When the key-package-identifier-and-receipt-request attribute appears 247 in more than one location in the overall key package, each occurrence 248 is evaluated independently. That is, the receiver may generate more 249 than one receipt for a single key package. However the time at which 250 the receipts are sent will depend on policies that are beyond the 251 scope of this document. 253 4. Key Package Receipt CMS Content Type 255 The key package receipt content type is used to confirm receipt of an 256 identified key package or collection of key packages. This content 257 type MUST be Distinguished Encoding Rules (DER) encoded [X.690]. 259 The key package receipt content type has the following syntax: 261 ct-key-package-receipt CONTENT-TYPE ::= { 262 TYPE KeyPackageReceipt 263 IDENTIFIED BY id-ct-KP-keyPackageReceipt } 265 id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= { 266 joint-iso-itu-t(2) country(16) us(840) organization(1) 267 gov(101) dod(2) infosec(1) formats(2) 268 key-package-content-types(78) 3 } 270 KeyPackageReceipt ::= SEQUENCE { 271 version KeyPkgVersion DEFAULT v2, 272 receiptOf KeyPkgIdentifier, 273 receivedBy SIREntityName } 275 -- Revised definition of KeyPkgVersion from [RFC6031] 276 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535) 278 KeyPkgIdentifier ::= CHOICE { 279 pkgID KeyPkgID, 280 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 282 KeyPkgID ::= OCTET STRING 284 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 286 The KeyPackageReceipt fields are used as follows: 288 o version identifies version of the key package receipt content. 289 For this version of the specification, the default value, v2, 290 MUST be used. Note that v1 was defined in an earlier version, 291 but the use of v1 is deprecated. 293 o receiptOf offers two alternatives for identifying the key package 294 for which the receipt is being generated. The first alternative, 295 pkgID, MUST be supported, and pkgID provides the key package 296 identifier of the key package or collection of key packages for 297 which this receipt is being generated. This key package 298 identifier value MUST exactly match the key package identifier 299 value of the key-package-identifier-and-receipt-request attribute 300 in the received key package or collection. The key-package- 301 identifier-and-receipt-request attribute is described Section 3. 302 The second alternative allows alternate attributes to be used to 303 define the identifier. 305 o receivedBy identifies the entity that received the key package. 306 The entity is named by an SIR entity name as specified in section 307 2. 309 Key package receipts MUST be encapsulated in a CMS SignedData content 310 type to carry the signature of the entity that is confirming receipt 311 of the identified key package or collection of key packages. Key 312 package receipts MAY be encrypted by encapsulating them in the CMS 313 EncryptedData content type, the CMS EnvelopedData content type, or 314 the AuthEnvelopedData content type. When the key package receipt is 315 signed and encrypted, it MUST be signed prior to being encrypted. 317 Note that delivery assurance is the responsibility of the protocol 318 that is used to transport and track key packages. The key package 319 receipt content type can be used in conjunction with that protocol as 320 part of an overall delivery assurance solution. 322 Because the receipts are signed, all recipients that generate key 323 package receipts MUST have a private signature key to sign the 324 receipt as well as store their own certificate or have a means of 325 obtaining the key identifier of their public key. If memory is a 326 concern, the public key identifier can be computed from the public 327 key. 329 If the receipt signer has access to a real-time clock, then the 330 binary-signing-time [RFC6019] signed attribute SHOULD be included in 331 the key package receipt to provide the date and time when it was 332 generated. 334 5. Key Package Error CMS Content Type 336 The key package error content type provides an indication of the 337 reason for rejection of a key package or collection of key packages. 338 This content type MUST be Distinguished Encoding Rules (DER) encoded 339 [X.690]. 341 The key package error content type has the following syntax: 343 ct-key-package-error CONTENT-TYPE ::= { 344 TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError } 346 id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= { 347 joint-iso-itu-t(2) country(16) us(840) organization(1) 348 gov(101) dod(2) infosec(1) formats(2) 349 key-package-content-types(78) 6 } 351 KeyPackageError ::= SEQUENCE { 352 version KeyPkgVersion DEFAULT v2, 353 errorOf [0] KeyPkgIdentifier OPTIONAL, 354 errorBy SIREntityName, 355 errorCode ErrorCodeChoice } 357 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535) 359 KeyPkgIdentifier ::= CHOICE { 360 pkgID KeyPkgID, 361 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 363 KeyPkgID ::= OCTET STRING 365 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 367 ErrorCodeChoice ::= CHOICE { 368 enum EnumeratedErrorCode, 369 oid OBJECT IDENTIFIER } 371 EnumeratedErrorCode ::= ENUMERATED { 372 decodeFailure (1), 373 badContentInfo (2), 374 badSignedData (3), 375 badEncapContent (4), 376 badCertificate (5), 377 badSignerInfo (6), 378 badSignedAttrs (7), 379 badUnsignedAttrs (8), 380 missingContent (9), 381 noTrustAnchor (10), 382 notAuthorized (11), 383 badDigestAlgorithm (12), 384 badSignatureAlgorithm (13), 385 unsupportedKeySize (14), 386 unsupportedParameters (15), 387 signatureFailure (16), 388 insufficientMemory (17), 389 incorrectTarget (23), 390 missingSignature (29), 391 resourcesBusy (30), 392 versionNumberMismatch (31), 393 revokedCertificate (33), 395 -- Error codes with values <= 33 are aligned with [RFC5934] 397 ambiguousDecrypt (60), 398 noDecryptKey (61), 399 badEncryptedData (62), 400 badEnvelopedData (63), 401 badAuthenticatedData (64), 402 badAuthEnvelopedData (65), 403 badKeyAgreeRecipientInfo (66), 404 badKEKRecipientInfo (67), 405 badEncryptContent (68), 406 badEncryptAlgorithm (69), 407 missingCiphertext (70), 408 decryptFailure (71), 409 badMACAlgorithm (72), 410 badAuthAttrs (73), 411 badUnauthAttrs (74), 412 invalidMAC (75), 413 mismatchedDigestAlg (76), 414 missingCertificate (77), 415 tooManySigners (78), 416 missingSignedAttributes (79), 417 derEncodingNotUsed (80), 418 missingContentHints (81), 419 invalidAttributeLocation (82), 420 badMessageDigest (83), 421 badKeyPackage (84), 422 badAttributes (85), 423 attributeComparisonFailure (86), 424 unsupportedSymmetricKeyPackage (87), 425 unsupportedAsymmetricKeyPackage (88), 426 constraintViolation (89), 427 ambiguousDefaultValue (90), 428 noMatchingRecipientInfo (91), 429 unsupportedKeyWrapAlgorithm (92), 430 badKeyTransRecipientInfo (93), 431 other (127), 432 ... -- Expect additional error codes -- } 434 The KeyPackageError fields are used as follows: 436 o version identifies version of the key package error content 437 structure. For this version of the specification, the default 438 value, v2, MUST be used. Note that v1 was defined in an earlier 439 version, but the use of v1 is deprecated. 441 o errorOf is OPTIONAL, and it provides the identifier of the keying 442 material for which this error is being generated. This is 443 omitted if the receiver or intermediary cannot parse the received 444 data to determine the package identifier. Also, encryption may 445 prevent an intermediary from obtaining any of the identifiers. 446 Two alternatives for identifying the keying material are 447 possible; see KeyPkgIdentifier as described in Section 4. The 448 value MUST exactly match the value of the key-package-identifier- 449 and-receipt-request attribute in the received key package or 450 collection. The key-package-identifier-and-receipt-request 451 attribute is described in Section 3. 453 o errorBy identifies the entity that received the key package. 454 The entity is named by an SIR entity name as specified in section 455 2. 457 o errorCode contains a code that indicates the reason for the 458 error. It contains either an enumerated error code from the list 459 below or an extended error code represented by an object 460 identifier. The enumerated error code alternative MUST be 461 supported. The object identifier error code MAY be supported. 463 * decodeFailure is used to indicate that the key package 464 intermediary or receiver was unable to successfully decode the 465 provided package. The specified content type and the provided 466 content do not match. 468 * badContentInfo is used to indicate that the ContentInfo syntax 469 is invalid or that the contentType carried within the 470 ContentInfo is unknown or unsupported. 472 * badSignedData is used to indicate that the SignedData syntax is 473 invalid, the version is unknown or unsupported, or more than 474 one entry is present in digestAlgorithms. 476 * badEncapContent is used to indicate that the 477 EncapsulatedContentInfo syntax is invalid within a SignedData 478 or an AuthenticatedData, or the EncryptedContentInfo syntax is 479 invalid within an AuthEnvelopedData. 481 * badCertificate is used to indicate that the syntax for one or 482 more certificates in CertificateSet or elsewhere is invalid or 483 unsupported. 485 * badSignerInfo is used to indicate that the SignerInfo syntax is 486 invalid, or the version is unknown or unsupported. 488 * badSignedAttrs is used to indicate that the signedAttrs syntax 489 within SignerInfo is invalid. 491 * badUnsignedAttrs is used to indicate that the unsignedAttrs 492 within SignerInfo contains one or more attributes. Since 493 unrecognized attributes are ignored, this error code is used 494 when the object identifier for the attribute is recognized, but 495 the value is malformed or internally inconsistent. In 496 addition, this error code can be used when policy prohibits an 497 implementation from supporting unsigned attributes. 499 * missingContent is used to indicate that the optional eContent 500 is missing in EncapsulatedContentInfo, which is required when 501 including an asymmetric key package, a symmetric key package, 502 and an encrypted key package. This error can be generated due 503 to problems located in SignedData or AuthenticatedData. 505 Note that CMS EncapsulatedContentInfo eContent field is 506 optional [RFC5652]; however, [RFC5958], [RFC6031], and 507 [RFC6032] require that the eContent be present. 509 * noTrustAnchor is used to indicate that the subjectKeyIdentifier 510 does not identify the public key of a trust anchor or a 511 certification path that terminates with an installed trust 512 anchor. 514 * notAuthorized is used to indicate that the sid within 515 SignerInfo leads to an installed trust anchor, but that trust 516 anchor is not an authorized signer for the received content 517 type. 519 * badDigestAlgorithm is used to indicate that the digestAlgorithm 520 in either SignerInfo, SignedData, or AuthenticatedData is 521 unknown or unsupported. 523 * badSignatureAlgorithm is used to indicate that the 524 signatureAlgorithm in SignerInfo is unknown or unsupported. 526 * unsupportedKeySize is used to indicate that the 527 signatureAlgorithm in SignerInfo is known and supported, but 528 the digital signature could not be validated because an 529 unsupported key size was employed by the signer. 530 Alternatively, the algorithm used in EnvelopedData, 531 AuthenticatedData, or AuthEnvelopedData to generate the key- 532 encryption key is known and supported, but an unsupported key 533 size was employed by the originator. 535 * unsupportedParameters is used to indicate that the 536 signatureAlgorithm in SignerInfo is known, but the digital 537 signature could not be validated because unsupported parameters 538 were employed by the signer. Alternatively, the algorithm used 539 in EnvelopedData, AuthenticatedData, or AuthEnvelopedData to 540 generate the key-encryption key is known and supported, but 541 unsupported parameters were employed by the originator. 543 * signatureFailure is used to indicate that the 544 signatureAlgorithm in SignerInfo is known and supported, but 545 the digital signature in the signature field within SignerInfo 546 could not be validated. 548 * insufficientMemory indicates that the key package could not be 549 processed because the intermediary or receiver did not have 550 sufficient memory to store the keying material. 552 * incorrectTarget indicates that a receiver is not the intended 553 recipient. 555 * missingSignature indicates that the receiver requires the key 556 package to be signed or authenticated with a Message 557 Authentication Check (MAC), but the received key package was 558 not signed or authenticated. 560 * resourcesBusy indicates that the resources necessary to process 561 the key package are not available at the present time, but the 562 resources might be available at some point in the future. 564 * versionNumberMismatch indicates that the version number in a 565 received key package is not acceptable. 567 * revokedCertificate indicates that one or more of the 568 certificates needed to properly process the key package has 569 been revoked. 571 * ambiguousDecrypt indicates that the EncryptedData content type 572 was used, and the key package receiver could not determine the 573 appropriate keying material to perform the decryption. 575 * noDecryptKey indicates that the receiver does not have the key 576 named in the content-decryption-key-identifier attribute (see 577 [RFC6032]). 579 * badEncryptedData indicates that the EncryptedData syntax is 580 invalid or the version is unknown or unsupported. 582 * badEnvelopedData indicates that the EnvelopedData syntax is 583 invalid or the version is unknown or unsupported. 585 * badAuthenticatedData indicates that the AuthenticatedData 586 syntax is invalid or the version is unknown or unsupported. 588 * badAuthEnvelopedData indicates that the AuthEnvelopedData 589 syntax is invalid or the version is unknown or unsupported. 591 * badKeyAgreeRecipientInfo indicates that the 592 KeyAgreeRecipientInfo syntax is invalid or the version is 593 unknown or unsupported. 595 * badKEKRecipientInfo indicates that the KEKRecipientInfo syntax 596 is invalid or the version is unknown or unsupported. 598 * badEncryptContent indicates that the EncryptedContentInfo 599 syntax is invalid, or that the content type carried within the 600 contentType is unknown or unsupported. 602 * badEncryptAlgorithm indicates that the encryption algorithm 603 identified by contentEncryptionAlgorithm in 604 EncryptedContentInfo is unknown or unsupported. This can 605 result from EncryptedData, EnvelopedData, or AuthEnvelopedData. 607 * missingCiphertext indicates that the optional encryptedContent 608 is missing in EncryptedContentInfo, which is required when 609 including an asymmetric key package, a symmetric key package, 610 and an encrypted key package. 612 * decryptFailure indicates that the encryptedContent in 613 EncryptedContentInfo did not decrypt properly. 615 * badMACAlgorithm indicates that the MAC algorithm identified by 616 MessageAuthenticationCodeAlgorithm in AuthenticatedData is 617 unknown or unsupported. 619 * badAuthAttrs is used to indicate that the authAttrs syntax 620 within AuthenticatedData or AuthEnvelopedData is invalid. 621 Since unrecognized attributes are ignored, this error code is 622 used when the object identifier for the attribute is 623 recognized, but the value is malformed or internally 624 inconsistent. 626 * badUnauthAttrs is used to indicate that the unauthAttrs syntax 627 within AuthenticatedData or AuthEnvelopedData is invalid. 628 Since unrecognized attributes are ignored, this error code is 629 used when the object identifier for the attribute is 630 recognized, but the value is malformed or internally 631 inconsistent. 633 * invalidMAC is used to indicate that the message authentication 634 code value within AuthenticatedData or AuthEnvelopedData did 635 not validate properly. 637 * mismatchedDigestAlg is used to indicate that the digest 638 algorithm in digestAlgorithms field within SignedData does not 639 match the digest algorithm used in the signature algorithm. 641 * missingCertificate indicates that a signature could not be 642 verified using a trust anchor or a certificate from the 643 certificates field within SignedData. Similarly, this error 644 code can indicate that a needed certificate is missing when 645 processing EnvelopedData, AuthEnvelopedData, or 646 AuthenticatedData. 648 * tooManySigners indicates that a SignedData content contained 649 more than one SignerInfo for a content type that requires only 650 one signer. 652 * missingSignedAttributes indicates that a SignedInfo within a 653 SignedData content did not contain any signed attributes; at a 654 minimum, the content-type and message-digest must be present, 655 as per [RFC5652]. Similarly, this error code can indicate that 656 required authenticated attributes are missing when processing 657 AuthEnvelopedData or AuthenticatedData. 659 * derEncodingNotUsed indicates that the content contained BER 660 encoding, or some other encoding, where DER encoding was 661 required. 663 * missingContentHints indicates that a SignedData content 664 encapsulates a content other than a key package or an encrypted 665 key package; however, the content-hints attribute [RFC2634] is 666 not included. Similarly, this error code can indicate that the 667 content-hints attribute was missing when processing 668 AuthEnvelopedData or AuthenticatedData. 670 * invalidAttributeLocation indicates that an attribute appeared 671 in an unacceptable location. 673 * badMessageDigest indicates that the value of the message-digest 674 attribute [RFC5652] did not match the calculated value. 676 * badKeyPackage indicates that the SymmetricKeyPackage [RFC6031] 677 or AsymmetricKeyPackage [RFC5958] syntax is invalid or that the 678 version is unknown. 680 * badAttributes indicates that an attribute collection contained 681 either multiple instances of the same attribute type that 682 allows only one instance or contained an attribute instance 683 with multiple values in an attribute that allows only one 684 value. 686 * attributeComparisonFailure indicates that multiple instances of 687 an attribute failed the comparison rules for the type of 688 attribute. 690 * unsupportedSymmetricKeyPackage indicates that the 691 implementation does not support symmetric key packages 692 [RFC6031]. 694 * unsupportedAsymmetricKeyPackage indicates that the 695 implementation does not support asymmetric key packages 696 [RFC5958]. 698 * constraintViolation indicates that one or more of the 699 attributes has a value that is not in the authorized set of 700 values for the signer [RFC6010]. That is, the value is in 701 conflict with the constraints imposed on the signer. 703 * ambiguousDefaultValue indicates that one or more of the 704 attributes that is part of the signer's constraints is omitted 705 from the key package, and the constraint permits more than one 706 value, therefore the appropriate default value for that 707 attribute or attribute cannot be determined. 709 * noMatchingRecipientInfo indicates that a recipientInfo could 710 not be found for the recipient. This can result from a keri or 711 kari found in EncryptedData, EnvelopedData, or 712 AuthEnvelopedData. 714 * unsupportedKeyWrapAlgorithm indicates that the key wrap 715 algorithm is not supported. 717 * badKeyTransRecipientInfo indicates that the 718 KeyTransRecipientInfo syntax is invalid or the version is 719 unknown or unsupported. 721 * other indicates that the key package could not be processed, 722 but the reason is not covered by any of the assigned status 723 codes. Use of this status code SHOULD be avoided. 725 The key package error content type MUST be signed if the entity 726 generating it is capable of signing it. For example, a device will 727 be incapable of signing when it is in early stages of deployment and 728 it has not been configured with a private signing key or a device has 729 an internal error that prevents use of its private signing key. When 730 it is signed, the key package error MUST be encapsulated in a CMS 731 SignedData content type to carry the signature of the party that is 732 indicating an error. When it is encrypted, the key package error 733 MUST be encapsulated in a CMS EnvelopedData content type, a CMS 734 EncryptedData content type, or a CMS AuthEnvelopedData content type. 735 When a key package error is signed and encrypted, it MUST be signed 736 prior to being encrypted. 738 All devices that generate signed key package error reports MUST store 739 their own certificate or have a means of obtaining the key identifier 740 of their public key. If memory is a concern, the public key 741 identifier can be computed from the public key. 743 If the error report signer has access to a real-time clock, then the 744 binary-signing-time attribute [RFC6019] SHOULD be included in the key 745 package error to provide the date and time when it was generated. 747 6. Protecting the KeyPackageReceipt and KeyPackageError 749 CMS protecting content types, [RFC5652] and [RFC5083], can be used to 750 provide security to the KeyPackageReceipt and KeyPackageError content 751 types: 753 o SignedData can be used to apply a digital signature. 755 o EncryptedData can be used to encrypt the content type with simple 756 symmetric encryption, where the sender and the receiver already 757 share the necessary encryption key. 759 o EnvelopedData can be used to encrypt the content type with 760 symmetric encryption, where the sender and the receiver do not 761 already share the necessary encryption key. 763 o AuthenticatedData can be used to integrity protect the content 764 type with message authentication algorithms that support 765 authenticated encryption, where key management information is 766 handled in a manner similar to EnvelopedData. 768 o AuthEnvelopedData can be used to protect the content types with 769 algorithms that support authenticated encryption, where key 770 management information is handled in a manner similar to 771 EnvelopedData. 773 7. Using the application/cms media type 775 The media type and parameters for carrying a key package receipt or a 776 key package error content type are specified in [MEDIA]. 778 8. Security Considerations 780 The key package receipt and key package error contents are not 781 necessarily protected. These content types can be combined with a 782 security protocol to protect the contents of the package. 784 The KeyPkgReceiptReq structure includes a receiptsFrom list and a 785 receiptsTo list. Both lists contain SIREntityNames. The syntax does 786 not specify a limit on the number of SIREntityNames that may be 787 included in either of these lists. In addition, there is 788 purposefully no requirement that the receiptTo entries have any 789 relation to the sender of the key package. To avoid these features 790 being used as part of a denial of service amplification, receipts 791 should only be returned for key packages with a valid signature from 792 a trusted signer. 794 If an implementation is willing to accept key packages from more than 795 one source, then there is a possibility that the same key package 796 identifier could be used by more than one source. As a result, there 797 is the potential for a receipt for one key package to be confused 798 with the receipt for another, potentially leading to confusion about 799 the keying material that is available to the recipient. In 800 environments with multiple key sources, a convention for assignment 801 of key package identifiers can avoid this potential confusion 802 altogether. 804 In some situations, returning very detailed error information can 805 provide an attacker with insight into the security processing. Where 806 this is a concern, the implementation should return the most generic 807 error code that is appropriate. However, detailed error codes are 808 very helpful during development, debugging, and interoperability 809 testing. For this reason, implementations may want to have a way to 810 configure the use of a generic error code or a detailed one. 812 9. IANA Considerations 814 None. 816 {RFC Editor: Please remove this section before publication.} 818 10. Acknowledgements 820 Many thanks to Radia Perlman, Sean Turner, Jim Schaad, and Carl 821 Wallace for their insightful review. Thanks to Robert Sparks for 822 improved wording. 824 11. References 826 11.1. Normative References 828 [MEDIA] Turner, S., R. Housley, and J. Schaad, "The 829 application/cms media type", Work in progress, September 830 2013. draft-turner-application-cms-media-type-07. 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, March 1997. 835 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 836 RFC 2634, June 1999. 838 [RFC4073] Housley, R., "Protecting Multiple Contents with the 839 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 841 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 842 Housley, R., and W. Polk, "Internet X.509 Public Key 843 Infrastructure Certificate and Certificate Revocation List 844 (CRL) Profile", RFC 5280, May 2008. 846 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 847 RFC 5652, September 2009. 849 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 850 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 851 June 2010. 853 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 854 2010. 856 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 857 Message Syntax (CMS) Content Constraints Extension", 858 RFC 6010, September 2010. 860 [RFC6019] Housley, R., "BinaryTime: An Alternate Format for 861 Representing Date and Time in ASN.1", RFC 6019, September 862 2010. 864 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 865 (CMS) Symmetric Key Package Content Type", RFC 6031, 866 December 2010. 868 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 869 (CMS) Encrypted Key Package Content Type", RFC 6032, 870 December 2010. 872 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 873 for the Cryptographic Message Syntax (CMS) and the Public 874 Key Infrastructure Using X.509 (PKIX)", RFC 6268, July 875 2011. 877 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 878 Information Technology - Abstract Syntax Notation One. 880 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 881 Information Technology - Abstract Syntax Notation One: 882 Information Object Specification. 884 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 885 Information Technology - Abstract Syntax Notation One: 886 Constraint Specification. 888 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 889 Information Technology - Abstract Syntax Notation One: 890 Parameterization of ASN.1 Specifications. 892 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 1:2002. 893 Information Technology - ASN.1 encoding rules: 894 Specification of Basic Encoding Rules (BER), Canonical 895 Encoding Rules (CER) and Distinguished Encoding Rules 896 (DER). 898 11.2. Informative References 900 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 901 Authenticated-Enveloped-Data Content Type", RFC 5083, 902 November 2007. 904 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 905 Management Protocol (TAMP)", RFC 5934, August 2010. 907 Appendix A: ASN.1 Module 909 This annex provides the normative ASN.1 definitions for the 910 structures described in this specification using ASN.1 as defined in 911 [X.680], [X.681], [X.682], and [X.683]. 913 KeyPackageReceiptAndErrorModuleV2 914 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 915 smime(16) modules(0) id-mod-keyPkgReceiptAndErrV2(63) } 917 DEFINITIONS IMPLICIT TAGS ::= 919 BEGIN 921 -- EXPORTS ALL 923 IMPORTS 925 -- FROM New SMIME ASN.1 [RFC6268] 927 CONTENT-TYPE 928 FROM CryptographicMessageSyntax-2010 929 { iso(1) member-body(2) us(840) rsadsi(113549) 930 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 932 -- From New PKIX ASN.1 [RFC5912] 934 ATTRIBUTE, SingleAttribute {} 935 FROM PKIX-CommonTypes-2009 936 { iso(1) identified-organization(3) dod(6) internet(1) 937 security(5) mechanisms(5) pkix(7) id-mod(0) 938 id-mod-pkixCommon-02(57) } 940 DistinguishedName 941 FROM PKIX1Explicit-2009 942 { iso(1) identified-organization(3) dod(6) internet(1) 943 security(5) mechanisms(5) pkix(7) id-mod(0) 944 id-mod-pkix1-explicit-02(51)} 945 ; 946 --- 947 --- Key Package Version Number (revised from [RFC6031]) 948 --- 950 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535) 952 -- 953 -- SIR Entity Name 954 -- 956 SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName 958 SIREntityNameTypes SIR-ENTITY-NAME ::= { 959 siren-dn, 960 ... -- Expect additional SIR Enitiy Name types -- } 962 SIR-ENTITY-NAME ::= CLASS { 963 &SIRENType OBJECT IDENTIFIER UNIQUE, 964 &SIRENValue 965 } WITH SYNTAX { 966 SYNTAX &SIRENValue IDENTIFIED BY &SIRENType } 968 SIREntityName ::= SEQUENCE { 969 sirenType SIR-ENTITY-NAME.&SIRENType({SIREntityNameTypes}), 970 sirenValue OCTET STRING (CONTAINING 971 SIR-ENTITY-NAME.&SIRENValue( 972 {SIREntityNameTypes}{@sirenType}) ) } 974 siren-dn SIR-ENTITY-NAME ::= { 975 SYNTAX DistinguishedName 976 IDENTIFIED BY id-dn } 978 id-dn OBJECT IDENTIFER ::= { 979 joint-iso-ccitt(2) country(16) us(840) organization(1) 980 gov(101) dod(2) infosec(1) sir-name-types(16) 0 } 982 -- 983 -- Attribute Definitions 984 -- 986 aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= { 987 TYPE KeyPkgIdentifierAndReceiptReq 988 IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq } 990 id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= { 991 joint-iso-itu-t(2) country(16) us(840) organization(1) 992 gov(101) dod(2) infosec(1) attributes(5) 65 } 994 KeyPkgIdentifierAndReceiptReq ::= SEQUENCE { 995 pkgID KeyPkgID, 996 receiptReq KeyPkgReceiptReq OPTIONAL } 998 KeyPkgID ::= OCTET STRING 1000 KeyPkgReceiptReq ::= SEQUENCE { 1001 encryptReceipt BOOLEAN DEFAULT FALSE, 1002 receiptsFrom [0] SIREntityNames OPTIONAL, 1003 receiptsTo SIREntityNames } 1005 -- 1006 -- Content Type Definitions 1007 -- 1009 KeyPackageContentTypes CONTENT-TYPE ::= { 1010 ct-key-package-receipt | 1011 ct-key-package-error, 1012 ... -- Expect additional content types -- } 1014 -- Key Package Receipt CMS Content Type 1016 ct-key-package-receipt CONTENT-TYPE ::= { 1017 TYPE KeyPackageReceipt 1018 IDENTIFIED BY id-ct-KP-keyPackageReceipt } 1020 id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= { 1021 joint-iso-itu-t(2) country(16) us(840) organization(1) 1022 gov(101) dod(2) infosec(1) formats(2) 1023 key-package-content-types(78) 3 } 1025 KeyPackageReceipt ::= SEQUENCE { 1026 version KeyPkgVersion DEFAULT v2, 1027 receiptOf KeyPkgIdentifier, 1028 receivedBy SIREntityName } 1030 KeyPkgIdentifier ::= CHOICE { 1031 pkgID KeyPkgID, 1032 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 1034 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 1035 -- Key Package Receipt CMS Content Type 1037 ct-key-package-error CONTENT-TYPE ::= { 1038 TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError } 1040 id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= { 1041 joint-iso-itu-t(2) country(16) us(840) organization(1) 1042 gov(101) dod(2) infosec(1) formats(2) 1043 key-package-content-types(78) 6 } 1045 KeyPackageError ::= SEQUENCE { 1046 version KeyPkgVersion DEFAULT v2, 1047 errorOf [0] KeyPkgIdentifier OPTIONAL, 1048 errorBy SIREntityName, 1049 errorCode ErrorCodeChoice } 1051 ErrorCodeChoice ::= CHOICE { 1052 enum EnumeratedErrorCode, 1053 oid OBJECT IDENTIFIER } 1055 EnumeratedErrorCode ::= ENUMERATED { 1056 decodeFailure (1), 1057 badContentInfo (2), 1058 badSignedData (3), 1059 badEncapContent (4), 1060 badCertificate (5), 1061 badSignerInfo (6), 1062 badSignedAttrs (7), 1063 badUnsignedAttrs (8), 1064 missingContent (9), 1065 noTrustAnchor (10), 1066 notAuthorized (11), 1067 badDigestAlgorithm (12), 1068 badSignatureAlgorithm (13), 1069 unsupportedKeySize (14), 1070 unsupportedParameters (15), 1071 signatureFailure (16), 1072 insufficientMemory (17), 1073 incorrectTarget (23), 1074 missingSignature (29), 1075 resourcesBusy (30), 1076 versionNumberMismatch (31), 1077 revokedCertificate (33), 1079 -- Error codes with values <= 33 are aligned with [RFC5934] 1081 ambiguousDecrypt (60), 1082 noDecryptKey (61), 1083 badEncryptedData (62), 1084 badEnvelopedData (63), 1085 badAuthenticatedData (64), 1086 badAuthEnvelopedData (65), 1087 badKeyAgreeRecipientInfo (66), 1088 badKEKRecipientInfo (67), 1089 badEncryptContent (68), 1090 badEncryptAlgorithm (69), 1091 missingCiphertext (70), 1092 decryptFailure (71), 1093 badMACAlgorithm (72), 1094 badAuthAttrs (73), 1095 badUnauthAttrs (74), 1096 invalidMAC (75), 1097 mismatchedDigestAlg (76), 1098 missingCertificate (77), 1099 tooManySigners (78), 1100 missingSignedAttributes (79), 1101 derEncodingNotUsed (80), 1102 missingContentHints (81), 1103 invalidAttributeLocation (82), 1104 badMessageDigest (83), 1105 badKeyPackage (84), 1106 badAttributes (85), 1107 attributeComparisonFailure (86), 1108 unsupportedSymmetricKeyPackage (87), 1109 unsupportedAsymmetricKeyPackage (88), 1110 constraintViolation (89), 1111 ambiguousDefaultValue (90), 1112 noMatchingRecipientInfo (91), 1113 unsupportedKeyWrapAlgorithm (92), 1114 badKeyTransRecipientInfo (93), 1115 other (127), 1116 ... -- Expect additional error codes -- } 1118 END 1120 Author's Address 1122 Russ Housley 1123 Vigil Security, LLC 1124 918 Spring Knoll Drive 1125 Herndon, VA 20170 1126 USA 1128 EMail: housley@vigilsec.com