GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7191

Internet Engineering Task Force (IETF) R. Housley Request for Comments: 7191 Vigil Security Category: Standards Track April 2014 ISSN: 2070-1721

                 Cryptographic Message Syntax (CMS)
            Key Package Receipt and Error Content Types

Abstract

 This document defines the syntax for two Cryptographic Message Syntax
 (CMS) content types: one for key package receipts and another for key
 package errors.  The key package receipt content type is used to
 confirm receipt of an identified key package or collection of key
 packages.  The key package error content type is used to indicate an
 error occurred during the processing of a key package.  CMS can be
 used to digitally sign, digest, authenticate, or encrypt these
 content types.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7191.

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Housley Standards Track [Page 1] RFC 7191 Key Package Receipts and Errors April 2014

Table of Contents

 1. Introduction ....................................................2
    1.1. Requirements Terminology ...................................2
    1.2. ASN.1 Syntax Notation ......................................2
    1.3. Processing Key Package Receipt Requests ....................3
    1.4. Processing Key Packages with Errors ........................3
 2. SIR Entity Name .................................................3
 3. Key Package Identifier and Receipt Request Attribute ............4
 4. Key Package Receipt CMS Content Type ............................6
 5. Key Package Error CMS Content Type ..............................8
 6. Protecting the KeyPackageReceipt and KeyPackageError ...........17
 7. Using the application/cms Media Type ...........................17
 8. IANA Considerations ............................................17
 9. Security Considerations ........................................17
 10. Acknowledgements ..............................................18
 11. References ....................................................18
    11.1. Normative References .....................................18
    11.2. Informative References ...................................20
 Appendix A. ASN.1 Module ..........................................21

1. Introduction

 This document defines the syntax for two Cryptographic Message Syntax
 (CMS) [RFC5652] content types: one for key package receipts and
 another for key package errors.  The key package receipt content type
 is used to confirm receipt of an identified key package or collection
 of key packages.  The key package error content type is used to
 indicate an error occurred during the processing of a key package.
 CMS can be used to digitally sign, digest, authenticate, or encrypt
 these content types.

1.1. Requirements Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

1.2. ASN.1 Syntax Notation

 The content types defined herein use ASN.1 ([X.680], [X.681],
 [X.682], and [X.683]).
 The CONTENT-TYPE definition was updated to the 2008 version of ASN.1
 by [RFC6268]; however, none of the new 2008 ASN.1 tokens are used in
 this specification, which allows compilers that only support the 2002
 version of ASN.1 to compile the module in Appendix A.

Housley Standards Track [Page 2] RFC 7191 Key Package Receipts and Errors April 2014

1.3. Processing Key Package Receipt Requests

 The key package or collection of key packages [RFC4073] [RFC5958]
 [RFC6031] [RFC6032] for which the receipt is being generated MUST be
 signed, and the key package MUST include the key-package-identifier-
 and-receipt-request attribute specified in Section 3.

1.4. Processing Key Packages with Errors

 The key package or collection of key packages [RFC4073] [RFC5958]
 [RFC6031] [RFC6032] for which the error is being generated might be
 signed.  The key package can be identified by a key-package-
 identifier-and-receipt-request attribute specified in Section 3.

2. SIR Entity Name

 Within a key distribution system, the source, intermediary, and
 receiver entities are identified by a Source Intermediary Recipient
 (SIR) entity name.  The syntax for the SIR entity name does not
 impose any particular structure, and it accommodates straightforward
 registration of additional SIR entity name types.
 The inclusion of the nameType object identifier ensures that two
 identifiers of different types that happen to contain the same values
 are not interpreted as equivalent.  Additional SIR entity name types
 are expected to be registered that represent different granularities.
 For example, one SIR entity name type might represent the receiver
 organization, and at a finer granularity, another SIR entity name
 type might identify a specific device, perhaps using a manufacturer
 identifier and serial number.  The use of an object identifier avoids
 the need for a central registry of SIR entity name types.
 The nameValue is an OCTET STRING, which allows the canonical form of
 any name to be carried.  Two names of the same type are considered
 equal if the octet strings are the same length and contain the same
 string of octets.

Housley Standards Track [Page 3] RFC 7191 Key Package Receipts and Errors April 2014

 SIREntityNames and SIREntityName have the following syntax:
    SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName
    SIR-ENTITY-NAME ::= CLASS {
        &sIRENType OBJECT IDENTIFIER UNIQUE,
        &SIRENValue
        } WITH SYNTAX {
        SYNTAX &SIRENValue IDENTIFIED BY &sIRENType }
    SIREntityName ::= SEQUENCE {
        sirenType    SIR-ENTITY-NAME.&sIRENType({SIREntityNameTypes}),
        sirenValue   OCTET STRING (CONTAINING
                       SIR-ENTITY-NAME.&SIRENValue(
                         {SIREntityNameTypes}{@sirenType}) ) }
 This document defines one SIR entity name type: the DN type.  The DN
 type uses a nameType of id-dn and a nameValue of a Distinguished Name
 (DN).  The nameValue OCTET STRING carries an ASN.1 encoded Name as
 specified in [RFC5280].  Note that other documents may define
 additional types.
    SIREntityNameTypes SIR-ENTITY-NAME ::= {
        siren-dn,
        ... -- Expect additional SIR Entity Name types -- }
    siren-dn SIR-ENTITY-NAME ::= {
        SYNTAX DistinguishedName
        IDENTIFIED BY id-dn }
    id-dn OBJECT IDENTIFIER ::= {
        joint-iso-ccitt(2) country(16) us(840) organization(1)
        gov(101) dod(2) infosec(1) sir-name-types(16) 0 }

