ISO/IEC 24824-4:2021

INTERNATIONAL ISO/IEC
STANDARD 24824-4
First edition
2021-03
Information technology — Generic
applications of ASN.1 —
Part 4:
Cryptographic message syntax
Reference number
ISO/IEC 24824-4:2021(E)
©
ISO/IEC 2021

---------------------- Page: 1 ----------------------
ISO/IEC 24824-4:2021(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2021 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 24824-4:2021(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.

The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of document should be noted. This document was drafted in accordance with the editorial
rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).

Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details
of any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC list of patent
declarations received (see patents.iec.ch).

Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.

For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
 www.iso.org/iso/foreword.html. In the IEC, www.iec.ch/understanding-standards.

This document was prepared by ITU-T [Telecommunication Standardization Sector of ITU] (as ITU-
T X.894 [10/2018]) and drafted in accordance with its editorial rules, in collaboration with Joint
Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 6, Telecommunications
and information exchange between systems.

A list of all parts in the ISO/IEC 24824 series can be found on the ISO and IEC websites.

Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.


© ISO/IEC 2020 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 24824-4:2021(E)
CONTENTS
Page
1 Scope . 1
2 Normative references . 1
2.1 Identical Recommendations | International Standards . 1
2.2 Paired Recommendations | International Standards equivalent in technical content . 1
2.3 Additional References . 1
3 Definitions . 1
4 Abbreviations . 2
5 Conventions . 2
6 Cryptographic message syntax . 2
7 Signcryption . 3
7.1 The SigncryptedData type . 4
7.2 The ContentInformation type . 4
7.3 The Signcrypter type . 10
8 Quantum safe SignedData signatures . 11
8.1 Detached content consideration . 12
8.2 Time stamp consideration . 12
8.3 The tokenizedParts attribute . 13
9 Other key management techniques . 13
9.1 Constructive key management . 13
9.2 Database encryption key management . 14
Annex A – ASN.1 modules . 17
A.1 Main CMS module (from IETF RFC 6268) . 17
A.2 Module CMSObjectIdentifiers . 23
A.3 Module AlgorithmInformation-2009 (from IETF RFC 5912) . 25
A.4 Module CryptographicMessageSyntaxAlgorithms-2009 (from IETF RFC 5911) . 32
A.5 Module PKIX-Algs-2009 (from IETF RFC 5912) . 35
A.6 Module PKIXAttributeCertificate-2009 (from IETF RFC 5912) . 42
A.7 Module AttributeCertificateVersion1-2009 (from IETF RFC 5912) . 46
A.8 Module PKIX-CommonTypes-2009 (from IETF RFC 5912) . 47
A.9 Module PKIX-X400Address-2009 (from IETF RFC 5912) . 50
A.10 Module PKIX1Explicit-2009 (from IETF RFC 5912) . 54
A.11 Module PKIXImplicit-2009 (from IETF RFC 5912) . 60
A.12 Module PKIX1-PSS-OAEP-Algorithms-2009 (from IETF RFC 5912) . 67
A.13 Module SecureMimeMessageV3dot1-2009 (from IETF RFC 5911) . 71
A.14 Module CMSSigncryption . 73
A.15 Module CMSCKMKeyManagement . 75
A.16 Module CMSDBKeyManagement . 77
A.17 Module CMSProfileAttributes . 79
A.18 Module TokenizationManifest . 80
A.19 Module TransientKey . 81
A.20 Module TrustedTimestamp . 83
A.21 Module ANSI-X9-42 . 88
A.22 Module ANSI-X9-62 . 91
Annex B – Object identifiers defined in this Recommendation | International Standard . 96
Bibliography . 97

iv Rec. ITU-T X.894 (10/2018) © ISO/IEC 2021 – All rights reserved

---------------------- Page: 4 ----------------------
INTERNATIONAL STANDARD ISO/IEC 24824-4:2021(E)

INTERNATIONAL STANDARD ISO/IEC 24824-4 RECOMMENDATION ITU-T X.894
Information technology — Generic applications of ASN.1 —
Part 4:
Cryptographic message syntax
1 Scope
This Recommendation | International Standard enhances the existing cryptographic message syntax (CMS) protocol by
adding signcryption techniques and providing a new Abstract Syntax Notation One (ASN.1) module which conforms to
the latest edition of the ASN.1 standard which can be used with all standardized encoding rules of ASN.1.
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent edition
of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently valid
International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently valid ITU-
T Recommendations.
2.1 Identical Recommendations | International Standards
– Recommendation ITU-T X.509 (2016) | ISO/IEC 9594-8:2017, Information technology – Open Systems
Interconnection – The Directory: Public-key and attribute certificate frameworks.
2.2 Paired Recommendations | International Standards equivalent in technical content
None.
2.3 Additional References
– ISO 11568-1:2005, Banking – Key management (retail) – Part 1: Principles.
– ISO/IEC 11770-6:2016, Information technology – Security techniques – Key management – Part 6: Key
derivation.
– ISO/IEC 18033-2:2006, Information technology – Security techniques – Encryption algorithms – Part 2:
Asymmetric ciphers.
– ISO/IEC 29150:2011, Information technology – Security techniques – Signcryption.
– IETF RFC 5652 (2009), Cryptographic message syntax (CMS).
– IETF RFC 6268 (2011), Additional new ASN.1 modules for the cryptographic message syntax (CMS) and
the public key infrastructure using X.509 (PKIX).
3 Definitions
For the purposes of this Recommendation | International Standard, the following definitions apply:
The following terms are defined in Rec. ITU-T X.509 | ISO/IEC 9594-8:
a) attribute certificate;
b) CA certificate;
c) certificate revocation list.
© ISO/IEC 2021 – All rights reserved Rec. ITU-T X.894 (10/2018) 1

