Information technology — Generic applications of ASN.1 — Part 4: Cryptographic message syntax

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.

Technologies de l'information — Applications génériques de l'ASN.1 — Partie 4: Titre manque

General Information

Status
Published
Publication Date
30-Mar-2021
Current Stage
6060 - International Standard published
Start Date
31-Mar-2021
Completion Date
31-Mar-2021
Ref Project

Buy Standard

Standard
ISO/IEC 24824-4:2021 - Information technology -- Generic applications of ASN.1
English language
98 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

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.
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
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.