3. Key Package Identifier and Receipt Request Attribute

 The key-package-identifier-and-receipt-request attribute, as its name
 implies, allows the originator to identify the key package and,
 optionally, request receipts.  This attribute can appear as a signed,
 authenticated, and content attribute.  Signed attributes are carried
 in the CMS Signed-data content type described in Section 5 of
 [RFC5652].  Authenticated attributes are carried in the CMS
 Authenticated-data content type described in Section 9 of [RFC5652]
 or in the CMS Authenticated-enveloped-data content type described in
 Section 2 of [RFC5083].  Content attributes are carried in the
 Content-with-attributes content type described in Section 3 of
 [RFC4073].

Housley Standards Track [Page 4] RFC 7191 Key Package Receipts and Errors April 2014

 The key-package-identifier-and-receipt-request attribute has the
 following syntax:
   aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= {
       TYPE KeyPkgIdentifierAndReceiptReq
       IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq }
   id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1)
       gov(101) dod(2) infosec(1) attributes(5) 65 }
   KeyPkgIdentifierAndReceiptReq ::= SEQUENCE {
       pkgID       KeyPkgID,
       receiptReq  KeyPkgReceiptReq OPTIONAL }
   KeyPkgID ::= OCTET STRING
   KeyPkgReceiptReq ::= SEQUENCE {
       encryptReceipt     BOOLEAN DEFAULT FALSE,
       receiptsFrom   [0] SIREntityNames OPTIONAL,
       receiptsTo         SIREntityNames }
 Even though the ATTRIBUTE syntax is defined as a SET OF
 AttributeValue, a key-package-identifier-and-receipt-request
 attribute MUST have a single attribute value; zero or multiple
 instances of AttributeValue are not permitted.
 The fields in the key-package-identifier-and-receipt-request
 attribute have the following semantics:
    o pkgID contains an octet string, and this syntax does not impose
      any particular structure on the identifier.
    o receiptReq is OPTIONAL, and when it is present, it includes an
      encryption receipt flag, an OPTIONAL indication of which
      receivers should generate receipts, and an indication of where
      the receipts are to be sent.
  • The encryption receipt flag indicates whether the key package

originator wants the receipt to be encrypted. If the boolean

        is set, then the receipt SHOULD be encrypted.
  • The OPTIONAL ReceiptsFrom field provides an indication of

which receivers SHOULD generate receipts. When the

        ReceiptsFrom field is absent, all receivers of the key package
        are expected to return receipts.  When the ReceiptsFrom field
        is present, a list of SIR entity names indicates which
        receivers of the key package are requested to return receipts.

Housley Standards Track [Page 5] RFC 7191 Key Package Receipts and Errors April 2014

        In this case, the receiver SHOULD return a receipt only if
        their SIR entity name appears on the list.
  • The receipt request does not include any key management

information; however, the list of SIR entity names in the

        receiptsTo field can be used to select symmetric or asymmetric
        keying material for the receipt receivers.
 A receiver SHOULD ignore the nameValue associated with any
 unrecognized nameType in either the receiptsFrom field or the
 receiptsTo field.
 When the key-package-identifier-and-receipt-request attribute appears
 in more than one location in the overall key package, each occurrence
 is evaluated independently.  That is, the receiver may generate more
 than one receipt for a single key package.  However, the time at
 which the receipts are sent will depend on policies that are beyond
 the scope of this document.

4. Key Package Receipt CMS Content Type

 The key package receipt content type is used to confirm receipt of an
 identified key package or collection of key packages.  This content
 type MUST be encoded using the Distinguished Encoding Rules (DER)
 [X.690].
 The key package receipt content type has the following syntax:
   ct-key-package-receipt CONTENT-TYPE ::= {
       TYPE KeyPackageReceipt
       IDENTIFIED BY id-ct-KP-keyPackageReceipt }
   id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1)
       gov(101) dod(2) infosec(1) formats(2)
       key-package-content-types(78) 3 }
   KeyPackageReceipt ::= SEQUENCE {
       version          KeyPkgVersion DEFAULT v2,
       receiptOf        KeyPkgIdentifier,
       receivedBy       SIREntityName }
  1. - Revised definition of KeyPkgVersion from [RFC6031]

KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535)

   KeyPkgIdentifier ::= CHOICE {
       pkgID            KeyPkgID,
       attribute        SingleAttribute {{ KeyPkgIdentifiers }} }