---------------------- Page: 5 ----------------------
ISO/IEC 24824-4:2021(E)
The following term is defined in ISO/IEC 29150:
– signcryption
4 Abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviations apply:
ASN.1 Abstract Syntax Notation One
CEK Content Encryption Key
CKM Constructive Key Management
CMS Cryptographic Message Syntax
CRL Certificate Revocation List
DBEKM Database Encryption Key Management
DK Data encryption Key
HK HMAC Key
HMAC Hashed Message Authentication
ID Identifier
KDF Key Derivation Function
MK Master Key encryption key
PBKDF Password-Based KDF
SCD Secure Cryptographic Device
SHA Secure Hash Algorithm
URI Uniform Resource Identifier
XML extensible Markup Language
5 Conventions
None.
6 Cryptographic message syntax
CMS is defined in the base text, IETF RFC 5652. ASN.1 modules have been revised to conform to the current ASN.1
standard in IETF RFC 6268.
CMS defines the following content types:
– data: used to transfer data defined string of octets;
– signed data: used to transfer data with zero or more signatures;
– enveloped data: used to transfer encrypted data with one or more content-encryption keys;
– digested data: used to transfer data with a message digest;
– encrypted data: used to transfer encrypted data;
– authenticated data: used to transfer data with a message authentication code and one or more encrypted
authentication keys.
Each of these content types is uniquely identified by an object identifier:
− for data:
 id-data OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549)pkcs(1) pkcs7(7) 1}
− for signed data:
 id-signedData OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840)rsadsi(113549) pkcs(1) pkcs7(7) 2}
− for enveloped data:
© ISO/IEC 2021 – All rights reserved
2 Rec. ITU-T X.894 (10/2018)

---------------------- Page: 6 ----------------------
ISO/IEC 24824-4:2021(E)
 id-envelopedData OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 3}
− for digested data:
 id-digestedData OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)

rsadsi(113549) pkcs(1) pkcs7(7) 5}
− for encrypted data:
 id-encryptedData OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 6}
− for authenticated data:
 id-ct-authData OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2}
