idnits 2.17.00 (12 Aug 2021) /tmp/idnits34249/draft-housley-ct-keypackage-receipt-n-error-06.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 454 has weird spacing: '...errorBy ident...' -- The document date (1 December 2013) is 3093 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 1029 == Outdated reference: draft-turner-application-cms-media-type has been published as RFC 7193 ** 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 1 December 2013 5 Expires: 1 June 2014 7 Cryptographic Message Syntax (CMS) 8 Key Package Receipt and Error Content Types 9 draft-housley-ct-keypackage-receipt-n-error-06.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 142 SIR-ENTITY-NAME ::= CLASS { 143 &SIRENType OBJECT IDENTIFIER UNIQUE, 144 &SIRENValue 145 } WITH SYNTAX { 146 SYNTAX &SIRENValue IDENTIFIED BY &SIRENType } 148 SIREntityName ::= SEQUENCE { 149 sirenType SIR-ENTITY-NAME.&SIRENType({SIREntityNameTypes}), 150 sirenValue OCTET STRING (CONTAINING 151 SIR-ENTITY-NAME.&SIRENValue( 152 {SIREntityNameTypes}{@sirenType}) ) } 154 This document defines one SIR entity name type: the DN type. The DN 155 type uses a nameType of id-dn and a nameValue of a Distinguished 156 Name. The nameValue OCTET STRING carries an ASN.1 encoded Name as 157 specified in [RFC5280]. Note that other documents may define 158 additional types. 160 SIREntityNameTypes SIR-ENTITY-NAME ::= { 161 siren-dn, 162 ... -- Expect additional SIR Enitiy Name types -- } 164 siren-dn SIR-ENTITY-NAME ::= { 165 SYNTAX DistinguishedName 166 IDENTIFIED BY id-dn } 168 id-dn OBJECT IDENTIFER ::= { 169 joint-iso-ccitt(2) country(16) us(840) organization(1) 170 gov(101) dod(2) infosec(1) sir-name-types(16) 0 } 172 3. Key Package Identifier and Receipt Request Attribute 174 The key-package-identifier-and-receipt-request attribute, as its name 175 implies, allows the originator to identify the key package and 176 optionally request receipts. This attribute can appear as a signed, 177 authenticated, and content attribute. Signed attributes are carried 178 in the CMS Signed-data content type described in Section 5 of 179 [RFC5652]. Authenticated attributes are carried in the CMS 180 Authenticated-data content type described in Section 9 of [RFC5652] 181 or in the CMS Authenticated-enveloped-data content type described in 182 Section 2 of [RFC5083]. Content attributes are carried in the 183 Content-with-attributes content type described in Section 3 of 184 [RFC4073]. 186 The key-package-identifier-and-receipt-request attribute has the 187 following syntax: 189 aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= { 190 TYPE KeyPkgIdentifierAndReceiptReq 191 IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq } 193 id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= { 194 joint-iso-itu-t(2) country(16) us(840) organization(1) 195 gov(101) dod(2) infosec(1) attributes(5) 65 } 197 KeyPkgIdentifierAndReceiptReq ::= SEQUENCE { 198 pkgID KeyPkgID, 199 receiptReq KeyPkgReceiptReq OPTIONAL } 201 KeyPkgID ::= OCTET STRING 203 KeyPkgReceiptReq ::= SEQUENCE { 204 encryptReceipt BOOLEAN DEFAULT FALSE, 205 receiptsFrom [0] SIREntityNames OPTIONAL, 206 receiptsTo SIREntityNames } 208 Even though the ATTRIBUTE syntax is defined as a SET OF 209 AttributeValue, a key-package-identifier-and-receipt-request 210 attribute MUST have a single attribute value; zero or multiple 211 instances of AttributeValue are not permitted. 213 The fields in the key-package-identifier-and-receipt-request 214 attribute have the following semantics: 216 o pkgID contains an octet string, and this syntax does not impose 217 any particular structure on the identifier. 219 o receiptReq is OPTIONAL, and when it is present, it includes an 220 encryption receipt flag, an OPTIONAL indication of which 221 receivers should generate receipts, and an indication of where 222 the receipts are to be sent. 224 * The encryption receipt flag indicates whether the key package 225 originator wants the receipt to be encrypted. If the boolean 226 is set, then the receipt SHOULD be encrypted. 228 * The OPTIONAL ReceiptsFrom field provides an indication of which 229 receivers SHOULD generate receipts. When the ReceiptsFrom 230 field is absent, then all receivers of the key package are 231 expected to return receipts. When the ReceiptsFrom field is 232 present, then a list of SIR entity names indicates which 233 receivers of the key package are expected to return receipts. 235 In this case, the receiver SHOULD return a receipt only if 236 their SIR entity name appears on the list. 238 * The receipt request does not include any key management 239 information; however, the list of SIR entity names in the 240 receiptsTo field can be used to select symmetric or asymmetric 241 keying material for the receipt receivers. 243 A receiver SHOULD ignore the nameValue associated with any 244 unrecognized nameType in either the receiptsFrom field or the 245 receiptsTo field. 247 When the key-package-identifier-and-receipt-request attribute appears 248 in more than one location in the overall key package, each occurrence 249 is evaluated independently. That is, the receiver may generate more 250 than one receipt for a single key package. However the time at which 251 the receipts are sent will depend on policies that are beyond the 252 scope of this document. 254 4. Key Package Receipt CMS Content Type 256 The key package receipt content type is used to confirm receipt of an 257 identified key package or collection of key packages. This content 258 type MUST be Distinguished Encoding Rules (DER) encoded [X.690]. 260 The key package receipt content type has the following syntax: 262 ct-key-package-receipt CONTENT-TYPE ::= { 263 TYPE KeyPackageReceipt 264 IDENTIFIED BY id-ct-KP-keyPackageReceipt } 266 id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= { 267 joint-iso-itu-t(2) country(16) us(840) organization(1) 268 gov(101) dod(2) infosec(1) formats(2) 269 key-package-content-types(78) 3 } 271 KeyPackageReceipt ::= SEQUENCE { 272 version KeyPkgVersion DEFAULT v2, 273 receiptOf KeyPkgIdentifier, 274 receivedBy SIREntityName } 276 -- Revised definition of KeyPkgVersion from [RFC6031] 277 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535) 279 KeyPkgIdentifier ::= CHOICE { 280 pkgID KeyPkgID, 281 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 283 KeyPkgID ::= OCTET STRING 285 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 287 The KeyPackageReceipt fields are used as follows: 289 o version identifies version of the key package receipt content. 290 For this version of the specification, the default value, v2, 291 MUST be used. Note that v1 was defined in an earlier version, 292 but the use of v1 is deprecated. 294 o receiptOf offers two alternatives for identifying the key package 295 for which the receipt is being generated. The first alternative, 296 pkgID, MUST be supported, and pkgID provides the key package 297 identifier of the key package or collection of key packages for 298 which this receipt is being generated. This key package 299 identifier value MUST exactly match the key package identifier 300 value of the key-package-identifier-and-receipt-request attribute 301 in the received key package or collection. The key-package- 302 identifier-and-receipt-request attribute is described Section 3. 303 The second alternative allows alternate attributes to be used to 304 define the identifier. 306 o receivedBy identifies the entity that received the key package. 307 The entity is named by an SIR entity name as specified in section 308 2. 310 Key package receipts MUST be encapsulated in a CMS SignedData content 311 type to carry the signature of the entity that is confirming receipt 312 of the identified key package or collection of key packages. Key 313 package receipts MAY be encrypted by encapsulating them in the CMS 314 EncryptedData content type, the CMS EnvelopedData content type, or 315 the AuthEnvelopedData content type. When the key package receipt is 316 signed and encrypted, it MUST be signed prior to being encrypted. 318 Note that delivery assurance is the responsibility of the protocol 319 that is used to transport and track key packages. The key package 320 receipt content type can be used in conjunction with that protocol as 321 part of an overall delivery assurance solution. 323 Because the receipts are signed, all recipients that generate key 324 package receipts MUST have a private signature key to sign the 325 receipt as well as store their own certificate or have a means of 326 obtaining the key identifier of their public key. If memory is a 327 concern, the public key identifier can be computed from the public 328 key. 330 If the receipt signer has access to a real-time clock, then the 331 binary-signing-time [RFC6019] signed attribute SHOULD be included in 332 the key package receipt to provide the date and time when it was 333 generated. 335 5. Key Package Error CMS Content Type 337 The key package error content type provides an indication of the 338 reason for rejection of a key package or collection of key packages. 339 This content type MUST be Distinguished Encoding Rules (DER) encoded 340 [X.690]. 342 The key package error content type has the following syntax: 344 ct-key-package-error CONTENT-TYPE ::= { 345 TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError } 347 id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= { 348 joint-iso-itu-t(2) country(16) us(840) organization(1) 349 gov(101) dod(2) infosec(1) formats(2) 350 key-package-content-types(78) 6 } 352 KeyPackageError ::= SEQUENCE { 353 version KeyPkgVersion DEFAULT v2, 354 errorOf [0] KeyPkgIdentifier OPTIONAL, 355 errorBy SIREntityName, 356 errorCode ErrorCodeChoice } 358 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535) 360 KeyPkgIdentifier ::= CHOICE { 361 pkgID KeyPkgID, 362 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 364 KeyPkgID ::= OCTET STRING 366 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 368 ErrorCodeChoice ::= CHOICE { 369 enum EnumeratedErrorCode, 370 oid OBJECT IDENTIFIER } 372 EnumeratedErrorCode ::= ENUMERATED { 373 decodeFailure (1), 374 badContentInfo (2), 375 badSignedData (3), 376 badEncapContent (4), 377 badCertificate (5), 378 badSignerInfo (6), 379 badSignedAttrs (7), 380 badUnsignedAttrs (8), 381 missingContent (9), 382 noTrustAnchor (10), 383 notAuthorized (11), 384 badDigestAlgorithm (12), 385 badSignatureAlgorithm (13), 386 unsupportedKeySize (14), 387 unsupportedParameters (15), 388 signatureFailure (16), 389 insufficientMemory (17), 390 incorrectTarget (23), 391 missingSignature (29), 392 resourcesBusy (30), 393 versionNumberMismatch (31), 394 revokedCertificate (33), 396 -- Error codes with values <= 33 are aligned with [RFC5934] 398 ambiguousDecrypt (60), 399 noDecryptKey (61), 400 badEncryptedData (62), 401 badEnvelopedData (63), 402 badAuthenticatedData (64), 403 badAuthEnvelopedData (65), 404 badKeyAgreeRecipientInfo (66), 405 badKEKRecipientInfo (67), 406 badEncryptContent (68), 407 badEncryptAlgorithm (69), 408 missingCiphertext (70), 409 decryptFailure (71), 410 badMACAlgorithm (72), 411 badAuthAttrs (73), 412 badUnauthAttrs (74), 413 invalidMAC (75), 414 mismatchedDigestAlg (76), 415 missingCertificate (77), 416 tooManySigners (78), 417 missingSignedAttributes (79), 418 derEncodingNotUsed (80), 419 missingContentHints (81), 420 invalidAttributeLocation (82), 421 badMessageDigest (83), 422 badKeyPackage (84), 423 badAttributes (85), 424 attributeComparisonFailure (86), 425 unsupportedSymmetricKeyPackage (87), 426 unsupportedAsymmetricKeyPackage (88), 427 constraintViolation (89), 428 ambiguousDefaultValue (90), 429 noMatchingRecipientInfo (91), 430 unsupportedKeyWrapAlgorithm (92), 431 badKeyTransRecipientInfo (93), 432 other (127), 433 ... -- Expect additional error codes -- } 435 The KeyPackageError fields are used as follows: 437 o version identifies version of the key package error content 438 structure. For this version of the specification, the default 439 value, v2, MUST be used. Note that v1 was defined in an earlier 440 version, but the use of v1 is deprecated. 442 o errorOf is OPTIONAL, and it provides the identifier of the keying 443 material for which this error is being generated. This is 444 omitted if the receiver or intermediary cannot parse the received 445 data to determine the package identifier. Also, encryption may 446 prevent an intermediary from obtaining any of the identifiers. 447 Two alternatives for identifying the keying material are 448 possible; see KeyPkgIdentifier as described in Section 4. The 449 value MUST exactly match the value of the key-package-identifier- 450 and-receipt-request attribute in the received key package or 451 collection. The key-package-identifier-and-receipt-request 452 attribute is described in Section 3. 454 o errorBy identifies the entity that received the key package. 455 The entity is named by an SIR entity name as specified in section 456 2. 458 o errorCode contains a code that indicates the reason for the 459 error. It contains either an enumerated error code from the list 460 below or an extended error code represented by an object 461 identifier. The enumerated error code alternative MUST be 462 supported. The object identifier error code MAY be supported. 464 * decodeFailure is used to indicate that the key package 465 intermediary or receiver was unable to successfully decode the 466 provided package. The specified content type and the provided 467 content do not match. 469 * badContentInfo is used to indicate that the ContentInfo syntax 470 is invalid or that the contentType carried within the 471 ContentInfo is unknown or unsupported. 473 * badSignedData is used to indicate that the SignedData syntax is 474 invalid, the version is unknown or unsupported, or more than 475 one entry is present in digestAlgorithms. 477 * badEncapContent is used to indicate that the 478 EncapsulatedContentInfo syntax is invalid within a SignedData 479 or an AuthenticatedData, or the EncryptedContentInfo syntax is 480 invalid within an AuthEnvelopedData. 482 * badCertificate is used to indicate that the syntax for one or 483 more certificates in CertificateSet or elsewhere is invalid or 484 unsupported. 486 * badSignerInfo is used to indicate that the SignerInfo syntax is 487 invalid, or the version is unknown or unsupported. 489 * badSignedAttrs is used to indicate that the signedAttrs syntax 490 within SignerInfo is invalid. 492 * badUnsignedAttrs is used to indicate that the unsignedAttrs 493 within SignerInfo contains one or more attributes. Since 494 unrecognized attributes are ignored, this error code is used 495 when the object identifier for the attribute is recognized, but 496 the value is malformed or internally inconsistent. In 497 addition, this error code can be used when policy prohibits an 498 implementation from supporting unsigned attributes. 500 * missingContent is used to indicate that the optional eContent 501 is missing in EncapsulatedContentInfo, which is required when 502 including an asymmetric key package, a symmetric key package, 503 and an encrypted key package. This error can be generated due 504 to problems located in SignedData or AuthenticatedData. 506 Note that CMS EncapsulatedContentInfo eContent field is 507 optional [RFC5652]; however, [RFC5958], [RFC6031], and 508 [RFC6032] require that the eContent be present. 510 * noTrustAnchor is used to indicate that the subjectKeyIdentifier 511 does not identify the public key of a trust anchor or a 512 certification path that terminates with an installed trust 513 anchor. 515 * notAuthorized is used to indicate that the sid within 516 SignerInfo leads to an installed trust anchor, but that trust 517 anchor is not an authorized signer for the received content 518 type. 520 * badDigestAlgorithm is used to indicate that the digestAlgorithm 521 in either SignerInfo, SignedData, or AuthenticatedData is 522 unknown or unsupported. 524 * badSignatureAlgorithm is used to indicate that the 525 signatureAlgorithm in SignerInfo is unknown or unsupported. 527 * unsupportedKeySize is used to indicate that the 528 signatureAlgorithm in SignerInfo is known and supported, but 529 the digital signature could not be validated because an 530 unsupported key size was employed by the signer. 531 Alternatively, the algorithm used in EnvelopedData, 532 AuthenticatedData, or AuthEnvelopedData to generate the key- 533 encryption key is known and supported, but an unsupported key 534 size was employed by the originator. 536 * unsupportedParameters is used to indicate that the 537 signatureAlgorithm in SignerInfo is known, but the digital 538 signature could not be validated because unsupported parameters 539 were employed by the signer. Alternatively, the algorithm used 540 in EnvelopedData, AuthenticatedData, or AuthEnvelopedData to 541 generate the key-encryption key is known and supported, but 542 unsupported parameters were employed by the originator. 544 * signatureFailure is used to indicate that the 545 signatureAlgorithm in SignerInfo is known and supported, but 546 the digital signature in the signature field within SignerInfo 547 could not be validated. 549 * insufficientMemory indicates that the key package could not be 550 processed because the intermediary or receiver did not have 551 sufficient memory to store the keying material. 553 * incorrectTarget indicates that a receiver is not the intended 554 recipient. 556 * missingSignature indicates that the receiver requires the key 557 package to be signed or authenticated with a Message 558 Authentication Check (MAC), but the received key package was 559 not signed or authenticated. 561 * resourcesBusy indicates that the resources necessary to process 562 the key package are not available at the present time, but the 563 resources might be available at some point in the future. 565 * versionNumberMismatch indicates that the version number in a 566 received key package is not acceptable. 568 * revokedCertificate indicates that one or more of the 569 certificates needed to properly process the key package has 570 been revoked. 572 * ambiguousDecrypt indicates that the EncryptedData content type 573 was used, and the key package receiver could not determine the 574 appropriate keying material to perform the decryption. 576 * noDecryptKey indicates that the receiver does not have the key 577 named in the content-decryption-key-identifier attribute (see 578 [RFC6032]). 580 * badEncryptedData indicates that the EncryptedData syntax is 581 invalid or the version is unknown or unsupported. 583 * badEnvelopedData indicates that the EnvelopedData syntax is 584 invalid or the version is unknown or unsupported. 586 * badAuthenticatedData indicates that the AuthenticatedData 587 syntax is invalid or the version is unknown or unsupported. 589 * badAuthEnvelopedData indicates that the AuthEnvelopedData 590 syntax is invalid or the version is unknown or unsupported. 592 * badKeyAgreeRecipientInfo indicates that the 593 KeyAgreeRecipientInfo syntax is invalid or the version is 594 unknown or unsupported. 596 * badKEKRecipientInfo indicates that the KEKRecipientInfo syntax 597 is invalid or the version is unknown or unsupported. 599 * badEncryptContent indicates that the EncryptedContentInfo 600 syntax is invalid, or that the content type carried within the 601 contentType is unknown or unsupported. 603 * badEncryptAlgorithm indicates that the encryption algorithm 604 identified by contentEncryptionAlgorithm in 605 EncryptedContentInfo is unknown or unsupported. This can 606 result from EncryptedData, EnvelopedData, or AuthEnvelopedData. 608 * missingCiphertext indicates that the optional encryptedContent 609 is missing in EncryptedContentInfo, which is required when 610 including an asymmetric key package, a symmetric key package, 611 and an encrypted key package. 613 * decryptFailure indicates that the encryptedContent in 614 EncryptedContentInfo did not decrypt properly. 616 * badMACAlgorithm indicates that the MAC algorithm identified by 617 MessageAuthenticationCodeAlgorithm in AuthenticatedData is 618 unknown or unsupported. 620 * badAuthAttrs is used to indicate that the authAttrs syntax 621 within AuthenticatedData or AuthEnvelopedData is invalid. 622 Since unrecognized attributes are ignored, this error code is 623 used when the object identifier for the attribute is 624 recognized, but the value is malformed or internally 625 inconsistent. 627 * badUnauthAttrs is used to indicate that the unauthAttrs syntax 628 within AuthenticatedData or AuthEnvelopedData is invalid. 629 Since unrecognized attributes are ignored, this error code is 630 used when the object identifier for the attribute is 631 recognized, but the value is malformed or internally 632 inconsistent. 634 * invalidMAC is used to indicate that the message authentication 635 code value within AuthenticatedData or AuthEnvelopedData did 636 not validate properly. 638 * mismatchedDigestAlg is used to indicate that the digest 639 algorithm in digestAlgorithms field within SignedData does not 640 match the digest algorithm used in the signature algorithm. 642 * missingCertificate indicates that a signature could not be 643 verified using a trust anchor or a certificate from the 644 certificates field within SignedData. Similarly, this error 645 code can indicate that a needed certificate is missing when 646 processing EnvelopedData, AuthEnvelopedData, or 647 AuthenticatedData. 649 * tooManySigners indicates that a SignedData content contained 650 more than one SignerInfo for a content type that requires only 651 one signer. 653 * missingSignedAttributes indicates that a SignedInfo within a 654 SignedData content did not contain any signed attributes; at a 655 minimum, the content-type and message-digest must be present, 656 as per [RFC5652]. Similarly, this error code can indicate that 657 required authenticated attributes are missing when processing 658 AuthEnvelopedData or AuthenticatedData. 660 * derEncodingNotUsed indicates that the content contained BER 661 encoding, or some other encoding, where DER encoding was 662 required. 664 * missingContentHints indicates that a SignedData content 665 encapsulates a content other than a key package or an encrypted 666 key package; however, the content-hints attribute [RFC2634] is 667 not included. Similarly, this error code can indicate that the 668 content-hints attribute was missing when processing 669 AuthEnvelopedData or AuthenticatedData. 671 * invalidAttributeLocation indicates that an attribute appeared 672 in an unacceptable location. 674 * badMessageDigest indicates that the value of the message-digest 675 attribute [RFC5652] did not match the calculated value. 677 * badKeyPackage indicates that the SymmetricKeyPackage [RFC6031] 678 or AsymmetricKeyPackage [RFC5958] syntax is invalid or that the 679 version is unknown. 681 * badAttributes indicates that an attribute collection contained 682 either multiple instances of the same attribute type that 683 allows only one instance or contained an attribute instance 684 with multiple values in an attribute that allows only one 685 value. 687 * attributeComparisonFailure indicates that multiple instances of 688 an attribute failed the comparison rules for the type of 689 attribute. 691 * unsupportedSymmetricKeyPackage indicates that the 692 implementation does not support symmetric key packages 693 [RFC6031]. 695 * unsupportedAsymmetricKeyPackage indicates that the 696 implementation does not support asymmetric key packages 697 [RFC5958]. 699 * constraintViolation indicates that one or more of the 700 attributes has a value that is not in the authorized set of 701 values for the signer [RFC6010]. That is, the value is in 702 conflict with the constraints imposed on the signer. 704 * ambiguousDefaultValue indicates that one or more of the 705 attributes that is part of the signer's constraints is omitted 706 from the key package, and the constraint permits more than one 707 value, therefore the appropriate default value for that 708 attribute or attribute cannot be determined. 710 * noMatchingRecipientInfo indicates that a recipientInfo could 711 not be found for the recipient. This can result from a keri or 712 kari found in EncryptedData, EnvelopedData, or 713 AuthEnvelopedData. 715 * unsupportedKeyWrapAlgorithm indicates that the key wrap 716 algorithm is not supported. 718 * badKeyTransRecipientInfo indicates that the 719 KeyTransRecipientInfo syntax is invalid or the version is 720 unknown or unsupported. 722 * other indicates that the key package could not be processed, 723 but the reason is not covered by any of the assigned status 724 codes. Use of this status code SHOULD be avoided. 726 The key package error content type MUST be signed if the entity 727 generating it is capable of signing it. For example, a device will 728 be incapable of signing when it is in early stages of deployment and 729 it has not been configured with a private signing key or a device has 730 an internal error that prevents use of its private signing key. When 731 it is signed, the key package error MUST be encapsulated in a CMS 732 SignedData content type to carry the signature of the party that is 733 indicating an error. When it is encrypted, the key package error 734 MUST be encapsulated in a CMS EnvelopedData content type, a CMS 735 EncryptedData content type, or a CMS AuthEnvelopedData content type. 736 When a key package error is signed and encrypted, it MUST be signed 737 prior to being encrypted. 739 All devices that generate signed key package error reports MUST store 740 their own certificate or have a means of obtaining the key identifier 741 of their public key. If memory is a concern, the public key 742 identifier can be computed from the public key. 744 If the error report signer has access to a real-time clock, then the 745 binary-signing-time attribute [RFC6019] SHOULD be included in the key 746 package error to provide the date and time when it was generated. 748 6. Protecting the KeyPackageReceipt and KeyPackageError 750 CMS protecting content types, [RFC5652] and [RFC5083], can be used to 751 provide security to the KeyPackageReceipt and KeyPackageError content 752 types: 754 o SignedData can be used to apply a digital signature. 756 o EncryptedData can be used to encrypt the content type with simple 757 symmetric encryption, where the sender and the receiver already 758 share the necessary encryption key. 760 o EnvelopedData can be used to encrypt the content type with 761 symmetric encryption, where the sender and the receiver do not 762 already share the necessary encryption key. 764 o AuthenticatedData can be used to integrity protect the content 765 type with message authentication algorithms that support 766 authenticated encryption, where key management information is 767 handled in a manner similar to EnvelopedData. 769 o AuthEnvelopedData can be used to protect the content types with 770 algorithms that support authenticated encryption, where key 771 management information is handled in a manner similar to 772 EnvelopedData. 774 7. Using the application/cms media type 776 The media type and parameters for carrying a key package receipt or a 777 key package error content type are specified in [MEDIA]. 779 8. Security Considerations 781 The key package receipt and key package error contents are not 782 necessarily protected. These content types can be combined with a 783 security protocol to protect the contents of the package. 785 In some situations, returning very detailed error information can 786 provide an attacker with insight into the security processing. Where 787 this is a concern, the implementation should return the most generic 788 error code that is appropriate. However, detailed error codes are 789 very helpful during development, debugging, and interoperability 790 testing. For this reason, implementations may want to have a way to 791 configure the use of a generic error code or a detailed one. 793 9. IANA Considerations 795 None. 797 {RFC Editor: Please remove this section before publication.} 799 10. Acknowledgements 801 Many thanks to Sean Turner, Jim Schaad, and Carl Wallace for their 802 insightful review. Thanks to Robert Sparks for improved wording. 804 11. References 806 11.1. Normative References 808 [MEDIA] Turner, S., R. Housley, and J. Schaad, "The 809 application/cms media type", Work in progress, September 810 2013. draft-turner-application-cms-media-type-07. 812 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 813 Requirement Levels", BCP 14, RFC 2119, March 1997. 815 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 816 RFC 2634, June 1999. 818 [RFC4073] Housley, R., "Protecting Multiple Contents with the 819 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 821 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 822 Housley, R., and W. Polk, "Internet X.509 Public Key 823 Infrastructure Certificate and Certificate Revocation List 824 (CRL) Profile", RFC 5280, May 2008. 826 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 827 RFC 5652, September 2009. 829 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 830 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 831 June 2010. 833 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 834 2010. 836 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 837 Message Syntax (CMS) Content Constraints Extension", 838 RFC 6010, September 2010. 840 [RFC6019] Housley, R., "BinaryTime: An Alternate Format for 841 Representing Date and Time in ASN.1", RFC 6019, September 842 2010. 844 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 845 (CMS) Symmetric Key Package Content Type", RFC 6031, 846 December 2010. 848 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 849 (CMS) Encrypted Key Package Content Type", RFC 6032, 850 December 2010. 852 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 853 for the Cryptographic Message Syntax (CMS) and the Public 854 Key Infrastructure Using X.509 (PKIX)", RFC 6268, July 855 2011. 857 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 858 Information Technology - Abstract Syntax Notation One. 860 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 861 Information Technology - Abstract Syntax Notation One: 862 Information Object Specification. 864 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 865 Information Technology - Abstract Syntax Notation One: 866 Constraint Specification. 868 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 869 Information Technology - Abstract Syntax Notation One: 870 Parameterization of ASN.1 Specifications. 872 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 1:2002. 873 Information Technology - ASN.1 encoding rules: 874 Specification of Basic Encoding Rules (BER), Canonical 875 Encoding Rules (CER) and Distinguished Encoding Rules 876 (DER). 878 11.2. Informative References 880 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 881 Authenticated-Enveloped-Data Content Type", RFC 5083, 882 November 2007. 884 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 885 Management Protocol (TAMP)", RFC 5934, August 2010. 887 Appendix A: ASN.1 Module 889 This annex provides the normative ASN.1 definitions for the 890 structures described in this specification using ASN.1 as defined in 891 [X.680], [X.681], [X.682], and [X.683]. 893 KeyPackageReceiptAndErrorModuleV2 894 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 895 smime(16) modules(0) id-mod-keyPkgReceiptAndErrV2(63) } 897 DEFINITIONS IMPLICIT TAGS ::= 899 BEGIN 901 -- EXPORTS ALL 903 IMPORTS 905 -- FROM New SMIME ASN.1 [RFC6268] 907 CONTENT-TYPE 908 FROM CryptographicMessageSyntax-2010 909 { iso(1) member-body(2) us(840) rsadsi(113549) 910 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 912 -- From New PKIX ASN.1 [RFC5912] 914 ATTRIBUTE, SingleAttribute {} 915 FROM PKIX-CommonTypes-2009 916 { iso(1) identified-organization(3) dod(6) internet(1) 917 security(5) mechanisms(5) pkix(7) id-mod(0) 918 id-mod-pkixCommon-02(57) } 920 DistinguishedName 921 FROM PKIX1Explicit-2009 922 { iso(1) identified-organization(3) dod(6) internet(1) 923 security(5) mechanisms(5) pkix(7) id-mod(0) 924 id-mod-pkix1-explicit-02(51)} 925 ; 927 --- 928 --- Key Package Version Number (revised from [RFC6031]) 929 --- 931 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535) 933 -- 934 -- SIR Entity Name 935 -- 937 SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName 939 SIREntityNameTypes SIR-ENTITY-NAME ::= { 940 siren-dn, 941 ... -- Expect additional SIR Enitiy Name types -- } 943 SIR-ENTITY-NAME ::= CLASS { 944 &SIRENType OBJECT IDENTIFIER UNIQUE, 945 &SIRENValue 946 } WITH SYNTAX { 947 SYNTAX &SIRENValue IDENTIFIED BY &SIRENType } 949 SIREntityName ::= SEQUENCE { 950 sirenType SIR-ENTITY-NAME.&SIRENType({SIREntityNameTypes}), 951 sirenValue OCTET STRING (CONTAINING 952 SIR-ENTITY-NAME.&SIRENValue( 953 {SIREntityNameTypes}{@sirenType}) ) } 955 siren-dn SIR-ENTITY-NAME ::= { 956 SYNTAX DistinguishedName 957 IDENTIFIED BY id-dn } 959 id-dn OBJECT IDENTIFER ::= { 960 joint-iso-ccitt(2) country(16) us(840) organization(1) 961 gov(101) dod(2) infosec(1) sir-name-types(16) 0 } 963 -- 964 -- Attribute Definitions 965 -- 967 aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= { 968 TYPE KeyPkgIdentifierAndReceiptReq 969 IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq } 971 id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= { 972 joint-iso-itu-t(2) country(16) us(840) organization(1) 973 gov(101) dod(2) infosec(1) attributes(5) 65 } 975 KeyPkgIdentifierAndReceiptReq ::= SEQUENCE { 976 pkgID KeyPkgID, 977 receiptReq KeyPkgReceiptReq OPTIONAL } 979 KeyPkgID ::= OCTET STRING 981 KeyPkgReceiptReq ::= SEQUENCE { 982 encryptReceipt BOOLEAN DEFAULT FALSE, 983 receiptsFrom [0] SIREntityNames OPTIONAL, 984 receiptsTo SIREntityNames } 986 -- 987 -- Content Type Definitions 988 -- 990 KeyPackageContentTypes CONTENT-TYPE ::= { 991 ct-key-package-receipt | 992 ct-key-package-error, 993 ... -- Expect additional content types -- } 995 -- Key Package Receipt CMS Content Type 997 ct-key-package-receipt CONTENT-TYPE ::= { 998 TYPE KeyPackageReceipt 999 IDENTIFIED BY id-ct-KP-keyPackageReceipt } 1001 id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= { 1002 joint-iso-itu-t(2) country(16) us(840) organization(1) 1003 gov(101) dod(2) infosec(1) formats(2) 1004 key-package-content-types(78) 3 } 1006 KeyPackageReceipt ::= SEQUENCE { 1007 version KeyPkgVersion DEFAULT v2, 1008 receiptOf KeyPkgIdentifier, 1009 receivedBy SIREntityName } 1011 KeyPkgIdentifier ::= CHOICE { 1012 pkgID KeyPkgID, 1013 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 1015 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 1017 -- Key Package Receipt CMS Content Type 1019 ct-key-package-error CONTENT-TYPE ::= { 1020 TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError } 1022 id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= { 1023 joint-iso-itu-t(2) country(16) us(840) organization(1) 1024 gov(101) dod(2) infosec(1) formats(2) 1025 key-package-content-types(78) 6 } 1027 KeyPackageError ::= SEQUENCE { 1028 version KeyPkgVersion DEFAULT v2, 1029 errorOf [0] KeyPkgIdentifier OPTIONAL, 1030 errorBy SIREntityName, 1031 errorCode ErrorCodeChoice } 1033 ErrorCodeChoice ::= CHOICE { 1034 enum EnumeratedErrorCode, 1035 oid OBJECT IDENTIFIER } 1037 EnumeratedErrorCode ::= ENUMERATED { 1038 decodeFailure (1), 1039 badContentInfo (2), 1040 badSignedData (3), 1041 badEncapContent (4), 1042 badCertificate (5), 1043 badSignerInfo (6), 1044 badSignedAttrs (7), 1045 badUnsignedAttrs (8), 1046 missingContent (9), 1047 noTrustAnchor (10), 1048 notAuthorized (11), 1049 badDigestAlgorithm (12), 1050 badSignatureAlgorithm (13), 1051 unsupportedKeySize (14), 1052 unsupportedParameters (15), 1053 signatureFailure (16), 1054 insufficientMemory (17), 1055 incorrectTarget (23), 1056 missingSignature (29), 1057 resourcesBusy (30), 1058 versionNumberMismatch (31), 1059 revokedCertificate (33), 1061 -- Error codes with values <= 33 are aligned with [RFC5934] 1063 ambiguousDecrypt (60), 1064 noDecryptKey (61), 1065 badEncryptedData (62), 1066 badEnvelopedData (63), 1067 badAuthenticatedData (64), 1068 badAuthEnvelopedData (65), 1069 badKeyAgreeRecipientInfo (66), 1070 badKEKRecipientInfo (67), 1071 badEncryptContent (68), 1072 badEncryptAlgorithm (69), 1073 missingCiphertext (70), 1074 decryptFailure (71), 1075 badMACAlgorithm (72), 1076 badAuthAttrs (73), 1077 badUnauthAttrs (74), 1078 invalidMAC (75), 1079 mismatchedDigestAlg (76), 1080 missingCertificate (77), 1081 tooManySigners (78), 1082 missingSignedAttributes (79), 1083 derEncodingNotUsed (80), 1084 missingContentHints (81), 1085 invalidAttributeLocation (82), 1086 badMessageDigest (83), 1087 badKeyPackage (84), 1088 badAttributes (85), 1089 attributeComparisonFailure (86), 1090 unsupportedSymmetricKeyPackage (87), 1091 unsupportedAsymmetricKeyPackage (88), 1092 constraintViolation (89), 1093 ambiguousDefaultValue (90), 1094 noMatchingRecipientInfo (91), 1095 unsupportedKeyWrapAlgorithm (92), 1096 badKeyTransRecipientInfo (93), 1097 other (127), 1098 ... -- Expect additional error codes -- } 1100 END 1102 Author's Address 1104 Russ Housley 1105 Vigil Security, LLC 1106 918 Spring Knoll Drive 1107 Herndon, VA 20170 1108 USA 1110 EMail: housley@vigilsec.com