Housley Standards Track [Page 6] RFC 7191 Key Package Receipts and Errors April 2014

   KeyPkgID ::= OCTET STRING
   KeyPkgIdentifiers ATTRIBUTE ::= { ... }
 The KeyPackageReceipt fields are used as follows:
    o version identifies version of the key package receipt content.
      For this version of the specification, the default value, v2,
      MUST be used.  Note that v1 was defined in an earlier version,
      but the use of v1 is deprecated.
    o receiptOf offers two alternatives for identifying the key
      package for which the receipt is being generated.  The first
      alternative, pkgID, MUST be supported, and pkgID provides the
      key package identifier of the key package or collection of key
      packages for which this receipt is being generated.  This key
      package identifier value MUST exactly match the key package
      identifier value of the key-package-identifier-and-receipt-
      request attribute in the received key package or collection.
      The key-package-identifier-and-receipt-request attribute is
      described Section 3.  The second alternative allows alternate
      attributes to be used to define the identifier.
    o receivedBy identifies the entity that received the key package.
      The entity is named by an SIR entity name as specified in
      Section 2.
 Key package receipts MUST be encapsulated in a CMS SignedData content
 type to carry the signature of the entity that is confirming receipt
 of the identified key package or collection of key packages.  Key
 package receipts MAY be encrypted by encapsulating them in the CMS
 EncryptedData content type, the CMS EnvelopedData content type, or
 the AuthEnvelopedData content type.  When the key package receipt is
 signed and encrypted, it MUST be signed prior to being encrypted.
 Note that delivery assurance is the responsibility of the protocol
 that is used to transport and track key packages.  The key package
 receipt content type can be used in conjunction with that protocol as
 part of an overall delivery assurance solution.
 Because the receipts are signed, all recipients that generate key
 package receipts MUST have a private signature key to sign the
 receipt as well as store their own certificate or have a means of
 obtaining the key identifier of their public key.  If memory is a
 concern, the public key identifier can be computed from the public
 key.

Housley Standards Track [Page 7] RFC 7191 Key Package Receipts and Errors April 2014

 If the receipt signer has access to a real-time clock, then the
 binary-signing-time [RFC6019] signed attribute SHOULD be included in
 the key package receipt to provide the date and time when it was
 generated.

5. Key Package Error CMS Content Type

 The key package error content type provides an indication of the
 reason for rejection of a key package or collection of key packages.
 This content type MUST be encoded using the Distinguished Encoding
 Rules (DER) [X.690].
 The key package error content type has the following syntax:
   ct-key-package-error CONTENT-TYPE ::= {
       TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError }
   id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1)
       gov(101) dod(2) infosec(1) formats(2)
       key-package-content-types(78) 6 }
   KeyPackageError ::= SEQUENCE {
       version        KeyPkgVersion DEFAULT v2,
       errorOf    [0] KeyPkgIdentifier OPTIONAL,
       errorBy        SIREntityName,
       errorCode      ErrorCodeChoice }
   KeyPkgVersion ::= INTEGER  { v1(1), v2(2) } (1 .. 65535)
   KeyPkgIdentifier ::= CHOICE {
       pkgID            KeyPkgID,
       attribute        SingleAttribute {{ KeyPkgIdentifiers }} }
   KeyPkgID ::= OCTET STRING
   KeyPkgIdentifiers ATTRIBUTE ::= { ... }
   ErrorCodeChoice ::= CHOICE {
       enum           EnumeratedErrorCode,
       oid            OBJECT IDENTIFIER }
   EnumeratedErrorCode ::= ENUMERATED {
       decodeFailure                     (1),
       badContentInfo                    (2),
       badSignedData                     (3),
       badEncapContent                   (4),
       badCertificate                    (5),

Housley Standards Track [Page 8] RFC 7191 Key Package Receipts and Errors April 2014

       badSignerInfo                     (6),
       badSignedAttrs                    (7),
       badUnsignedAttrs                  (8),
       missingContent                    (9),
       noTrustAnchor                    (10),
       notAuthorized                    (11),
       badDigestAlgorithm               (12),
       badSignatureAlgorithm            (13),
       unsupportedKeySize               (14),
       unsupportedParameters            (15),
       signatureFailure                 (16),
       insufficientMemory               (17),
       incorrectTarget                  (23),
       missingSignature                 (29),
       resourcesBusy                    (30),
       versionNumberMismatch            (31),
       revokedCertificate               (33),
  1. - Error codes with values ⇐ 33 are aligned with [RFC5934]
       ambiguousDecrypt                 (60),
       noDecryptKey                     (61),
       badEncryptedData                 (62),
       badEnvelopedData                 (63),
       badAuthenticatedData             (64),
       badAuthEnvelopedData             (65),
       badKeyAgreeRecipientInfo         (66),
       badKEKRecipientInfo              (67),
       badEncryptContent                (68),
       badEncryptAlgorithm              (69),
       missingCiphertext                (70),
       decryptFailure                   (71),
       badMACAlgorithm                  (72),
       badAuthAttrs                     (73),
       badUnauthAttrs                   (74),
       invalidMAC                       (75),
       mismatchedDigestAlg              (76),
       missingCertificate               (77),
       tooManySigners                   (78),
       missingSignedAttributes          (79),
       derEncodingNotUsed               (80),
       missingContentHints              (81),
       invalidAttributeLocation         (82),
       badMessageDigest                 (83),
       badKeyPackage                    (84),
       badAttributes                    (85),
       attributeComparisonFailure       (86),
       unsupportedSymmetricKeyPackage   (87),

Housley Standards Track [Page 9] RFC 7191 Key Package Receipts and Errors April 2014

       unsupportedAsymmetricKeyPackage  (88),
       constraintViolation              (89),
       ambiguousDefaultValue            (90),
       noMatchingRecipientInfo          (91),
       unsupportedKeyWrapAlgorithm      (92),
       badKeyTransRecipientInfo         (93),
       other                           (127),
       ... -- Expect additional error codes  -- }
 The KeyPackageError fields are used as follows:
    o version identifies version of the key package error content
      structure.  For this version of the specification, the default
      value, v2, MUST be used.  Note that v1 was defined in an earlier
      version, but the use of v1 is deprecated.
    o errorOf is OPTIONAL, and it provides the identifier of the
      keying material for which this error is being generated.  This
      is omitted if the receiver or intermediary cannot parse the
      received data to determine the package identifier.  Also,
      encryption may prevent an intermediary from obtaining any of the
      identifiers.  Two alternatives for identifying the keying
      material are possible; see KeyPkgIdentifier as described in
      Section 4.  The value MUST exactly match the value of the key-
      package-identifier-and-receipt-request attribute in the received
      key package or collection.  The key-package-identifier-and-
      receipt-request attribute is described in Section 3.
    o errorBy identifies the entity that received the key package.
      The entity is named by an SIR entity name as specified in
      Section 2.
    o errorCode contains a code that indicates the reason for the
      error.  It contains either an enumerated error code from the
      list below or an extended error code represented by an object
      identifier.  The enumerated error code alternative MUST be
      supported.  The object identifier error code MAY be supported.
  • decodeFailure is used to indicate that the key package