Data transferred with CMS use the following ASN.1 type:
ContentInfo ::= SEQUENCE {
contentType CONTENT-TYPE.&id({ContentSet}),
content [0] EXPLICIT CONTENT-
TYPE.&Type({ContentSet}{@contentType})}
The CONTENT-TYPE information object class is defined as TYPE-IDENTIFIER and is used to assign one of the previous
object identifiers to the corresponding ASN.1 type.
CONTENT-TYPE ::= TYPE-IDENTIFIER
ContentType ::= CONTENT-TYPE.&id
ContentSet CONTENT-TYPE ::= {
-- Define the set of content types to be recognized
ct-Data  |
ct-SignedData |
ct-EnvelopedData  |
ct-DigestedData |
ct-EncryptedData |
ct-AuthenticatedData,
...}
ct-Data   CONTENT-TYPE ::= {OCTET STRING IDENTIFIED BY id-
data}
ct-SignedData   CONTENT-TYPE ::= {SignedData IDENTIFIED BY id-
signedData}
ct-EnvelopedData  CONTENT-TYPE ::= {EnvelopedData IDENTIFIED BY
  id-envelopedData}
ct-DigestedData  CONTENT-TYPE ::= {DigestedData IDENTIFIED BY
  id-digestedData}
ct-EncryptedData  CONTENT-TYPE ::= {EncryptedData IDENTIFIED BY
  id-encryptedData}
ct-AuthenticatedData CONTENT-TYPE ::= {AuthenticatedData IDENTIFIED BY
  id-ct-authData}
Other content types can be defined by creation of new information objects of CONTENT-TYPE information object class
using unique object identifiers.
The ct-SignedCryptedData defined in clause 7 is an example.
7 Signcryption
The SigncryptedData uses the signcryption technique defined in ISO/IEC 29150. The signcryption technique
simultaneously signs and encrypts the data to achieve origin authentication, data integrity and confidentiality. Signcryption
can be used in CMS in four different modes:
a) signcrypted-content: content of any type or format is signcrypted using the signcryption algorithm;
b) signcrypted-attributes: content of any type or format and a collection of attributes of any type or
format are together signcrypted;
c) signcrypted-components: elements of content of any type or format are signcrypted for one or more
message recipients using the public-private keys of the sender and the public key of each recipient.
© ISO/IEC 2021 – All rights reserved
Rec. ITU-T X.894 (10/2018) 3

