idnits 2.17.00 (12 Aug 2021) /tmp/idnits32894/draft-housley-ct-keypackage-receipt-n-error-00.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 415 has weird spacing: '...errorBy ident...' -- The document date (17 April 2013) is 3321 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 935 ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Downref: Normative reference to an Informational RFC: RFC 6268 Summary: 2 errors (**), 0 flaws (~~), 2 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 April 2013 5 Expires: 19 October 2013 7 Cryptographic Message Syntax (CMS) 8 Key Package Receipt and Error Content Types 9 draft-housley-ct-keypackage-receipt-n-error-00.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 . . . . . . . . . . . . . 5 62 5. Key Package Error CMS Content Type . . . . . . . . . . . . . . 7 63 6. Protecting the KeyPackageReceipt and KeyPackageError . . . . . 16 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 16 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 69 10.2. Informative References . . . . . . . . . . . . . . . . . 18 70 Appendix A: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 19 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 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 an SIR entity name. The syntax 118 for the SIR entity name does not impose any particular structure, and 119 it accommodates straightforward registration of additional SIR entity 120 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 SIREntityNames and SIREntityName have the following syntax: 134 SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName 136 SIREntityName ::= SEQUENCE { 137 nameType OBJECT IDENTIFIER, 138 nameValue OCTET STRING } 140 This document defines one SIR entity name type: the DN type. The DN 141 type uses a nameType of id-dn and a nameValue of a Distinguished 142 Name. The nameValue OCTET STRING carries an ASN.1 encoded Name as 143 specified in [RFC5280]. Note that other documents may define 144 additional types. 146 id-dn OBJECT IDENTIFER ::= { 147 joint-iso-ccitt(2) country(16) us(840) organization(1) 148 gov(101) dod(2) infosec(1) sir-name-types(16) 0 } 150 3. Key Package Identifier and Receipt Request Attribute 152 The key-package-identifier-and-receipt-request attribute, as its name 153 implies, allows the originator to identify the key package and 154 optionally request receipts. This attribute can appear as a signed, 155 authenticated, and content attribute. 157 The key-package-identifier-and-receipt-request attribute has the 158 following syntax: 160 aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= { 161 TYPE KeyPkgIdentifierAndReceiptReq 162 IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq } 164 id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= { 165 joint-iso-itu-t(2) country(16) us(840) organization(1) 166 gov(101) dod(2) infosec(1) attributes(5) 65 } 168 KeyPkgIdentifierAndReceiptReq ::= SEQUENCE { 169 pkgID KeyPkgID, 170 receiptReq KeyPkgReceiptReq OPTIONAL } 172 KeyPkgID ::= OCTET STRING 174 KeyPkgReceiptReq ::= SEQUENCE { 175 encryptReceipt BOOLEAN DEFAULT FALSE, 176 receiptsFrom [0] SIREntityNames OPTIONAL, 177 receiptsTo SIREntityNames } 179 The fields in the key-package-identifier-and-receipt-request 180 attribute have the following semantics: 182 o pkgID contains an octet string, and this syntax does not impose 183 any particular structure on the identifier. 185 o receiptReq is OPTIONAL, and when it is present, it includes an 186 encryption receipt flag, an OPTIONAL indication of which 187 receivers should generate receipts, and an indication of where 188 the receipts are to be sent. 190 * The encryption receipt flag indicates whether the key package 191 originator wants the receipt to be encrypted. If the boolean 192 is set, then the receipt SHOULD be encrypted. 194 * The OPTIONAL ReceiptsFrom field provides an indication of which 195 receivers SHOULD generate receipts. When the ReceiptsFrom 196 field is absent, then all receivers of the key package are 197 expected to return receipts. When the ReceiptsFrom field is 198 present, then a list of SIR entity names indicates which 199 receivers of the key package are expected to return receipts. 200 In this case, the receiver SHOULD return a receipt only if 201 their SIR entity name appears on the list. 203 * The receipt request does not include any key management 204 information; however, the list of SIR entity names in the 205 receiptsTo field can be used to select symmetric or asymmetric 206 keying material for the receipt receivers. 208 A receiver SHOULD ignore the nameValue associated with any 209 unrecognized nameType in either the receiptsFrom field or the 210 receiptsTo field. 212 When the key-package-identifier-and-receipt-request attribute appears 213 in more than one location in the overall key package, each occurrence 214 is evaluated independently. That is, the receiver may generate more 215 than one receipt for a single key package. However the time at which 216 the receipts are sent will depend on policies that are beyond the 217 scope of this document. 219 4. Key Package Receipt CMS Content Type 221 The key package receipt content type is used to confirm receipt of an 222 identified key package or collection of key packages. This content 223 type MUST be Distinguished Encoding Rules (DER) encoded [X.690]. 225 The key package receipt content type has the following syntax: 227 ct-key-package-receipt CONTENT-TYPE ::= { 228 TYPE KeyPackageReceipt 229 IDENTIFIED BY id-ct-KP-keyPackageReceipt } 231 id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= { 232 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 233 smime(16) ct(1) TBD1 } 235 KeyPackageReceipt ::= SEQUENCE { 236 version KeyPkgVersion DEFAULT v2, 237 receiptOf KeyPkgIdentifier, 238 receivedBy SIREntityName } 240 -- Revised definition of KeyPkgVersion from [RFC6031] 241 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. MAX) 243 KeyPkgIdentifier ::= CHOICE { 244 pkgID KeyPkgID, 245 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 247 KeyPkgID ::= OCTET STRING 249 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 251 The KeyPackageReceipt fields are used as follows: 253 o version identifies version of the key package receipt content. 254 For this version of the specification, the default value, v2, 255 MUST be used. Note that v1 was defined in an earlier version, 256 but the use of v1 is deprecated. 258 o receiptOf offers two alternatives for identifying the key package 259 for which the receipt is being generated. The first alternative, 260 pkgID, MUST be supported, and pkgID provides the key package 261 identifier of the key package or collection of key packages for 262 which this receipt is being generated. This key package 263 identifier value MUST exactly match the key package identifier 264 value of the key-package-identifier-and-receipt-request attribute 265 in the received key package or collection. The key-package- 266 identifier-and-receipt-request attribute is described Section 3. 267 The second alternative allows alternate attributes to be used to 268 define the identifier. 270 o receivedBy identifies the entity that received the key package. 271 The entity is named by an SIR entity name as specified in section 272 2. 274 Key package receipts MUST be encapsulated in a CMS SignedData content 275 type to carry the signature of the entity that is confirming receipt 276 of the identified key package or collection of key packages. Key 277 package receipts MAY be encrypted by encapsulating them in the CMS 278 EncryptedData content type, the CMS EnvelopedData content type, or 279 the AuthEnvelopedData content type. When the key package receipt is 280 signed and encrypted, it MUST be signed prior to being encrypted. 282 Note that delivery assurance is the responsibility of the protocol 283 that is used to transport and track key packages. The key package 284 receipt content type can be used in conjunction with that protocol as 285 part of an overall delivery assurance solution. 287 Because the receipts are signed, all recipients that generate key 288 package receipts MUST have a private signature key to sign the 289 receipt as well as store their own certificate or have a means of 290 obtaining the key identifier of their public key. If memory is a 291 concern, the public key identifier can be computed from the public 292 key. 294 If the receipt signer has access to a real-time clock, then the 295 binary-signing-time [RFC6019] signed attribute SHOULD be included in 296 the key package receipt to provide the date and time when it was 297 generated. 299 5. Key Package Error CMS Content Type 301 The key package error content type provides an indication of the 302 reason for rejection of a key package or collection of key packages. 303 This content type MUST be Distinguished Encoding Rules (DER) encoded 304 [X.690]. 306 The key package error content type has the following syntax: 308 ct-key-package-error CONTENT-TYPE ::= { 309 TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError } 311 id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= { 312 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 313 smime(16) ct(1) TBD2 } 315 KeyPackageError ::= SEQUENCE { 316 version KeyPkgVersion DEFAULT v2, 317 errorOf [0] KeyPkgIdentifier OPTIONAL, 318 errorBy SIREntityName, 319 errorCode ErrorCodeChoice } 321 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. MAX) 322 KeyPkgIdentifier ::= CHOICE { 323 pkgID KeyPkgID, 324 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 326 KeyPkgID ::= OCTET STRING 328 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 330 ErrorCodeChoice ::= CHOICE { 331 enum EnumeratedErrorCode, 332 oid OBJECT IDENTIFIER } 334 EnumeratedErrorCode ::= ENUMERATED { 335 decodeFailure (1), 336 badContentInfo (2), 337 badSignedData (3), 338 badEncapContent (4), 339 badCertificate (5), 340 badSignerInfo (6), 341 badSignedAttrs (7), 342 badUnsignedAttrs (8), 343 missingContent (9), 344 noTrustAnchor (10), 345 notAuthorized (11), 346 badDigestAlgorithm (12), 347 badSignatureAlgorithm (13), 348 unsupportedKeySize (14), 349 unsupportedParameters (15), 350 signatureFailure (16), 351 insufficientMemory (17), 352 incorrectTarget (23), 353 missingSignature (29), 354 resourcesBusy (30), 355 versionNumberMismatch (31), 356 revokedCertificate (33), 358 -- Error codes above this point are aligned with [RFC5934] 360 ambiguousDecrypt (60), 361 noDecryptKey (61), 362 badEncryptedData (62), 363 badEnvelopedData (63), 364 badAuthenticatedData (64), 365 badAuthEnvelopedData (65), 366 badKeyAgreeRecipientInfo (66), 367 badKEKRecipientInfo (67), 368 badEncryptContent (68), 369 badEncryptAlgorithm (69), 370 missingCiphertext (70), 371 decryptFailure (71), 372 badMACAlgorithm (72), 373 badAuthAttrs (73), 374 badUnauthAttrs (74), 375 invalidMAC (75), 376 mismatchedDigestAlg (76), 377 missingCertificate (77), 378 tooManySigners (78), 379 missingSignedAttributes (79), 380 derEncodingNotUsed (80), 381 missingContentHints (81), 382 invalidAttributeLocation (82), 383 badMessageDigest (83), 384 badKeyPackage (84), 385 badAttributes (85), 386 attributeComparisonFailure (86), 387 unsupportedSymmetricKeyPackage (87), 388 unsupportedAsymmetricKeyPackage (88), 389 constraintViolation (89), 390 ambiguousDefaultValue (90), 391 noMatchingReceipientInfo (91), 392 unsupportedKeyWrapAlgorithm (92), 393 other (127), 394 ... -- Expect additional error codes -- } 396 The KeyPackageError fields are used as follows: 398 o version identifies version of the key package error content 399 structure. For this version of the specification, the default 400 value, v2, MUST be used. Note that v1 was defined in an earlier 401 version, but the use of v1 is deprecated. 403 o errorOf is OPTIONAL, and it provides the identifier of the keying 404 material for which this error is being generated. This is 405 omitted if the receiver or intermediary cannot parse the received 406 data to determine the package identifier. Also, encryption may 407 prevent an intermediary from obtaining any of the identifiers. 408 Two alternatives for identifying the keying material are 409 possible; see KeyPkgIdentifer as described in Section 4. The 410 value MUST exactly match the value of the key-package-identifier- 411 and-receipt-request attribute in the received key package or 412 collection. The key-package-identifier-and-receipt-request 413 attribute is described in Section 3. 415 o errorBy identifies the entity that received the key package. 416 The entity is named by an SIR entity name as specified in section 417 2. 419 o errorCode contains a code that indicates the reason for the 420 error. It contains either an enumerated error code from the list 421 below or an extended error code represented by an object 422 identifier. The enumerated error code alternative MUST be 423 supported. The object identifier error code MAY be supported. 425 * decodeFailure is used to indicate that the key package 426 intermediary or receiver was unable to successfully decode the 427 provided package. The specified content type and the provided 428 content do not match. 430 * badContentInfo is used to indicate that the ContentInfo syntax 431 is invalid or that the contentType carried within the 432 ContentInfo is unknown or unsupported. 434 * badSignedData is used to indicate that the SignedData syntax is 435 invalid, the version is unknown or unsupported, or more than 436 one entry is present in digestAlgorithms. 438 * badEncapContent is used to indicate that the 439 EncapsulatedContentInfo syntax is invalid within a SignedData 440 or an AuthenticatedData or the EncryptedContentInfo syntax is 441 invalid within an AuthEnvelopedData. 443 * badCertificate is used to indicate that the syntax for one or 444 more certificates in CertificateSet or elsewhere is invalid or 445 unsupported. 447 * badSignerInfo is used to indicate that the SignerInfo syntax is 448 invalid, or the version is unknown or unsupported. 450 * badSignedAttrs is used to indicate that the signedAttrs syntax 451 within SignerInfo is invalid. 453 * badUnsignedAttrs is used to indicate that the unsignedAttrs 454 within SignerInfo contains one or more attributes. Since 455 unrecognized attributes are ignored, this error code is used 456 when the object identifier for the attribute is recognized, but 457 the value is malformed or internally inconsistent. 459 * missingContent is used to indicate that the optional eContent 460 is missing in EncapsulatedContentInfo, which is required when 461 including an asymmetric, a symmetric key package, and an 462 encrypted key package. This error can be generated due to 463 problems located in SignedData or AuthenticatedData. 465 Note that CMS EncapsulatedContentInfo eContent field is 466 optional [RFC5652]; however, [RFC5958], [RFC6031], and 468 [RFC6032] require that the eContent be present. 470 * noTrustAnchor is used to indicate that the subjectKeyIdentifier 471 does not identify the public key of a trust anchor or a 472 certification path that terminates with an installed trust 473 anchor. 475 * notAuthorized is used to indicate that the sid within 476 SignerInfo leads to an installed trust anchor, but that trust 477 anchor is not an authorized signer for the received content 478 type. 480 * badDigestAlgorithm is used to indicate that the digestAlgorithm 481 in either SignerInfo, SignedData, or AuthenticatedData is 482 unknown or unsupported. 484 * badSignatureAlgorithm is used to indicate that the 485 signatureAlgorithm in SignerInfo is unknown or unsupported. 487 * unsupportedKeySize is used to indicate that the 488 signatureAlgorithm in SignerInfo is known and supported, but 489 the digital signature could not be validated because an 490 unsupported key size was employed by the signer. 491 Alternatively, the algorithm used in EnvelopedData, 492 AuthenticatedData, or AuthEnvelopedData to generate the key- 493 encryption key is known and supported, but an unsupported key 494 size was employed by the originator. 496 * unsupportedParameters is used to indicate that the 497 signatureAlgorithm in SignerInfo is known, but the digital 498 signature could not be validated because unsupported parameters 499 were employed by the signer. Alternatively, the algorithm used 500 in EnvelopedData, AuthenticatedData, or AuthEnvelopedData to 501 generate the key-encryption key is known and supported, but 502 unsupported parameters were employed by the originator. 504 * signatureFailure is used to indicate that the 505 signatureAlgorithm in SignerInfo is known and supported, but 506 the digital signature in the signature field within SignerInfo 507 could not be validated. 509 * insufficientMemory indicates that the key package could not be 510 processed because the intermediary or receiver did not have 511 sufficient memory to store the keying material. 513 * incorrectTarget indicates that a receiver is not the intended 514 recipient. 516 * missingSignature indicates that the receiver requires the key 517 package to be signed or authenticated with a Message 518 Authentication Check (MAC), but the received key package was 519 not signed or authenticated. 521 * resourcesBusy indicates that the resources necessary to process 522 the key package are not available at the present time, but the 523 resources might be available at some point in the future. 525 * versionNumberMismatch indicates that the version number in a 526 received key package is not acceptable. 528 * revokedCertificate indicates that one or more of the 529 certificates needed to properly process the key package has 530 been revoked. 532 * ambiguousDecrypt indicates that the EncryptedData content type 533 was used, and the key package receiver could not determine the 534 appropriate keying material to perform the decryption. 536 * noDecryptKey indicates that the receiver does not have the key 537 named in the content-decryption-key-identifier attribute. 539 * badEncryptedData indicates that the EncryptedData syntax is 540 invalid or the version is unknown or unsupported. 542 * badEnvelopedData indicates that the EnvelopedData syntax is 543 invalid or the version is unknown or unsupported. 545 * badAuthenticatedData indicates that the AuthenticatedData 546 syntax is invalid or the version is unknown or unsupported. 548 * badAuthEnvelopedData indicates that the AuthEnvelopedData 549 syntax is invalid or the version is unknown or unsupported. 551 * badKeyAgreeRecipientInfo indicates that the 552 KeyAgreeRecipientInfo syntax is invalid or the version is 553 unknown or unsupported. 555 * badKEKRecipientInfo indicates that the KEKRecipientInfo syntax 556 is invalid or the version is unknown or unsupported. 558 * badEncryptContent indicates that the EncryptedContentInfo 559 syntax is invalid, or that the content type carried within the 560 contentType is unknown or unsupported. 562 * badEncryptAlgorithm indicates that the encryption algorithm 563 identified by contentEncryptionAlgorithm in 564 EncryptedContentInfo is unknown or unsupported. This can 565 result from EncryptedData, EnvelopedData, or AuthEnvelopedData. 567 * missingCiphertext indicates that the optional encryptedContent 568 is missing in EncryptedContentInfo, which is required when 569 including an asymmetric, a symmetric key package, and an 570 encrypted key package. 572 * decryptFailure indicates that the encryptedContent in 573 EncryptedContentInfo did not decrypt properly. 575 * badMACAlgorithm indicates that the MAC algorithm identified by 576 MessageAuthenticationCodeAlgorithm in AuthenticatedData is 577 unknown or unsupported. 579 * badAuthAttrs is used to indicate that the authAttrs syntax 580 within AuthenticatedData or AuthEnvelopedData is invalid. 581 Since unrecognized attributes are ignored, this error code is 582 used when the object identifier for the attribute is 583 recognized, but the value is malformed or internally 584 inconsistent. 586 * badUnauthAttrs is used to indicate that the unauthAttrs syntax 587 within AuthenticatedData or AuthEnvelopedData is invalid. 588 Since unrecognized attributes are ignored, this error code is 589 used when the object identifier for the attribute is 590 recognized, but the value is malformed or internally 591 inconsistent. 593 * invalidMAC is used to indicate that the message authentication 594 code value within AuthenticatedData or AuthEnvelopedData did 595 not validate properly. 597 * mismatchedDigestAlg is used to indicate that the digest 598 algorithm in digestAlgorithms field within SignedData does not 599 match the digest algorithm used by the content signer. 601 * missingCertificate indicates that a signature could not be 602 verified using a trust anchor or a certificate from the 603 certificates field within SignedData. Similarly, this error 604 code can indicate that a needed certificate is missing when 605 processing EnvelopedData, AuthEnvelopedData, or 606 AuthenticatedData. 608 * tooManySigners indicates that a SignedData content contained 609 more than one SignerInfo. 611 * missingSignedAttributes indicates that a SignedInfo within a 612 SignedData content did not contain any signed attributes; at a 613 minimum, the content-type and message-digest must be present, 614 as per [RFC5652]. Similarly, this error code can indicate that 615 required authenticated attributes are missing when processing 616 AuthEnvelopedData or AuthenticatedData. 618 * derEncodingNotUsed indicates that the content contained BER 619 encoding, or some other encoding, where DER encoding was 620 required. 622 * missingContentHints indicates that a SignedData content 623 encapsulates a content other than a key package or an encrypted 624 key package; however, the content-hints attribute [RFC2634] is 625 not included. Similarly, this error code can indicate that the 626 content-hints attribute was missing when processing 627 AuthEnvelopedData or AuthenticatedData. 629 * invalidAttributeLocation indicates that an attribute appeared 630 in an unacceptable location. 632 * badMessageDigest indicates that the value of the message-digest 633 attribute [RFC5652] did not match the calculated value. 635 * badKeyPackage indicates that the SymmetricKeyPackage [RFC6031] 636 or AsymmetricKeyPackage [RFC5958] syntax is invalid or that the 637 version is unknown. 639 * badAttributes indicates that an attribute collection contained 640 either multiple instances of the same attribute type or 641 contained an attribute instance with multiple values. 643 * attributeComparisonFailure indicates that multiple instances of 644 an attribute failed the comparison rules for the type of 645 attribute. 647 * unsupportedSymmetricKeyPackage indicates that the 648 implementation is not prepared to process symmetric key 649 packages [RFC6031]. 651 * unsupportedAsymmetricKeyPackage indicates that the 652 implementation is not prepared to process asymmetric key 653 packages [RFC5958]. 655 * constraintViolation indicates that one or more of the 656 attributes has a value that is not in the authorized set of 657 values for the signer [RFC6010]. That is, the value is in 658 conflict with the constraints imposed on the signer. 660 * ambiguousDefaultValue indicates that one or more of the 661 attributes that is part of the signer's constraints is omitted 662 from the key package, and the constraint permits more than one 663 value, therefore the appropriate default value for that 664 attribute or attribute cannot be determined. 666 * noMatchingRecipientInfo indicates that a recipientInfo could 667 not be found for the recipient. This can result from a keri or 668 kari found in EncryptedData, EnvelopedData, or 669 AuthEnvelopedData. 671 * unsupportedKeyWrapAlgorithm indicates that the key wrap 672 algorithm is not supported. 674 * other indicates that the key package could not be processed, 675 but the reason is not covered by any of the assigned status 676 codes. Use of this status code SHOULD be avoided. 678 The key package error content type MUST be signed if the entity 679 generating it is capable of signing it. For example, a device will 680 be incapable of signing when it is in early stages of deployment and 681 it has not been configured with a private signing key or a device has 682 an internal error that prevents use of its private signing key. When 683 it is signed, the key package error MUST be encapsulated in a CMS 684 SignedData content type to carry the signature of the party that is 685 indicating an error. When it is encrypted, the key package error 686 MUST be encapsulated in a CMS EnvelopedData content type, a CMS 687 EncryptedData content type, or a CMS AuthEnvelopedData content type. 688 When a key package error is signed and encrypted, it MUST be signed 689 prior to being encrypted. 691 All devices that generate signed key package error reports MUST store 692 their own certificate or have a means of obtaining the key identifier 693 of their public key. If memory is a concern, the public key 694 identifier can be computed from the public key. 696 If the error report signer has access to a real-time clock, then the 697 binary-signing-time attribute [RFC6019] SHOULD be included in the key 698 package error to provide the date and time when it was generated. 700 6. Protecting the KeyPackageReceipt and KeyPackageError 702 CMS protecting content types, [RFC5652] and [RFC5083], can be used to 703 provide security to the KeyPackageReceipt and KeyPackageError content 704 types: 706 o SignedData can be used to apply a digital signature. 708 o EncryptedData can be used to encrypt the content type with simple 709 symmetric encryption, where the sender and the receiver already 710 share the necessary encryption key. 712 o EnvelopedData can be used to encrypt the content type with 713 symmetric encryption, where the sender and the receiver do not 714 already share the necessary encryption key. 716 o AuthEnvelopedData can be used to protect the content types with 717 algorithms that support authenticated encryption, where key 718 management information is handled in a manner similar to 719 EnvelopedData. 721 7. Security Considerations 723 The key package receipt and key package error contents are not 724 necessarily protected. These content types can be combined with a 725 security protocol to protect the contents of the package. 727 8. IANA Considerations 729 None. 731 {RFC Editor: Please remove this section before publication.} 733 9. Acknowledgements 735 TBD 737 10. References 739 10.1. Normative References 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, March 1997. 744 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 745 RFC 2634, June 1999. 747 [RFC4073] Housley, R., "Protecting Multiple Contents with the 748 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 750 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 751 Housley, R., and W. Polk, "Internet X.509 Public Key 752 Infrastructure Certificate and Certificate Revocation List 753 (CRL) Profile", RFC 5280, May 2008. 755 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 756 RFC 5652, September 2009. 758 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 759 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 760 June 2010. 762 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 763 2010. 765 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 766 Message Syntax (CMS) Content Constraints Extension", 767 RFC 6010, September 2010. 769 [RFC6019] Housley, R., "BinaryTime: An Alternate Format for 770 Representing Date and Time in ASN.1", RFC 6019, September 771 2010. 773 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 774 (CMS) Symmetric Key Package Content Type", RFC 6031, 775 December 2010. 777 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 778 (CMS) Encrypted Key Package Content Type", RFC 6032, 779 December 2010. 781 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 782 for the Cryptographic Message Syntax (CMS) and the Public 783 Key Infrastructure Using X.509 (PKIX)", RFC 6268, July 784 2011. 786 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 787 Information Technology - Abstract Syntax Notation One. 789 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 790 Information Technology - Abstract Syntax Notation One: 791 Information Object Specification. 793 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 794 Information Technology - Abstract Syntax Notation One: 795 Constraint Specification. 797 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 798 Information Technology - Abstract Syntax Notation One: 799 Parameterization of ASN.1 Specifications. 801 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 1:2002. 802 Information Technology - ASN.1 encoding rules: 803 Specification of Basic Encoding Rules (BER), Canonical 804 Encoding Rules (CER) and Distinguished Encoding Rules 805 (DER). 807 10.2. Informative References 809 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 810 Authenticated-Enveloped-Data Content Type", RFC 5083, 811 November 2007. 813 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 814 Management Protocol (TAMP)", RFC 5934, August 2010. 816 Appendix A: ASN.1 Module 818 This annex provides the normative ASN.1 definitions for the 819 structures described in this specification using ASN.1 as defined in 820 [X.680], [X.681], [X.682], and [X.683]. 822 KeyPackageReceiptAndErrorModuleV2 823 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 824 smime(16) modules(0) TBD3 } 826 -- TO DO: Get Three OID values assigned. 828 DEFINITIONS IMPLICIT TAGS ::= 830 BEGIN 832 -- EXPORTS ALL 834 IMPORTS 836 -- FROM New SMIME ASN.1 [RFC6268] 838 CONTENT-TYPE 839 FROM CryptographicMessageSyntax-2010 840 { iso(1) member-body(2) us(840) rsadsi(113549) 841 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 843 -- From New PKIX ASN.1 [RFC5912] 845 ATTRIBUTE, SingleAttribute {} 846 FROM PKIX-CommonTypes-2009 847 { iso(1) identified-organization(3) dod(6) internet(1) 848 security(5) mechanisms(5) pkix(7) id-mod(0) 849 id-mod-pkixCommon-02(57) } 850 ; 851 --- 852 --- Key Package Version Number (revised from [RFC6031]) 853 --- 855 KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. MAX) 857 -- 858 -- SIR Entity Name 859 -- 861 SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName 863 SIREntityName ::= SEQUENCE { 864 nameType OBJECT IDENTIFIER, 865 nameValue OCTET STRING } 867 id-dn OBJECT IDENTIFER ::= { 868 joint-iso-ccitt(2) country(16) us(840) organization(1) 869 gov(101) dod(2) infosec(1) sir-name-types(16) 0 } 871 -- 872 -- Attribute Definitions 873 -- 875 aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= { 876 TYPE KeyPkgIdentifierAndReceiptReq 877 IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq } 879 id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= { 880 joint-iso-itu-t(2) country(16) us(840) organization(1) 881 gov(101) dod(2) infosec(1) attributes(5) 65 } 883 KeyPkgIdentifierAndReceiptReq ::= SEQUENCE { 884 pkgID KeyPkgID, 885 receiptReq KeyPkgReceiptReq OPTIONAL } 887 KeyPkgID ::= OCTET STRING 889 KeyPkgReceiptReq ::= SEQUENCE { 890 encryptReceipt BOOLEAN DEFAULT FALSE, 891 receiptsFrom [0] SIREntityNames OPTIONAL, 892 receiptsTo SIREntityNames } 894 -- 895 -- Content Type Definitions 896 -- 898 KeyPackageContentTypes CONTENT-TYPE ::= { 899 ct-key-package-receipt | 900 ct-key-package-error, 901 ... -- Expect additional content types -- } 903 -- Key Package Receipt CMS Content Type 905 ct-key-package-receipt CONTENT-TYPE ::= { 906 TYPE KeyPackageReceipt 907 IDENTIFIED BY id-ct-KP-keyPackageReceipt } 909 id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= { 910 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 911 smime(16) ct(1) TBD1 } 913 KeyPackageReceipt ::= SEQUENCE { 914 version KeyPkgVersion DEFAULT v2, 915 receiptOf KeyPkgIdentifier, 916 receivedBy SIREntityName } 918 KeyPkgIdentifier ::= CHOICE { 919 pkgID KeyPkgID, 920 attribute SingleAttribute {{ KeyPkgIdentifiers }} } 922 KeyPkgIdentifiers ATTRIBUTE ::= { ... } 924 -- Key Package Receipt CMS Content Type 926 ct-key-package-error CONTENT-TYPE ::= { 927 TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError } 929 id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= { 930 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 931 smime(16) ct(1) TBD2 } 933 KeyPackageError ::= SEQUENCE { 934 version KeyPkgVersion DEFAULT v2, 935 errorOf [0] KeyPkgIdentifier OPTIONAL, 936 errorBy SIREntityName, 937 errorCode ErrorCodeChoice } 939 ErrorCodeChoice ::= CHOICE { 940 enum EnumeratedErrorCode, 941 oid OBJECT IDENTIFIER } 943 EnumeratedErrorCode ::= ENUMERATED { 944 decodeFailure (1), 945 badContentInfo (2), 946 badSignedData (3), 947 badEncapContent (4), 948 badCertificate (5), 949 badSignerInfo (6), 950 badSignedAttrs (7), 951 badUnsignedAttrs (8), 952 missingContent (9), 953 noTrustAnchor (10), 954 notAuthorized (11), 955 badDigestAlgorithm (12), 956 badSignatureAlgorithm (13), 957 unsupportedKeySize (14), 958 unsupportedParameters (15), 959 signatureFailure (16), 960 insufficientMemory (17), 961 incorrectTarget (23), 962 missingSignature (29), 963 resourcesBusy (30), 964 versionNumberMismatch (31), 965 revokedCertificate (33), 967 -- Error codes above this point are aligned with [RFC5934] 969 ambiguousDecrypt (60), 970 noDecryptKey (61), 971 badEncryptedData (62), 972 badEnvelopedData (63), 973 badAuthenticatedData (64), 974 badAuthEnvelopedData (65), 975 badKeyAgreeRecipientInfo (66), 976 badKEKRecipientInfo (67), 977 badEncryptContent (68), 978 badEncryptAlgorithm (69), 979 missingCiphertext (70), 980 decryptFailure (71), 981 badMACAlgorithm (72), 982 badAuthAttrs (73), 983 badUnauthAttrs (74), 984 invalidMAC (75), 985 mismatchedDigestAlg (76), 986 missingCertificate (77), 987 tooManySigners (78), 988 missingSignedAttributes (79), 989 derEncodingNotUsed (80), 990 missingContentHints (81), 991 invalidAttributeLocation (82), 992 badMessageDigest (83), 993 badKeyPackage (84), 994 badAttributes (85), 995 attributeComparisonFailure (86), 996 unsupportedSymmetricKeyPackage (87), 997 unsupportedAsymmetricKeyPackage (88), 998 constraintViolation (89), 999 ambiguousDefaultValue (90), 1000 noMatchingReceipientInfo (91), 1001 unsupportedKeyWrapAlgorithm (92), 1002 other (127), 1003 ... -- Expect additional error codes -- } 1005 END 1007 Author's Address 1009 Russ Housley 1010 Vigil Security, LLC 1011 918 Spring Knoll Drive 1012 Herndon, VA 20170 1013 USA 1015 EMail: housley@vigilsec.com