intermediary or receiver was unable to successfully decode

          the provided package.  The specified content type and the
          provided content do not match.
  • badContentInfo is used to indicate that the ContentInfo

syntax is invalid or that the contentType carried within the

          ContentInfo is unknown or unsupported.

Housley Standards Track [Page 10] RFC 7191 Key Package Receipts and Errors April 2014

  • badSignedData is used to indicate that the SignedData syntax

is invalid, the version is unknown or unsupported, or more

          than one entry is present in digestAlgorithms.
  • badEncapContent is used to indicate that the

EncapsulatedContentInfo syntax is invalid within a

          SignedData or an AuthenticatedData or the
          EncryptedContentInfo syntax is invalid within an
          AuthEnvelopedData.
  • badCertificate is used to indicate that the syntax for one

or more certificates in CertificateSet or elsewhere is

          invalid or unsupported.
  • badSignerInfo is used to indicate that the SignerInfo syntax

is invalid or the version is unknown or unsupported.

  • badSignedAttrs is used to indicate that the signedAttrs

syntax within SignerInfo is invalid.

  • badUnsignedAttrs is used to indicate that the unsignedAttrs

within SignerInfo contains one or more attributes. Since

          unrecognized attributes are ignored, this error code is used
          when the object identifier for the attribute is recognized,
          but the value is malformed or internally inconsistent.  In
          addition, this error code can be used when policy prohibits
          an implementation from supporting unsigned attributes.
  • missingContent is used to indicate that the optional

eContent is missing in EncapsulatedContentInfo, which is

          required when including an asymmetric key package, a
          symmetric key package, and an encrypted key package.  This
          error can be generated due to problems located in SignedData
          or AuthenticatedData.
          Note that CMS EncapsulatedContentInfo eContent field is
          optional [RFC5652]; however, [RFC5958], [RFC6031], and
          [RFC6032] require that the eContent be present.
  • noTrustAnchor is used to indicate that the

subjectKeyIdentifier does not identify the public key of a

          trust anchor or a certification path that terminates with an
          installed trust anchor.
  • notAuthorized is used to indicate that the sid within

SignerInfo leads to an installed trust anchor, but that

          trust anchor is not an authorized signer for the received
          content type.

Housley Standards Track [Page 11] RFC 7191 Key Package Receipts and Errors April 2014

  • badDigestAlgorithm is used to indicate that the

digestAlgorithm in either SignerInfo, SignedData, or

          AuthenticatedData is unknown or unsupported.
  • badSignatureAlgorithm is used to indicate that the

signatureAlgorithm in SignerInfo is unknown or unsupported.

  • unsupportedKeySize is used to indicate that the

signatureAlgorithm in SignerInfo is known and supported, but

          the digital signature could not be validated because an
          unsupported key size was employed by the signer.
          Alternatively, the algorithm used in EnvelopedData,
          AuthenticatedData, or AuthEnvelopedData to generate the key-
          encryption key is known and supported, but an unsupported
          key size was employed by the originator.
  • unsupportedParameters is used to indicate that the

signatureAlgorithm in SignerInfo is known, but the digital

          signature could not be validated because unsupported
          parameters were employed by the signer.  Alternatively, the
          algorithm used in EnvelopedData, AuthenticatedData, or
          AuthEnvelopedData to generate the key-encryption key is
          known and supported, but unsupported parameters were
          employed by the originator.
  • signatureFailure is used to indicate that the

signatureAlgorithm in SignerInfo is known and supported, but

          the digital signature in the signature field within
          SignerInfo could not be validated.
  • insufficientMemory indicates that the key package could not

be processed because the intermediary or receiver did not

          have sufficient memory to store the keying material.
  • incorrectTarget indicates that a receiver is not the

intended recipient.

  • missingSignature indicates that the receiver requires the

key package to be signed or authenticated with a Message

          Authentication Code (MAC), but the received key package was
          not signed or authenticated.
  • resourcesBusy indicates that the resources necessary to