---------------------- Page: 7 ----------------------
ISO/IEC 24824-4:2021(E)
d) signcrypted-envelope: a fresh symmetric key is used to encrypt content of any type or format and the
resulting ciphertext is transmitted as an octet string.
7.1 The SigncryptedData type
id-signcryptedData OBJECT IDENTIFIER ::=
{itu-t recommendation(0) x(24) cms-profile(894) signcryption(1)
data(0)}
ct-SigncryptedData CONTENT-TYPE ::= {
TYPE SigncryptedData IDENTIFIED BY id-signcryptedData}
SigncryptedData ::= SEQUENCE {
version CMSVersion,
contentInformation ContentInformation,
certificates CertificateSet OPTIONAL,
crls  RevocationInfoChoices OPTIONAL,
signcrypters Signcrypters
}
Signcrypters ::= SEQUENCE SIZE(1.MAX) OF Signcrypter
a) version is version number.
b) contentInformation identifies the signcrypted data processing mode.
c) certificates is a collection of public key or attribute certificates to facilitate the validation of the public
keys of the signcrypters. This collection may contain more certificates than necessary or fewer and, in the
latter case, recipients have to use other means to get other certificates.
d) crls is a collection of public key or attribute certificate revocation lists (CRLs) to facilitate the validation
of the certificates of the signcrypters. As for certificates, this collection may contain more CRLs than
necessary or fewer and, in the latter case, recipients have to use other means to get other CRLs.
signcrypters is a collection of all signcrypter specific information.
e)
7.2 The ContentInformation type
ContentInformation ::= SEQUENCE {
mode Mode,
content Content OPTIONAL
}
The modes are defined using the following information object class:
MODE ::= CLASS {
&Type OPTIONAL,
&id  OBJECT IDENTIFIER UNIQUE
}
WITH SYNTAX {[WITH SYNTAX &Type] ID &id}
Four modes are currently defined:
a) signcryptedAttributes: content and attributes of any type or format are signcrypted.
b) signcryptedComponents: specified components of content of any type or format are signcrypted, and
the resulting cryptogram is signed along with a manifest of signcrypted locations and other attributes.
c) signcryptedContent: content of any type or format is signcrypted.
d) signcryptedEnveloped: content of any type or format is encrypted under a symmetric key to create
ciphertext for sharing with one or more message recipients. That symmetric key and a message digest of the
ciphertext are signcrypted for each message recipient using the public-private keys of the sender and the
public key of each recipient.
Mode ::= MODE.&id({ProcessingModes})
ProcessingModes MODE ::= {
signcryptedAttributes |
signcryptedComponents |
signcryptedContent |
© ISO/IEC 2021 – All rights reserved
4 Rec. ITU-T X.894 (10/2018)

---------------------- Page: 8 ----------------------
ISO/IEC 24824-4:2021(E)
signcryptedEnveloped,
... -- Expect additional processing modes --
}
Content ::= OCTET STRING(SIZE(1.MAX))
7.2.1 The signcryptedContent mode
In the signcrypted-content mode, content of any type or format is signcrypted using the signcryption algorithm identified
in the signcryptedDataAlgorithm component of the signcrypters component of type SigncryptedData.
The message sender applies this signcryption algorithm to the content using the sender public and private keys and the
recipient public key. These keys are identified in the message as values of type SigncrypterIDs and the
signcrytionValue component of type Signcrypter contains the results of signcryption.
In this processing mode of SigncryptedData, there are no signcrypted attributes and the optional
signatureInformation component is not present. The message sender at their option may include values in the
unsigncryptedAttributes component of the Signcrypter component for any recipient. The signcrypted-
content mode is indicated in a message by the following information object identifier:
signcryptedContent MODE ::= { ID signcrypted-content }
A value of type SigncryptedData using signcrypted-content mode is created as follows:
a) the value of the version component of type SigncryptedData is set to 1;
b) in the contentInformation component of type SigncryptedData, set the value of mode to the
signcrypted-content object identifier. the optional content component should not be present;
c) optionally, include values in the certificates component of type SigncryptedData;
d) optionally, include values in the crls component of type SigncryptedData;
e) for each message recipient, include a value of type Signcrypter in the signcrypters component of
type SigncryptedData as follows:
i) the value of the version component of type Signcrypter is set to 1,
ii) in the sids component of type Signcrypter set the components of a value of type
SigncrypterIDs to identify the public-private key pairs of the message sender and recipient,
iii) set the value of the signcryptedDataAlgorithm component of type Signcrypter to identify
the signcryption algorithm and any associated parameters,
iv) include the results of signcrypting content of any type or format encoded as a value of type
OCTET STRING in the signcryptionValue component of type Signcrypter,
v) the optional signatureInformation component of type Signcrypter should not be present;
vi) optionally, include values in the unsigncryptedAttributes component of type
Signcrypter.
To recover the plaintext from the SigncryptedData message, a message recipient should perform the following steps:
1) search the list of per recipient values of type Signcrypter in the signcrypters component of type
SigncryptedData to locate the recipient public-private key pair in the sids component of type
Signcrypter;
2) designcrypt the value in the signcryptionValue component of type Signcrypter for a given
recipient using their public-private key pair of the recipient and the public key of the sender identified in the
sids component of type Signcrypter, and the signcryption algorithm and associated parameters
provided in the signcryptedDataAlgorithm component of type Signcrypter.
Perform certificate path validation to gain assurance that the sender public key certificate is trusted.
7.2.2 The signcryptedAttributes mode
In the signcrypted-attributes mode, content of any type or format and a collection of attributes of any type or format in the
signcryptionAttributes component of type SigncrypterInfo are together signcrypted as specified for the
signcrypted-content mode. At least three attributes shall be present: the messageDigest, the contentType, and the
signcryptedAttributes attribute.
© ISO/IEC 2021 – All rights reserved
Rec. ITU-T X.894 (10/2018) 5

