idnits 2.17.00 (12 Aug 2021) /tmp/idnits33744/draft-housley-ct-keypackage-receipt-n-error-02.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 431 has weird spacing: '...errorBy ident...' -- The document date (17 May 2013) is 3291 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) == Missing Reference: 'RFC6268' is mentioned on line 869, but not defined -- Looks like a reference, but probably isn't: '0' on line 968 ** Downref: Normative reference to an Informational RFC: RFC 5912 Summary: 1 error (**), 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) Russ Housley 3 Internet-Draft Vigil Security 4 Intended Status: Standards Track 17 May 2013 5 Expires: 17 November 2013 7 Cryptographic Message Syntax (CMS) 8 Key Package Receipt and Error Content Types 9 draft-housley-ct-keypackage-receipt-n-error-02.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 . . . . . 18 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 18 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 70 Appendix A: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 21 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 73 1. Introduction 75 This document defines the syntax for two Cryptographic Message Syntax 76 (CMS) [RFC5652] content types, one for key package receipts, and 77 another for key package errors. The key package receipt content type 78 is used to confirm receipt of an identified key package or collection 79 of key packages. The key package error content type is used to 80 indicate an error occurred during the processing of a key package. 81 CMS can be used to digitally sign, digest, authenticate, or encrypt 82 these content types. 84 1.1. Requirements Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 1.2. ASN.1 Syntax Notation 92 The content types defined herein use ASN.1 [X.680], [X.681], [X.682], 93 and [X.683]. 95 The CONTENT-TYPE definition was updated to the 2008 version of ASN.1 96 by [RFC6268]; however, none of the new 2008 ASN.1 tokens are used in 97 this specification, which allows compilers that only support the 2002 98 version of ASN.1 to compile the module in Appendix A. 100 1.3. Processing Key Package Receipt Requests 102 The key package or collection of key packages [RFC4073] [RFC5958] 103 [RFC6031] [RFC6032] for which the receipt is being generated MUST be 104 signed, and the key package MUST include the key-package-identifier- 105 and-receipt-request attribute specified in Section 3. 107 1.4. Processing Key Packages with Errors 109 The key package or collection of key packages [RFC4073] [RFC5958] 110 [RFC6031] [RFC6032] for which the error is being generated might be 111 signed. The key package can be identified by a key-package- 112 identifier-and-receipt-request attribute specified in Section 3. 114 2. SIR Entity Name 116 Within a key distribution system, the source, intermediary, and 117 receiver entities are identified by a Source Intermediary Recipient 118 (SIR) entity name. The syntax for the SIR entity name does not 119 impose any particular structure, and it accommodates straightforward 120 registration of additional SIR entity name types. 122 The inclusion of the nameType object identifier ensures that two 123 identifiers of different types that happen to contain the same values 124 are not interpreted as equivalent. Additional SIR entity name types 125 are expected to be registered that represent different granularities. 126 For example, one SIR entity name type might represent the receiver 127 organization, and at a finer granularity, another SIR entity name 128 type might identify a specific device, perhaps using a manufacturer 129 identifier and serial number. The use of an object identifier avoids 130 the need for a central registry of SIR entity name types. 132 The nameValue is an OCTET STRING, which allows the canonical form of 133 any name to be carried. Two names of the same type are considered 134 equal if the octet strings are the same length and contain the same 135 string of octets. 137 SIREntityNames and SIREntityName have the following syntax: 139 SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName 141 SIREntityName ::= SEQUENCE { 142 nameType OBJECT IDENTIFIER, 143 nameValue OCTET STRING } 145 This document defines one SIR entity name type: the DN type. The DN 146 type uses a nameType of id-dn and a nameValue of a Distinguished 147 Name. The nameValue OCTET STRING carries an ASN.1 encoded Name as 148 specified in [RFC5280]. Note that other documents may define 149 additional types. 151 id-dn OBJECT IDENTIFER ::= { 152 joint-iso-ccitt(2) country(16) us(840) organization(1) 153 gov(101) dod(2) infosec(1) sir-name-types(16) 0 } 155 3. Key Package Identifier and Receipt Request Attribute 157 The key-package-identifier-and-receipt-request attribute, as its name 158 implies, allows the originator to identify the key package and 159 optionally request receipts. This attribute can appear as a signed, 160 authenticated, and content attribute. Signed attributes are carried 161 in the CMS Signed-data content type described in Section 5 of 162 [RFC5652]. Authenticated attributes are carried in the CMS 163 Authenticated-data content type described in Section 9 of [RFC5652] 164 or in the CMS Authenticated-enveloped-data content type described in 165 Section 2 of [RFC5083]. Content attributes are carried in the 166 Content-with-attributes content type described in Section 3 of 167 [RFC4073]. 169 The key-package-identifier-and-receipt-request attribute has the 170 following syntax: 172 aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= { 173 TYPE KeyPkgIdentifierAndReceiptReq 174 IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq } 176 id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= { 177 joint-iso-itu-t(2) country(16) us(840) organization(1) 178 gov(101) dod(2) infosec(1) attributes(5) 65 } 180 KeyPkgIdentifierAndReceiptReq ::= SEQUENCE { 181 pkgID KeyPkgID, 182 receiptReq KeyPkgReceiptReq OPTIONAL } 184 KeyPkgID ::= OCTET STRING 185 KeyPkgReceiptReq ::= SEQUENCE { 186 encryptReceipt BOOLEAN DEFAULT FALSE, 187 receiptsFrom [0] SIREntityNames OPTIONAL, 188 receiptsTo SIREntityNames } 189 Even though the ATTRIBUTE syntax is defined as a SET OF 190 AttributeValue, a key-package-identifier-and-receipt-request 191 attribute MUST have a single attribute value; zero or multiple 192 instances of AttributeValue are not permitted. 194 The fields in the key-package-identifier-and-receipt-request 195 attribute have the following semantics: 197 o pkgID contains an octet string, and this syntax does not impose 198 any particular structure on the identifier. 200 o receiptReq is OPTIONAL, and when it is present, it includes an 201 encryption receipt flag, an OPTIONAL indication of which 202 receivers should generate receipts, and an indication of where 203 the receipts are to be sent. 205 * The encryption receipt flag indicates whether the key package 206 originator wants the receipt to be encrypted. If the boolean 207 is set, then the receipt SHOULD be encrypted. 209 * The OPTIONAL ReceiptsFrom field provides an indication of which 210 receivers SHOULD generate receipts. When the ReceiptsFrom 211 field is absent, then all receivers of the key package are 212 expected to return receipts. When the ReceiptsFrom field is 213 present, then a list of SIR entity names indicates which 214 receivers of the key package are expected to return receipts. 215 In this case, the receiver SHOULD return a receipt only if 216 their SIR entity name appears on the list. 218 * The receipt request does not include any key management 219 information; however, the list of SIR entity names in the 220 receiptsTo field can be used to select symmetric or asymmetric 221 keying material for the receipt receivers. 223 A receiver SHOULD ignore the nameValue associated with any 224 unrecognized nameType in either the receiptsFrom field or the 225 receiptsTo field. 227 When the key-package-identifier-and-receipt-request attribute appears 228 in more than one location in the overall key package, each occurrence 229 is evaluated independently. That is, the receiver may generate more 230 than one receipt for a single key package. However the time at which 231 the receipts are sent will depend on policies that are beyond the 232 scope of this document. 234 4. Key Package Receipt CMS Content Type 236 The key package receipt content type is used to confirm receipt of an 237 identified key package or collection of key packages. This content 238 type MUST be Distinguished Encoding Rules (DER) encoded [X.690]. 240 The key package receipt content type has the following syntax: 242 ct-key-package-receipt CONTENT-TYPE ::= { 243 TYPE KeyPackageReceipt 244 IDENTIFIED BY id-ct-KP-keyPackageReceipt } 246 id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= { 247 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 248 smime(16) ct(1) TBD1 } 250 KeyPackageReceipt ::= SEQUENCE { 251 version KeyPkgVersion DEFAULT v2, 252 receiptOf KeyPkgIdentifier, 253 receivedBy SIREntityName } 255 -- Revised definition of KeyPkgVersion from [RFC6031] 256 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535) 258 KeyPkgIdentifier ::= CHOICE { 259 pkgID KeyPkgID, 260 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 262 KeyPkgID ::= OCTET STRING 264 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 266 The KeyPackageReceipt fields are used as follows: 268 o version identifies version of the key package receipt content. 269 For this version of the specification, the default value, v2, 270 MUST be used. Note that v1 was defined in an earlier version, 271 but the use of v1 is deprecated. 273 o receiptOf offers two alternatives for identifying the key package 274 for which the receipt is being generated. The first alternative, 275 pkgID, MUST be supported, and pkgID provides the key package 276 identifier of the key package or collection of key packages for 277 which this receipt is being generated. This key package 278 identifier value MUST exactly match the key package identifier 279 value of the key-package-identifier-and-receipt-request attribute 280 in the received key package or collection. The key-package- 281 identifier-and-receipt-request attribute is described Section 3. 282 The second alternative allows alternate attributes to be used to 283 define the identifier. 285 o receivedBy identifies the entity that received the key package. 286 The entity is named by an SIR entity name as specified in section 287 2. 289 Key package receipts MUST be encapsulated in a CMS SignedData content 290 type to carry the signature of the entity that is confirming receipt 291 of the identified key package or collection of key packages. Key 292 package receipts MAY be encrypted by encapsulating them in the CMS 293 EncryptedData content type, the CMS EnvelopedData content type, or 294 the AuthEnvelopedData content type. When the key package receipt is 295 signed and encrypted, it MUST be signed prior to being encrypted. 297 Note that delivery assurance is the responsibility of the protocol 298 that is used to transport and track key packages. The key package 299 receipt content type can be used in conjunction with that protocol as 300 part of an overall delivery assurance solution. 302 Because the receipts are signed, all recipients that generate key 303 package receipts MUST have a private signature key to sign the 304 receipt as well as store their own certificate or have a means of 305 obtaining the key identifier of their public key. If memory is a 306 concern, the public key identifier can be computed from the public 307 key. 309 If the receipt signer has access to a real-time clock, then the 310 binary-signing-time [RFC6019] signed attribute SHOULD be included in 311 the key package receipt to provide the date and time when it was 312 generated. 314 5. Key Package Error CMS Content Type 316 The key package error content type provides an indication of the 317 reason for rejection of a key package or collection of key packages. 318 This content type MUST be Distinguished Encoding Rules (DER) encoded 319 [X.690]. 321 The key package error content type has the following syntax: 323 ct-key-package-error CONTENT-TYPE ::= { 324 TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError } 326 id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= { 327 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 328 smime(16) ct(1) TBD2 } 330 KeyPackageError ::= SEQUENCE { 331 version KeyPkgVersion DEFAULT v2, 332 errorOf [0] KeyPkgIdentifier OPTIONAL, 333 errorBy SIREntityName, 334 errorCode ErrorCodeChoice } 336 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535) 337 KeyPkgIdentifier ::= CHOICE { 338 pkgID KeyPkgID, 339 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 341 KeyPkgID ::= OCTET STRING 343 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 345 ErrorCodeChoice ::= CHOICE { 346 enum EnumeratedErrorCode, 347 oid OBJECT IDENTIFIER } 349 EnumeratedErrorCode ::= ENUMERATED { 350 decodeFailure (1), 351 badContentInfo (2), 352 badSignedData (3), 353 badEncapContent (4), 354 badCertificate (5), 355 badSignerInfo (6), 356 badSignedAttrs (7), 357 badUnsignedAttrs (8), 358 missingContent (9), 359 noTrustAnchor (10), 360 notAuthorized (11), 361 badDigestAlgorithm (12), 362 badSignatureAlgorithm (13), 363 unsupportedKeySize (14), 364 unsupportedParameters (15), 365 signatureFailure (16), 366 insufficientMemory (17), 367 incorrectTarget (23), 368 missingSignature (29), 369 resourcesBusy (30), 370 versionNumberMismatch (31), 371 revokedCertificate (33), 373 -- Error codes above this point are aligned with [RFC5934] 375 ambiguousDecrypt (60), 376 noDecryptKey (61), 377 badEncryptedData (62), 378 badEnvelopedData (63), 379 badAuthenticatedData (64), 380 badAuthEnvelopedData (65), 381 badKeyAgreeRecipientInfo (66), 382 badKEKRecipientInfo (67), 383 badEncryptContent (68), 384 badEncryptAlgorithm (69), 385 missingCiphertext (70), 386 decryptFailure (71), 387 badMACAlgorithm (72), 388 badAuthAttrs (73), 389 badUnauthAttrs (74), 390 invalidMAC (75), 391 mismatchedDigestAlg (76), 392 missingCertificate (77), 393 tooManySigners (78), 394 missingSignedAttributes (79), 395 derEncodingNotUsed (80), 396 missingContentHints (81), 397 invalidAttributeLocation (82), 398 badMessageDigest (83), 399 badKeyPackage (84), 400 badAttributes (85), 401 attributeComparisonFailure (86), 402 unsupportedSymmetricKeyPackage (87), 403 unsupportedAsymmetricKeyPackage (88), 404 constraintViolation (89), 405 ambiguousDefaultValue (90), 406 noMatchingRecipientInfo (91), 407 unsupportedKeyWrapAlgorithm (92), 408 badKeyTransRecipientInfo (93), 409 other (127), 410 ... -- Expect additional error codes -- } 412 The KeyPackageError fields are used as follows: 414 o version identifies version of the key package error content 415 structure. For this version of the specification, the default 416 value, v2, MUST be used. Note that v1 was defined in an earlier 417 version, but the use of v1 is deprecated. 419 o errorOf is OPTIONAL, and it provides the identifier of the keying 420 material for which this error is being generated. This is 421 omitted if the receiver or intermediary cannot parse the received 422 data to determine the package identifier. Also, encryption may 423 prevent an intermediary from obtaining any of the identifiers. 424 Two alternatives for identifying the keying material are 425 possible; see KeyPkgIdentifier as described in Section 4. The 426 value MUST exactly match the value of the key-package-identifier- 427 and-receipt-request attribute in the received key package or 428 collection. The key-package-identifier-and-receipt-request 429 attribute is described in Section 3. 431 o errorBy identifies the entity that received the key package. 432 The entity is named by an SIR entity name as specified in section 433 2. 435 o errorCode contains a code that indicates the reason for the 436 error. It contains either an enumerated error code from the list 437 below or an extended error code represented by an object 438 identifier. The enumerated error code alternative MUST be 439 supported. The object identifier error code MAY be supported. 441 * decodeFailure is used to indicate that the key package 442 intermediary or receiver was unable to successfully decode the 443 provided package. The specified content type and the provided 444 content do not match. 446 * badContentInfo is used to indicate that the ContentInfo syntax 447 is invalid or that the contentType carried within the 448 ContentInfo is unknown or unsupported. 450 * badSignedData is used to indicate that the SignedData syntax is 451 invalid, the version is unknown or unsupported, or more than 452 one entry is present in digestAlgorithms. 454 * badEncapContent is used to indicate that the 455 EncapsulatedContentInfo syntax is invalid within a SignedData 456 or an AuthenticatedData, or the EncryptedContentInfo syntax is 457 invalid within an AuthEnvelopedData. 459 * badCertificate is used to indicate that the syntax for one or 460 more certificates in CertificateSet or elsewhere is invalid or 461 unsupported. 463 * badSignerInfo is used to indicate that the SignerInfo syntax is 464 invalid, or the version is unknown or unsupported. 466 * badSignedAttrs is used to indicate that the signedAttrs syntax 467 within SignerInfo is invalid. 469 * badUnsignedAttrs is used to indicate that the unsignedAttrs 470 within SignerInfo contains one or more attributes. Since 471 unrecognized attributes are ignored, this error code is used 472 when the object identifier for the attribute is recognized, but 473 the value is malformed or internally inconsistent. In 474 addition, this error code can be used when policy prohibits an 475 implementation from supporting unsigned attributes. 477 * missingContent is used to indicate that the optional eContent 478 is missing in EncapsulatedContentInfo, which is required when 479 including an asymmetric key package, a symmetric key package, 480 and an encrypted key package. This error can be generated due 481 to problems located in SignedData or AuthenticatedData. 483 Note that CMS EncapsulatedContentInfo eContent field is 484 optional [RFC5652]; however, [RFC5958], [RFC6031], and 485 [RFC6032] require that the eContent be present. 487 * noTrustAnchor is used to indicate that the subjectKeyIdentifier 488 does not identify the public key of a trust anchor or a 489 certification path that terminates with an installed trust 490 anchor. 492 * notAuthorized is used to indicate that the sid within 493 SignerInfo leads to an installed trust anchor, but that trust 494 anchor is not an authorized signer for the received content 495 type. 497 * badDigestAlgorithm is used to indicate that the digestAlgorithm 498 in either SignerInfo, SignedData, or AuthenticatedData is 499 unknown or unsupported. 501 * badSignatureAlgorithm is used to indicate that the 502 signatureAlgorithm in SignerInfo is unknown or unsupported. 504 * unsupportedKeySize is used to indicate that the 505 signatureAlgorithm in SignerInfo is known and supported, but 506 the digital signature could not be validated because an 507 unsupported key size was employed by the signer. 508 Alternatively, the algorithm used in EnvelopedData, 509 AuthenticatedData, or AuthEnvelopedData to generate the key- 510 encryption key is known and supported, but an unsupported key 511 size was employed by the originator. 513 * unsupportedParameters is used to indicate that the 514 signatureAlgorithm in SignerInfo is known, but the digital 515 signature could not be validated because unsupported parameters 516 were employed by the signer. Alternatively, the algorithm used 517 in EnvelopedData, AuthenticatedData, or AuthEnvelopedData to 518 generate the key-encryption key is known and supported, but 519 unsupported parameters were employed by the originator. 521 * signatureFailure is used to indicate that the 522 signatureAlgorithm in SignerInfo is known and supported, but 523 the digital signature in the signature field within SignerInfo 524 could not be validated. 526 * insufficientMemory indicates that the key package could not be 527 processed because the intermediary or receiver did not have 528 sufficient memory to store the keying material. 530 * incorrectTarget indicates that a receiver is not the intended 531 recipient. 533 * missingSignature indicates that the receiver requires the key 534 package to be signed or authenticated with a Message 535 Authentication Check (MAC), but the received key package was 536 not signed or authenticated. 538 * resourcesBusy indicates that the resources necessary to process 539 the key package are not available at the present time, but the 540 resources might be available at some point in the future. 542 * versionNumberMismatch indicates that the version number in a 543 received key package is not acceptable. 545 * revokedCertificate indicates that one or more of the 546 certificates needed to properly process the key package has 547 been revoked. 549 * ambiguousDecrypt indicates that the EncryptedData content type 550 was used, and the key package receiver could not determine the 551 appropriate keying material to perform the decryption. 553 * noDecryptKey indicates that the receiver does not have the key 554 named in the content-decryption-key-identifier attribute (see 555 [RFC6032]). 557 * badEncryptedData indicates that the EncryptedData syntax is 558 invalid or the version is unknown or unsupported. 560 * badEnvelopedData indicates that the EnvelopedData syntax is 561 invalid or the version is unknown or unsupported. 563 * badAuthenticatedData indicates that the AuthenticatedData 564 syntax is invalid or the version is unknown or unsupported. 566 * badAuthEnvelopedData indicates that the AuthEnvelopedData 567 syntax is invalid or the version is unknown or unsupported. 569 * badKeyAgreeRecipientInfo indicates that the 570 KeyAgreeRecipientInfo syntax is invalid or the version is 571 unknown or unsupported. 573 * badKEKRecipientInfo indicates that the KEKRecipientInfo syntax 574 is invalid or the version is unknown or unsupported. 576 * badEncryptContent indicates that the EncryptedContentInfo 577 syntax is invalid, or that the content type carried within the 578 contentType is unknown or unsupported. 580 * badEncryptAlgorithm indicates that the encryption algorithm 581 identified by contentEncryptionAlgorithm in 582 EncryptedContentInfo is unknown or unsupported. This can 583 result from EncryptedData, EnvelopedData, or AuthEnvelopedData. 585 * missingCiphertext indicates that the optional encryptedContent 586 is missing in EncryptedContentInfo, which is required when 587 including an asymmetric key package, a symmetric key package, 588 and an encrypted key package. 590 * decryptFailure indicates that the encryptedContent in 591 EncryptedContentInfo did not decrypt properly. 593 * badMACAlgorithm indicates that the MAC algorithm identified by 594 MessageAuthenticationCodeAlgorithm in AuthenticatedData is 595 unknown or unsupported. 597 * badAuthAttrs is used to indicate that the authAttrs syntax 598 within AuthenticatedData or AuthEnvelopedData is invalid. 599 Since unrecognized attributes are ignored, this error code is 600 used when the object identifier for the attribute is 601 recognized, but the value is malformed or internally 602 inconsistent. 604 * badUnauthAttrs is used to indicate that the unauthAttrs syntax 605 within AuthenticatedData or AuthEnvelopedData is invalid. 606 Since unrecognized attributes are ignored, this error code is 607 used when the object identifier for the attribute is 608 recognized, but the value is malformed or internally 609 inconsistent. 611 * invalidMAC is used to indicate that the message authentication 612 code value within AuthenticatedData or AuthEnvelopedData did 613 not validate properly. 615 * mismatchedDigestAlg is used to indicate that the digest 616 algorithm in digestAlgorithms field within SignedData does not 617 match the digest algorithm used in the signature algorithm. 619 * missingCertificate indicates that a signature could not be 620 verified using a trust anchor or a certificate from the 621 certificates field within SignedData. Similarly, this error 622 code can indicate that a needed certificate is missing when 623 processing EnvelopedData, AuthEnvelopedData, or 624 AuthenticatedData. 626 * tooManySigners indicates that a SignedData content contained 627 more than one SignerInfo for a content type that requires only 628 one signer. 630 * missingSignedAttributes indicates that a SignedInfo within a 631 SignedData content did not contain any signed attributes; at a 632 minimum, the content-type and message-digest must be present, 633 as per [RFC5652]. Similarly, this error code can indicate that 634 required authenticated attributes are missing when processing 635 AuthEnvelopedData or AuthenticatedData. 637 * derEncodingNotUsed indicates that the content contained BER 638 encoding, or some other encoding, where DER encoding was 639 required. 641 * missingContentHints indicates that a SignedData content 642 encapsulates a content other than a key package or an encrypted 643 key package; however, the content-hints attribute [RFC2634] is 644 not included. Similarly, this error code can indicate that the 645 content-hints attribute was missing when processing 646 AuthEnvelopedData or AuthenticatedData. 648 * invalidAttributeLocation indicates that an attribute appeared 649 in an unacceptable location. 651 * badMessageDigest indicates that the value of the message-digest 652 attribute [RFC5652] did not match the calculated value. 654 * badKeyPackage indicates that the SymmetricKeyPackage [RFC6031] 655 or AsymmetricKeyPackage [RFC5958] syntax is invalid or that the 656 version is unknown. 658 * badAttributes indicates that an attribute collection contained 659 either multiple instances of the same attribute type that 660 allows only one instance or contained an attribute instance 661 with multiple values in an attribute that allows only one 662 value. 664 * attributeComparisonFailure indicates that multiple instances of 665 an attribute failed the comparison rules for the type of 666 attribute. 668 * unsupportedSymmetricKeyPackage indicates that the 669 implementation does not support symmetric key packages 670 [RFC6031]. 672 * unsupportedAsymmetricKeyPackage indicates that the 673 implementation does not support asymmetric key packages 675 [RFC5958]. 677 * constraintViolation indicates that one or more of the 678 attributes has a value that is not in the authorized set of 679 values for the signer [RFC6010]. That is, the value is in 680 conflict with the constraints imposed on the signer. 682 * ambiguousDefaultValue indicates that one or more of the 683 attributes that is part of the signer's constraints is omitted 684 from the key package, and the constraint permits more than one 685 value, therefore the appropriate default value for that 686 attribute or attribute cannot be determined. 688 * noMatchingRecipientInfo indicates that a recipientInfo could 689 not be found for the recipient. This can result from a keri or 690 kari found in EncryptedData, EnvelopedData, or 691 AuthEnvelopedData. 693 * unsupportedKeyWrapAlgorithm indicates that the key wrap 694 algorithm is not supported. 696 * badKeyTransRecipientInfo indicates that the 697 KeyTransRecipientInfo syntax is invalid or the version is 698 unknown or unsupported. 700 * other indicates that the key package could not be processed, 701 but the reason is not covered by any of the assigned status 702 codes. Use of this status code SHOULD be avoided. 704 The key package error content type MUST be signed if the entity 705 generating it is capable of signing it. For example, a device will 706 be incapable of signing when it is in early stages of deployment and 707 it has not been configured with a private signing key or a device has 708 an internal error that prevents use of its private signing key. When 709 it is signed, the key package error MUST be encapsulated in a CMS 710 SignedData content type to carry the signature of the party that is 711 indicating an error. When it is encrypted, the key package error 712 MUST be encapsulated in a CMS EnvelopedData content type, a CMS 713 EncryptedData content type, or a CMS AuthEnvelopedData content type. 714 When a key package error is signed and encrypted, it MUST be signed 715 prior to being encrypted. 717 All devices that generate signed key package error reports MUST store 718 their own certificate or have a means of obtaining the key identifier 719 of their public key. If memory is a concern, the public key 720 identifier can be computed from the public key. 722 If the error report signer has access to a real-time clock, then the 723 binary-signing-time attribute [RFC6019] SHOULD be included in the key 724 package error to provide the date and time when it was generated. 726 6. Protecting the KeyPackageReceipt and KeyPackageError 728 CMS protecting content types, [RFC5652] and [RFC5083], can be used to 729 provide security to the KeyPackageReceipt and KeyPackageError content 730 types: 732 o SignedData can be used to apply a digital signature. 734 o EncryptedData can be used to encrypt the content type with simple 735 symmetric encryption, where the sender and the receiver already 736 share the necessary encryption key. 738 o EnvelopedData can be used to encrypt the content type with 739 symmetric encryption, where the sender and the receiver do not 740 already share the necessary encryption key. 742 o AuthenticatedData can be used to integrity protect the content 743 type with message authentication algorithms that support 744 authenticated encryption, where key management information is 745 handled in a manner similar to EnvelopedData. 747 o AuthEnvelopedData can be used to protect the content types with 748 algorithms that support authenticated encryption, where key 749 management information is handled in a manner similar to 750 EnvelopedData. 752 7. Security Considerations 754 The key package receipt and key package error contents are not 755 necessarily protected. These content types can be combined with a 756 security protocol to protect the contents of the package. 758 In some situations, returning very detailed error information can 759 provide an attacker with insight into the security processing. Where 760 this is a concern, the implementation should return the most generic 761 error code that is appropriate. However, detailed error codes are 762 very helpful during development, debugging, and interoperability 763 testing. For this reason, implementations may want to have a way to 764 configure the use of a generic error code or a detailed one. 766 8. IANA Considerations 768 None. 770 {RFC Editor: Please remove this section before publication.} 772 9. Acknowledgements 773 Thanks to Sean Turner and Jim Schaad for their insightful revie 775 10. References 777 10.1. Normative References 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, March 1997. 782 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 783 RFC 2634, June 1999. 785 [RFC4073] Housley, R., "Protecting Multiple Contents with the 786 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 788 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 789 Housley, R., and W. Polk, "Internet X.509 Public Key 790 Infrastructure Certificate and Certificate Revocation List 791 (CRL) Profile", RFC 5280, May 2008. 793 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 794 RFC 5652, September 2009. 796 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 797 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 798 June 2010. 800 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 801 2010. 803 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 804 Message Syntax (CMS) Content Constraints Extension", 805 RFC 6010, September 2010. 807 [RFC6019] Housley, R., "BinaryTime: An Alternate Format for 808 Representing Date and Time in ASN.1", RFC 6019, September 809 2010. 811 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 812 (CMS) Symmetric Key Package Content Type", RFC 6031, 813 December 2010. 815 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 816 (CMS) Encrypted Key Package Content Type", RFC 6032, 817 December 2010. 819 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 820 Information Technology - Abstract Syntax Notation One. 822 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 823 Information Technology - Abstract Syntax Notation One: 824 Information Object Specification. 826 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 827 Information Technology - Abstract Syntax Notation One: 828 Constraint Specification. 830 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 831 Information Technology - Abstract Syntax Notation One: 832 Parameterization of ASN.1 Specifications. 834 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 1:2002. 835 Information Technology - ASN.1 encoding rules: 836 Specification of Basic Encoding Rules (BER), Canonical 837 Encoding Rules (CER) and Distinguished Encoding Rules 838 (DER). 840 10.2. Informative References 842 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 843 Authenticated-Enveloped-Data Content Type", RFC 5083, 844 November 2007. 846 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 847 Management Protocol (TAMP)", RFC 5934, August 2010. 849 Appendix A: ASN.1 Module 851 This annex provides the normative ASN.1 definitions for the 852 structures described in this specification using ASN.1 as defined in 853 [X.680], [X.681], [X.682], and [X.683]. 855 KeyPackageReceiptAndErrorModuleV2 856 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 857 smime(16) modules(0) TBD3 } 859 -- TO DO: Get Three OID values assigned. 861 DEFINITIONS IMPLICIT TAGS ::= 863 BEGIN 865 -- EXPORTS ALL 867 IMPORTS 869 -- FROM New SMIME ASN.1 [RFC6268] 871 CONTENT-TYPE 872 FROM CryptographicMessageSyntax-2010 873 { iso(1) member-body(2) us(840) rsadsi(113549) 874 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 876 -- From New PKIX ASN.1 [RFC5912] 878 ATTRIBUTE, SingleAttribute {} 879 FROM PKIX-CommonTypes-2009 880 { iso(1) identified-organization(3) dod(6) internet(1) 881 security(5) mechanisms(5) pkix(7) id-mod(0) 882 id-mod-pkixCommon-02(57) } 883 ; 884 --- 885 --- Key Package Version Number (revised from [RFC6031]) 886 --- 888 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535) 890 -- 891 -- SIR Entity Name 892 -- 894 SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName 896 SIREntityName ::= SEQUENCE { 897 nameType OBJECT IDENTIFIER, 898 nameValue OCTET STRING } 900 id-dn OBJECT IDENTIFER ::= { 901 joint-iso-ccitt(2) country(16) us(840) organization(1) 902 gov(101) dod(2) infosec(1) sir-name-types(16) 0 } 904 -- 905 -- Attribute Definitions 906 -- 908 aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= { 909 TYPE KeyPkgIdentifierAndReceiptReq 910 IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq } 912 id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= { 913 joint-iso-itu-t(2) country(16) us(840) organization(1) 914 gov(101) dod(2) infosec(1) attributes(5) 65 } 916 KeyPkgIdentifierAndReceiptReq ::= SEQUENCE { 917 pkgID KeyPkgID, 918 receiptReq KeyPkgReceiptReq OPTIONAL } 920 KeyPkgID ::= OCTET STRING 922 KeyPkgReceiptReq ::= SEQUENCE { 923 encryptReceipt BOOLEAN DEFAULT FALSE, 924 receiptsFrom [0] SIREntityNames OPTIONAL, 925 receiptsTo SIREntityNames } 927 -- 928 -- Content Type Definitions 929 -- 931 KeyPackageContentTypes CONTENT-TYPE ::= { 932 ct-key-package-receipt | 933 ct-key-package-error, 934 ... -- Expect additional content types -- } 936 -- Key Package Receipt CMS Content Type 938 ct-key-package-receipt CONTENT-TYPE ::= { 939 TYPE KeyPackageReceipt 940 IDENTIFIED BY id-ct-KP-keyPackageReceipt } 942 id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= { 943 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 944 smime(16) ct(1) TBD1 } 946 KeyPackageReceipt ::= SEQUENCE { 947 version KeyPkgVersion DEFAULT v2, 948 receiptOf KeyPkgIdentifier, 949 receivedBy SIREntityName } 951 KeyPkgIdentifier ::= CHOICE { 952 pkgID KeyPkgID, 953 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 955 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 957 -- Key Package Receipt CMS Content Type 959 ct-key-package-error CONTENT-TYPE ::= { 960 TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError } 962 id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= { 963 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 964 smime(16) ct(1) TBD2 } 966 KeyPackageError ::= SEQUENCE { 967 version KeyPkgVersion DEFAULT v2, 968 errorOf [0] KeyPkgIdentifier OPTIONAL, 969 errorBy SIREntityName, 970 errorCode ErrorCodeChoice } 972 ErrorCodeChoice ::= CHOICE { 973 enum EnumeratedErrorCode, 974 oid OBJECT IDENTIFIER } 976 EnumeratedErrorCode ::= ENUMERATED { 977 decodeFailure (1), 978 badContentInfo (2), 979 badSignedData (3), 980 badEncapContent (4), 981 badCertificate (5), 982 badSignerInfo (6), 983 badSignedAttrs (7), 984 badUnsignedAttrs (8), 985 missingContent (9), 986 noTrustAnchor (10), 987 notAuthorized (11), 988 badDigestAlgorithm (12), 989 badSignatureAlgorithm (13), 990 unsupportedKeySize (14), 991 unsupportedParameters (15), 992 signatureFailure (16), 993 insufficientMemory (17), 994 incorrectTarget (23), 995 missingSignature (29), 996 resourcesBusy (30), 997 versionNumberMismatch (31), 998 revokedCertificate (33), 1000 -- Error codes above this point are aligned with [RFC5934] 1002 ambiguousDecrypt (60), 1003 noDecryptKey (61), 1004 badEncryptedData (62), 1005 badEnvelopedData (63), 1006 badAuthenticatedData (64), 1007 badAuthEnvelopedData (65), 1008 badKeyAgreeRecipientInfo (66), 1009 badKEKRecipientInfo (67), 1010 badEncryptContent (68), 1011 badEncryptAlgorithm (69), 1012 missingCiphertext (70), 1013 decryptFailure (71), 1014 badMACAlgorithm (72), 1015 badAuthAttrs (73), 1016 badUnauthAttrs (74), 1017 invalidMAC (75), 1018 mismatchedDigestAlg (76), 1019 missingCertificate (77), 1020 tooManySigners (78), 1021 missingSignedAttributes (79), 1022 derEncodingNotUsed (80), 1023 missingContentHints (81), 1024 invalidAttributeLocation (82), 1025 badMessageDigest (83), 1026 badKeyPackage (84), 1027 badAttributes (85), 1028 attributeComparisonFailure (86), 1029 unsupportedSymmetricKeyPackage (87), 1030 unsupportedAsymmetricKeyPackage (88), 1031 constraintViolation (89), 1032 ambiguousDefaultValue (90), 1033 noMatchingRecipientInfo (91), 1034 unsupportedKeyWrapAlgorithm (92), 1035 badKeyTransRecipientInfo (93), 1036 other (127), 1037 ... -- Expect additional error codes -- } 1039 END 1041 Author's Address 1043 Russ Housley 1044 Vigil Security, LLC 1045 918 Spring Knoll Drive 1046 Herndon, VA 20170 1047 USA 1049 EMail: housley@vigilsec.com