process the key package are not available at the present

          time, but the resources might be available at some point in
          the future.

Housley Standards Track [Page 12] RFC 7191 Key Package Receipts and Errors April 2014

  • versionNumberMismatch indicates that the version number in a

received key package is not acceptable.

  • revokedCertificate indicates that one or more of the

certificates needed to properly process the key package has

          been revoked.
  • ambiguousDecrypt indicates that the EncryptedData content

type was used, and the key package receiver could not

          determine the appropriate keying material to perform the
          decryption.
  • noDecryptKey indicates that the receiver does not have the

key named in the content-decryption-key-identifier attribute

          (see [RFC6032]).
  • badEncryptedData indicates that the EncryptedData syntax is

invalid or the version is unknown or unsupported.

  • badEnvelopedData indicates that the EnvelopedData syntax is

invalid or the version is unknown or unsupported.

  • badAuthenticatedData indicates that the AuthenticatedData

syntax is invalid or the version is unknown or unsupported.

  • badAuthEnvelopedData indicates that the AuthEnvelopedData

syntax is invalid or the version is unknown or unsupported.

  • badKeyAgreeRecipientInfo indicates that the

KeyAgreeRecipientInfo syntax is invalid or the version is

          unknown or unsupported.
  • badKEKRecipientInfo indicates that the KEKRecipientInfo

syntax is invalid or the version is unknown or unsupported.

  • badEncryptContent indicates that the EncryptedContentInfo

syntax is invalid, or that the content type carried within

          the contentType is unknown or unsupported.
  • badEncryptAlgorithm indicates that the encryption algorithm

identified by contentEncryptionAlgorithm in

          EncryptedContentInfo is unknown or unsupported.  This can
          result from EncryptedData, EnvelopedData, or
          AuthEnvelopedData.

Housley Standards Track [Page 13] RFC 7191 Key Package Receipts and Errors April 2014

  • missingCiphertext indicates that the optional

encryptedContent is missing in EncryptedContentInfo, which

          is required when including an asymmetric key package, a
          symmetric key package, and an encrypted key package.
  • decryptFailure indicates that the encryptedContent in

EncryptedContentInfo did not decrypt properly.

  • badMACAlgorithm indicates that the MAC algorithm identified

by MessageAuthenticationCodeAlgorithm in AuthenticatedData

          is unknown or unsupported.
  • badAuthAttrs is used to indicate that the authAttrs syntax

within AuthenticatedData or AuthEnvelopedData is invalid.

          Since unrecognized attributes are ignored, this error code
          is used when the object identifier for the attribute is
          recognized, but the value is malformed or internally
          inconsistent.
  • badUnauthAttrs is used to indicate that the unauthAttrs

syntax within AuthenticatedData or AuthEnvelopedData is

          invalid.  Since unrecognized attributes are ignored, this
          error code is used when the object identifier for the
          attribute is recognized, but the value is malformed or
          internally inconsistent.
  • invalidMAC is used to indicate that the message

authentication code value within AuthenticatedData or

          AuthEnvelopedData did not validate properly.
  • mismatchedDigestAlg is used to indicate that the digest

algorithm in digestAlgorithms field within SignedData does

          not match the digest algorithm used in the signature
          algorithm.
  • missingCertificate indicates that a signature could not be

verified using a trust anchor or a certificate from the

          certificates field within SignedData.  Similarly, this error
          code can indicate that a needed certificate is missing when
          processing EnvelopedData, AuthEnvelopedData, or
          AuthenticatedData.
  • tooManySigners indicates that a SignedData content contained

more than one SignerInfo for a content type that requires

          only one signer.

Housley Standards Track [Page 14] RFC 7191 Key Package Receipts and Errors April 2014

  • missingSignedAttributes indicates that a SignedInfo within a

SignedData content did not contain any signed attributes; at

          a minimum, the content-type and message-digest must be
          present, as per [RFC5652].  Similarly, this error code can
          indicate that required authenticated attributes are missing
          when processing AuthEnvelopedData or AuthenticatedData.
  • derEncodingNotUsed indicates that the content contained BER

encoding, or some other encoding, where DER encoding was

          required.
  • missingContentHints indicates that a SignedData content

encapsulates a content other than a key package or an

          encrypted key package; however, the content-hints attribute
          [RFC2634] is not included.  Similarly, this error code can
          indicate that the content-hints attribute was missing when
          processing AuthEnvelopedData or AuthenticatedData.
  • invalidAttributeLocation indicates that an attribute

appeared in an unacceptable location.

  • badMessageDigest indicates that the value of the message-

digest attribute [RFC5652] did not match the calculated

          value.
  • badKeyPackage indicates that the SymmetricKeyPackage

[RFC6031] or AsymmetricKeyPackage [RFC5958] syntax is

          invalid or that the version is unknown.
  • badAttributes indicates that an attribute collection either

contained multiple instances of the same attribute type that

          allows only one instance or contained an attribute instance
          with multiple values in an attribute that allows only one
          value.
  • attributeComparisonFailure indicates that multiple instances

of an attribute failed the comparison rules for the type of

          attribute.
  • unsupportedSymmetricKeyPackage indicates that the

implementation does not support symmetric key packages

          [RFC6031].
  • unsupportedAsymmetricKeyPackage indicates that the