---------------------- Page: 9 ----------------------
ISO/IEC 24824-4:2021(E)
The signcrypted-attributes mode is indicated in a message by the following information object identifier:
signcryptedAttributes MODE ::= { ID signcrypted-attributes }
A value of type SigncryptedData using signcrypted-attributes mode is created as follows:
a) the value of the version component of type SigncryptedData is set to 1;
b) in the contentInformation component of type SigncryptedData, set the value of mode to the
signcrypted-attributes object identifier. the optional content component should not be present;
c) optionally, include values in the certificates component of type SigncryptedData;
d) optionally, include values in the crls component of type SigncryptedData;
e) for each message recipient, include a value of type Signcrypter in the signcrypters component of
type SigncryptedData as follows:
i) the value of the version component of type Signcrypter is set to 1;
ii) in the sids component of type Signcrypter set the components of a value of type
SigncrypterIDs to indentify the public-private key pairs of the message sender and recipient;
iii) set the value of the signcryptedDataAlgorithm component of type Signcrypter to identify
the signcryption algorithm and any associated parameters;
iv) create a value of type ToBeSigncrypted by setting its content component to a value of type
Content and its attributes component to a value of type SigncryptedAttributes;
v) signcrypt an encoded value of type ToBeSigncrypted and include the results of the processing in
the signcryptionValue component of type Signcrypter;
vi) the optional signatureInformation component of type SigncrypterInfo should not be
present;
vii) optionally, include values in the unsigncryptedAttributes component of type
Signcrypter.
To recover the plaintext from the SigncryptedData message, a message recipient should perform the following steps:
a) search the list of per recipient values of type Signcrypter in the signcrypters component of type
SigncryptedData to locate the recipient public-private key pair in the sids component of type
Signcrypter;
b) designcrypt the value in the signcryptionValue component of type Signcrypter for the recipient
using the signcryption algorithm and any associated parameters provided in the
signcryptedDataAlgorithm component of type Signcrypter to recover a value of type
ToBeSigncrypted;
c) perform certificate path validation to gain assurance that the sender public key certificate is trusted.
7.2.3 The signcryptedComponents mode
In signcrypted-components mode, elements of content of any type or format are signcrypted for one or more message
recipients using the public-private keys of the sender and the public key of each recipient. A content-type specific manifest
of signcrypted element locations in the content is bound to the partially signcrypted content under a digital signature.
The signcrypted-components mode is indicated in a message by the following information object identifier:
signcryptedComponents MODE ::= { ID signcrypted-components }
A value of type SigncryptedPartsManifest is defined in terms of the &id and &Type fields of the
SIGNCRYPTED information object class. This type definition uses a parametrized type, Signcrypted{}, whose sole
parameter is the Manifest information object set:
SigncryptedPartsManifest ::= Signcrypted{{Manifest}}
Signcrypted{SIGNCRYPTED:IOSet} ::= SEQUENCE {
Name SIGNCRYPTED.&id({IOSet}),
Parts SIGNCRYPTED.&Type({IOSet}{@name}) OPTIONAL
}

SIGNCRYPTED ::= CLASS {
© ISO/IEC 2021 – All rights reserved
6 Rec. ITU-T X.894 (10/2018)

---------------------- Page: 10 ----------------------
ISO/IEC 24824-4:2021(E)
&id  OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX {OID &id [PARMS &Type]}
Manifest SIGNCRYPTED ::= {
xPathManifest,
.
}
The type of manifest required to identify the signcrypted components of a particular object varies with the type, structure
and format of the object. For content in the form of an image, a signcrypted components manifest might be composed
of a list of ((x, y), (x, y)) coordinate pairs that define a rectangular area of the image to be signcrypted and thereby redacted.
In this Recommendation | International Standard, a single manifest object is defined to support component identification
in an extensible markup language (XML) document. The xPathManifest object uses location paths based on the XPath
query language to specifiy a set of one or more signcrypted XML document components and is defined as follows:
xPathManifest SIGNCRYPTED ::= {
OID id-cms-XPath PARMS XPathSet
}
XPathSet ::= SEQUENCE SIZE(1.MAX) OF XPath
XPath ::= UTF8String (CONSTRAINED BY { -- XML Path Query Language 2.0 -- })
A value of type SigncryptedData using signcrypted-components mode is created as follows:
a) the value of the version component of type SigncryptedData is set to 1;
b) in the contentInformation component of type SigncryptedData, set the value of mode to the
signcrypted-components object identifier. the optional content component should not be present;
c) optionally, include values in the certificates component of type SigncryptedData;
d) optionally, include values in the crls component of type SigncryptedData;
e) for each message recipient, include a value of type Signcrypter in the signcrypters component of
type SigncryptedData as follows:
i) the value of the version component of type Signcr
...