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