implementation does not support asymmetric key packages

          [RFC5958].

Housley Standards Track [Page 15] RFC 7191 Key Package Receipts and Errors April 2014

  • constraintViolation indicates that one or more of the

attributes has a value that is not in the authorized set of

          values for the signer [RFC6010].  That is, the value is in
          conflict with the constraints imposed on the signer.
  • ambiguousDefaultValue indicates that one or more of the

attributes that is part of the signer's constraints is

          omitted from the key package, and the constraint permits
          more than one value; therefore, the appropriate default
          value for that attribute or attribute cannot be determined.
  • noMatchingRecipientInfo indicates that a recipientInfo could

not be found for the recipient. This can result from a ktri

          or kari found in EncryptedData, EnvelopedData, or
          AuthEnvelopedData.
  • unsupportedKeyWrapAlgorithm indicates that the key wrap

algorithm is not supported.

  • badKeyTransRecipientInfo indicates that the

KeyTransRecipientInfo syntax is invalid or the version is

          unknown or unsupported.
  • other indicates that the key package could not be processed,

but the reason is not covered by any of the assigned status

          codes.  Use of this status code SHOULD be avoided.
 The key package error content type MUST be signed if the entity
 generating it is capable of signing it.  For example, a device will
 be incapable of signing when it is in early stages of deployment and
 it has not been configured with a private signing key or a device has
 an internal error that prevents use of its private signing key.  When
 it is signed, the key package error MUST be encapsulated in a CMS
 SignedData content type to carry the signature of the party that is
 indicating an error.  When it is encrypted, the key package error
 MUST be encapsulated in a CMS EnvelopedData content type, a CMS
 EncryptedData content type, or a CMS AuthEnvelopedData content type.
 When a key package error is signed and encrypted, it MUST be signed
 prior to being encrypted.
 All devices that generate signed key package error reports MUST store
 their own certificate or have a means of obtaining the key identifier
 of their public key.  If memory is a concern, the public key
 identifier can be computed from the public key.
 If the error report signer has access to a real-time clock, then the
 binary-signing-time attribute [RFC6019] SHOULD be included in the key
 package error to provide the date and time when it was generated.

Housley Standards Track [Page 16] RFC 7191 Key Package Receipts and Errors April 2014

6. Protecting the KeyPackageReceipt and KeyPackageError

 CMS protecting content types, [RFC5652] and [RFC5083], can be used to
 provide security to the KeyPackageReceipt and KeyPackageError content
 types:
    o SignedData can be used to apply a digital signature.
    o EncryptedData can be used to encrypt the content type with
      simple symmetric encryption, where the sender and the receiver
      already share the necessary encryption key.
    o EnvelopedData can be used to encrypt the content type with
      symmetric encryption, where the sender and the receiver do not
      already share the necessary encryption key.
    o AuthenticatedData can be used to integrity protect the content
      type with message authentication algorithms that support
      authenticated encryption, where key management information is
      handled in a manner similar to EnvelopedData.
    o AuthEnvelopedData can be used to protect the content types with
      algorithms that support authenticated encryption, where key
      management information is handled in a manner similar to
      EnvelopedData.

7. Using the application/cms Media Type

 The media type and parameters for carrying a key package receipt or a
 key package error content type are specified in [RFC7193].

8. IANA Considerations

 IANA has updated the reference for the following registration in the
 "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)"
 registry:
    63  id-mod-keyPkgReceiptAndErrV2  [RFC7191]

9. Security Considerations

 The key package receipt and key package error contents are not
 necessarily protected.  These content types can be combined with a
 security protocol to protect the contents of the package.
 The KeyPkgReceiptReq structure includes a receiptsFrom list and a
 receiptsTo list.  Both lists contain SIREntityNames.  The syntax does
 not specify a limit on the number of SIREntityNames that may be

Housley Standards Track [Page 17] RFC 7191 Key Package Receipts and Errors April 2014

 included in either of these lists.  In addition, there is
 purposefully no requirement that the receiptTo entries have any
 relation to the sender of the key package.  To avoid these features
 being used as part of a denial-of-service amplification, receipts
 should only be returned for key packages with a valid signature from
 a trusted signer.
 If an implementation is willing to accept key packages from more than
 one source, then there is a possibility that the same key package
 identifier could be used by more than one source.  As a result, there
 is the potential for a receipt for one key package to be confused
 with the receipt for another, potentially leading to confusion about
 the keying material that is available to the recipient.  In
 environments with multiple key sources, a convention for assignment
 of key package identifiers can avoid this potential confusion
 altogether.
 In some situations, returning very detailed error information can
 provide an attacker with insight into the security processing.  Where
 this is a concern, the implementation should return the most generic
 error code that is appropriate.  However, detailed error codes are
 very helpful during development, debugging, and interoperability
 testing.  For this reason, implementations may want to have a way to
 configure the use of a generic error code or a detailed one.

10. Acknowledgements

 Many thanks to Radia Perlman, Sean Turner, Jim Schaad, and Carl
 Wallace for their insightful review.  Thanks to Robert Sparks for
 improved wording.

11. References

11.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2634]  Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
            RFC 2634, June 1999.
 [RFC4073]  Housley, R., "Protecting Multiple Contents with the
            Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.
 [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
            Housley, R., and W. Polk, "Internet X.509 Public Key
            Infrastructure Certificate and Certificate Revocation List
            (CRL) Profile", RFC 5280, May 2008.

Housley Standards Track [Page 18] RFC 7191 Key Package Receipts and Errors April 2014

 [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
            RFC 5652, September 2009.
 [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
            Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
            June 2010.
 [RFC5958]  Turner, S., "Asymmetric Key Packages", RFC 5958, August
            2010.
 [RFC6010]  Housley, R., Ashmore, S., and C. Wallace, "Cryptographic
            Message Syntax (CMS) Content Constraints Extension", RFC
            6010, September 2010.
 [RFC6019]  Housley, R., "BinaryTime: An Alternate Format for
            Representing Date and Time in ASN.1", RFC 6019, September
            2010.
 [RFC6031]  Turner, S. and R. Housley, "Cryptographic Message Syntax
            (CMS) Symmetric Key Package Content Type", RFC 6031,
            December 2010.
 [RFC6032]  Turner, S. and R. Housley, "Cryptographic Message Syntax
            (CMS) Encrypted Key Package Content Type", RFC 6032,
            December 2010.
 [RFC6268]  Schaad, J. and S. Turner, "Additional New ASN.1 Modules
            for the Cryptographic Message Syntax (CMS) and the Public
            Key Infrastructure Using X.509 (PKIX)", RFC 6268, July
            2011.
 [RFC7193]  Turner, S., Housley, R., and J. Schaad, "The
            application/cms Media Type", RFC 7193, April 2014.
 [X.680]    ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.
            Information Technology - Abstract Syntax Notation One.
 [X.681]    ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002.
            Information Technology - Abstract Syntax Notation One:
            Information Object Specification.
 [X.682]    ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002.
            Information Technology - Abstract Syntax Notation One:
            Constraint Specification.
 [X.683]    ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002.
            Information Technology - Abstract Syntax Notation One:
            Parameterization of ASN.1 Specifications.

Housley Standards Track [Page 19] RFC 7191 Key Package Receipts and Errors April 2014

 [X.690]    ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 1:2002.
            Information Technology - ASN.1 encoding rules:
            Specification of Basic Encoding Rules (BER), Canonical
            Encoding Rules (CER) and Distinguished Encoding Rules
            (DER).

11.2. Informative References

 [RFC5083]  Housley, R., "Cryptographic Message Syntax (CMS)
            Authenticated-Enveloped-Data Content Type", RFC 5083,
            November 2007.
 [RFC5934]  Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
            Management Protocol (TAMP)", RFC 5934, August 2010.

Housley Standards Track [Page 20] RFC 7191 Key Package Receipts and Errors April 2014

Appendix A. ASN.1 Module

 This annex provides the normative ASN.1 definitions for the
 structures described in this specification using ASN.1 as defined in
 [X.680], [X.681], [X.682], and [X.683].
 KeyPackageReceiptAndErrorModuleV2
   { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) modules(0) id-mod-keyPkgReceiptAndErrV2(63) }
 DEFINITIONS IMPLICIT TAGS ::=
 BEGIN
  1. - EXPORTS ALL
 IMPORTS
  1. - FROM New SMIME ASN.1 [RFC6268]
 CONTENT-TYPE
   FROM CryptographicMessageSyntax-2010
     { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
  1. - From New PKIX ASN.1 [RFC5912]
 ATTRIBUTE, SingleAttribute {}
   FROM PKIX-CommonTypes-2009
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-pkixCommon-02(57) }
 DistinguishedName
   FROM PKIX1Explicit-2009
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-pkix1-explicit-02(51)}
 ;
  1. – Key Package Version Number (revised from [RFC6031])
 KeyPkgVersion ::= INTEGER  { v1(1), v2(2) } (1 .. 65535)

Housley Standards Track [Page 21] RFC 7191 Key Package Receipts and Errors April 2014

  1. -
  2. - SIR Entity Name
  3. -
 SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName
 SIREntityNameTypes SIR-ENTITY-NAME ::= {
     siren-dn,
     ... -- Expect additional SIR Entity Name types -- }
 SIR-ENTITY-NAME ::= CLASS {
     &sIRENType OBJECT IDENTIFIER UNIQUE,
     &SIRENValue
     } WITH SYNTAX {
     SYNTAX &SIRENValue IDENTIFIED BY &sIRENType }
 SIREntityName ::= SEQUENCE {
     sirenType      SIR-ENTITY-NAME.&sIRENType({SIREntityNameTypes}),
     sirenValue     OCTET STRING (CONTAINING
                      SIR-ENTITY-NAME.&SIRENValue(
                        {SIREntityNameTypes}{@sirenType}) ) }
 siren-dn SIR-ENTITY-NAME ::= {
     SYNTAX DistinguishedName
     IDENTIFIED BY id-dn }
 id-dn OBJECT IDENTIFIER ::= {
     joint-iso-ccitt(2) country(16) us(840) organization(1)
     gov(101) dod(2) infosec(1) sir-name-types(16) 0 }
  1. -
  2. - Attribute Definitions
  3. -
 aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= {
     TYPE KeyPkgIdentifierAndReceiptReq
     IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq }
 id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= {
     joint-iso-itu-t(2) country(16) us(840) organization(1)
     gov(101) dod(2) infosec(1) attributes(5) 65 }
 KeyPkgIdentifierAndReceiptReq ::= SEQUENCE {
     pkgID       KeyPkgID,
     receiptReq  KeyPkgReceiptReq OPTIONAL }
 KeyPkgID ::= OCTET STRING

Housley Standards Track [Page 22] RFC 7191 Key Package Receipts and Errors April 2014

 KeyPkgReceiptReq ::= SEQUENCE {
     encryptReceipt     BOOLEAN DEFAULT FALSE,
     receiptsFrom   [0] SIREntityNames OPTIONAL,
     receiptsTo         SIREntityNames }
  1. -
  2. - Content Type Definitions
  3. -
 KeyPackageContentTypes CONTENT-TYPE ::= {
   ct-key-package-receipt |
   ct-key-package-error,
   ... -- Expect additional content types -- }
  1. - Key Package Receipt CMS Content Type
 ct-key-package-receipt CONTENT-TYPE ::= {
     TYPE KeyPackageReceipt
     IDENTIFIED BY id-ct-KP-keyPackageReceipt }
 id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= {
     joint-iso-itu-t(2) country(16) us(840) organization(1)
     gov(101) dod(2) infosec(1) formats(2)
     key-package-content-types(78) 3 }
 KeyPackageReceipt ::= SEQUENCE {
     version          KeyPkgVersion DEFAULT v2,
     receiptOf        KeyPkgIdentifier,
     receivedBy       SIREntityName }
 KeyPkgIdentifier ::= CHOICE {
     pkgID            KeyPkgID,
     attribute        SingleAttribute {{ KeyPkgIdentifiers }} }
 KeyPkgIdentifiers ATTRIBUTE ::= { ... }
  1. - Key Package Receipt CMS Content Type
 ct-key-package-error CONTENT-TYPE ::= {
     TYPE KeyPackageError IDENTIFIED BY id-ct-KP-keyPackageError }
 id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= {
     joint-iso-itu-t(2) country(16) us(840) organization(1)
     gov(101) dod(2) infosec(1) formats(2)
     key-package-content-types(78) 6 }

Housley Standards Track [Page 23] RFC 7191 Key Package Receipts and Errors April 2014

 KeyPackageError ::= SEQUENCE {
     version        KeyPkgVersion DEFAULT v2,
     errorOf    [0] KeyPkgIdentifier OPTIONAL,
     errorBy        SIREntityName,
     errorCode      ErrorCodeChoice }
 ErrorCodeChoice ::= CHOICE {
     enum           EnumeratedErrorCode,
     oid            OBJECT IDENTIFIER }
 EnumeratedErrorCode ::= ENUMERATED {
     decodeFailure                     (1),
     badContentInfo                    (2),
     badSignedData                     (3),
     badEncapContent                   (4),
     badCertificate                    (5),
     badSignerInfo                     (6),
     badSignedAttrs                    (7),
     badUnsignedAttrs                  (8),
     missingContent                    (9),
     noTrustAnchor                    (10),
     notAuthorized                    (11),
     badDigestAlgorithm               (12),
     badSignatureAlgorithm            (13),
     unsupportedKeySize               (14),
     unsupportedParameters            (15),
     signatureFailure                 (16),
     insufficientMemory               (17),
     incorrectTarget                  (23),
     missingSignature                 (29),
     resourcesBusy                    (30),
     versionNumberMismatch            (31),
     revokedCertificate               (33),
  1. - Error codes with values ⇐ 33 are aligned with [RFC5934]
     ambiguousDecrypt                 (60),
     noDecryptKey                     (61),
     badEncryptedData                 (62),
     badEnvelopedData                 (63),
     badAuthenticatedData             (64),
     badAuthEnvelopedData             (65),
     badKeyAgreeRecipientInfo         (66),
     badKEKRecipientInfo              (67),
     badEncryptContent                (68),
     badEncryptAlgorithm              (69),
     missingCiphertext                (70),
     decryptFailure                   (71),

Housley Standards Track [Page 24] RFC 7191 Key Package Receipts and Errors April 2014

     badMACAlgorithm                  (72),
     badAuthAttrs                     (73),
     badUnauthAttrs                   (74),
     invalidMAC                       (75),
     mismatchedDigestAlg              (76),
     missingCertificate               (77),
     tooManySigners                   (78),
     missingSignedAttributes          (79),
     derEncodingNotUsed               (80),
     missingContentHints              (81),
     invalidAttributeLocation         (82),
     badMessageDigest                 (83),
     badKeyPackage                    (84),
     badAttributes                    (85),
     attributeComparisonFailure       (86),
     unsupportedSymmetricKeyPackage   (87),
     unsupportedAsymmetricKeyPackage  (88),
     constraintViolation              (89),
     ambiguousDefaultValue            (90),
     noMatchingRecipientInfo          (91),
     unsupportedKeyWrapAlgorithm      (92),
     badKeyTransRecipientInfo         (93),
     other                           (127),
     ... -- Expect additional error codes  -- }
 END

Author's Address

 Russ Housley
 Vigil Security, LLC
 918 Spring Knoll Drive
 Herndon, VA 20170
 USA
 EMail: housley@vigilsec.com

Housley Standards Track [Page 25]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7191.txt · Last modified: 2014/04/04 23:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki