1、 American National Standard for Financial Services X9.73October2002 Cryptographic Message Syntax Secretariat: American Bankers Association Approved: American National Standards Institute ANS X9.73October2002 Foreword Approval of an American National Standard requires verification by ANSI that the re
2、quirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agr
3、eement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effort be made toward their resolution. The use of American National Standards is completely voluntary; their existence does not in any r
4、espect preclude anyone, whether he has approved the standards or not from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an inter
5、pretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in the name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whos
6、e name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the American National Standards Institute require that action be taken to reaffirm, revise, or withdraw this standard no later than five years
7、 from the date of approval. Published by American Bankers Association 1120 Connecticut Ave., NW Washington, DC 20036 USA Customer Service Center 1(800) 338-0626 or 1(202) 663-5087 Fax 1(202) 663-7543, E-mail X9 Online http:/www.x9.org Copyright 2002 by American Bankers Association All rights reserv
8、ed. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without prior written permission of the publisher. Printed in the United States of America 2002 All rights reserved 1 ANS X9.73October2002 Contents Foreword . 1 Introduction. 4 1 Scope 9 2
9、Normative references 9 3 Terms, definitions, symbols and abbreviated terms .10 4 Organization.14 5 Application .15 6 Message Structures 15 6.1 General .15 6.2 Signed Data17 6.2.1 General .17 6.2.2 Signed Attributes.21 6.2.3 Unsigned Attributes 24 6.2.4 Certificate Formats25 6.2.5 Detached Signatures
10、.26 6.3 Enveloped Data26 6.3.1 General .26 6.3.2 Detached Data28 6.3.3 Certificate Formats28 6.4 Authenticated Data29 6.5 Digested Data.30 6.6 Encrypted Data 30 6.7 Named Key Encrypted Data .31 6.8 Nesting of Structures31 6.9 Receipts31 6.10 Aggregate Data Signing31 7 Key Management Processing 31 7.
11、1 General .31 7.2 Asymmetric Key Transport.32 7.3 Asymmetric Key Agreement 32 7.4 Pre-established Key Encryption Keys.33 7.5 External Mechanisms Constructive Key Management.34 7.5.1 General .34 7.5.2 CKM Recipients .34 7.5.3 CKM Envelopes .35 8 S/MIME Formatting38 9 Conformance Classes.38 Annex A (n
12、ormative) ASN.1 Module for Object Identifiers40 2 2002 All rights reserved ANS X9.73October2002 Annex B (normative) X9.73 CMS Syntax43 Annex C (informative) Example Using CKM55 Annex D (informative) Example Using ANS X9.24 Key Management .58 Bibliography59 2002 All rights reserved 3 ANS X9.73October
13、2002 Introduction NOTE: The users attention is called to the possibility that compliance with this standard may require the use of an invention covered by patent rights. By publication of this standard, no position is taken with respect to the validity of this claim or of any patent rights in connec
14、tion therewith. The patent holder has, however, filed a statement of willingness to grant a license under these rights on reasonable and non-discriminatory terms and conditions to applicants desiring to obtain such a license. Details may be obtained from the standards developer. Suggestions for the
15、improvement or revision of this Standard are welcome. They should be sent to the X9 Committee Secretariat, American Bankers Association, 1120 Connecticut Avenue, N.W., Washington, D.C. 20036. This Standard was processed and approved for submittal to ANSI by the Accredited Standards Committee on Fina
16、ncial Services, X9. Committee approval of the Standard does not necessarily imply that all the committee members voted for its approval. Secretariat will provide current text for the following: The X9 committee had the following members: Harold Deal, Chairman Vincent DiSantis, Vice Chairman Cynthia
17、L. Fuller, Managing Director Darlene J. Schubert, Program Manager Organization Represented Representative ACI Worldwide Cindy Rink ACI Worldwide Jim Shaffer American Bankers Association Stephen Schutze American Bankers Association Michael Scully American Express Company Mike Jones American Express C
18、ompany Dick Schreiber American Express Company Gerry Smith American Express Company Barbara Wakefield BB the two keys have the property that, given the public key, it is computationally infeasible to derive the private key. 3.3 certificate digital certificate The public key and identity of an entity
19、, together with some other information, that is rendered unforgeable by signing the certificate with the private key of the Certification Authority that issued the certificate. 3.4 Certificate Authority CA An entity trusted by one or more other entities to create and assign certificates. 3.5 certifi
20、cate revocation list CRL A list of digital certificates that have been revoked for one reason or another usually because of compromise. 3.6 constructive key management CKM A method of establishing a key, whereby several components of keying material, both symmetric and asymmetric type of keys, where
21、 each component is used for a specific purpose, are combined together using a mathematical function to produce an object key. 10 2002 All rights reserved ANS X9.73October2002 3.7 content encryption key CEK The symmetric key used to encrypt the content of a message. 3.8 cryptographic hash function ha
22、sh A (mathematical) function that maps values from a large (possibly very large) domain into a smaller range. The function satisfies the following properties: 1. (One-way) It is computationally infeasible to find any input that maps to any pre-specified output; 2. (Collision Free) It is computationa
23、lly infeasible to find any two distinct inputs that map to the same output. 3.9 cryptographic key key A parameter that determines, possibly with other parameters, the operation of a cryptographic function such as: (a) the transformation from plaintext to ciphertext and vice versa; (b) the synchroniz
24、ed generation of keying material; (c) digital signature computation or validation. 3.10 cryptography The discipline that embodies principles, means and methods for the transformation of data to hide its information content, prevent its undetected modification, prevent its unauthorized use or a combi
25、nation thereof. 3.11 domain parameters The prime p that defines GF(p), a prime factor q of p-1, and an associated generator g of order q in the multiplicative group GF(p)*. These parameters are used to facilitate the use of algorithms based on discrete logarithm cryptography. 3.12 ephemeral key A pr
26、ivate or public key that is unique for each execution of a cryptographic scheme. An ephemeral private key is to be destroyed as soon as computational need for it is complete. An ephemeral public key may or may not be certified. In this standard, an ephemeral public key is represented by t, while an
27、ephemeral private key is represented by r, with a subscript to represent the owner of the key. 2002 All rights reserved 11 ANS X9.73October2002 3.13 forward secrecy perfect forward secrecy The assurance provided to an entity that the session key established with another entity will not be compromise
28、d by the compromise of either entitys static private key in the future. 3.14 key agreement A method of establishing a key, whereby both parties contribute to the value of the resulting key and neither party can control the value of the resulting key. 3.15 key encryption key A key used exclusively to
29、 encrypt and decrypt keys. 3.16 keying material The data (e.g., keys, certificates and initialization vectors) necessary to establish and maintain cryptographic keying relationships. 3.17 key management The generation, storage, secure distribution and application of keying material in accordance wit
30、h a security policy. 3.18 key pair When used in public key cryptography, a public key and its corresponding private key. 3.19 key transport A key establishment protocol under which the secret key is determined by the initiating party. 3.20 message authentication code MAC A cryptographic value that i
31、s the result of passing a message through the message authentication algorithm using a specific key. 3.21 Multipurpose Internet Mail Extensions MIME The format for internet message bodies as defined in the IETF documents RFC 2045, RFC 2046, RFC 2047, RFC 2048 and RFC 2049. 3.22 nonce A nonrepeating
32、value, such as a counter, using key management protocols to thwart replay and other types of attack. 12 2002 All rights reserved ANS X9.73October2002 3.23 object That which is to be encrypted. 3.24 object key A key used to encrypt and decrypt an object. 3.25 private key In an asymmetric (public) key
33、 cryptosystem, the key of an entitys key pair that is known only by that entity. A private key may be used: (1) to compute the corresponding public key; (2) to make a digital signature that may be verified by the corresponding public key; (3) to decrypt data encrypted by the corresponding public key
34、; or (4) together with other information to compute a piece of common shared secret information. 3.26 public key In an asymmetric (public) key cryptosystem, that key of an entitys key pair that may be publicly known. A public key may be used: (1) to verify a digital signature that is signed by the c
35、orresponding private key; (2) to encrypt data that may be decrypted by the corresponding private key; (3) by other parties to compute a piece of shared information. 3.27 Secure Electronic Transactions SET A cryptographic protocol that uses encryption technology to protect the transfer of payment inf
36、ormation over open networks, such as the Internet. 3.28 Secure MIME S/MIME The specification for handling MIME data securely by adding cryptographic security services to supply authentication, message integrity, non-repudiation of origin, privacy and data security. The specification is found in IETF
37、 documents RFC 2311 and 2312. See Multipurpose Internet Mail Extensions (MIME). 2002 All rights reserved 13 ANS X9.73October2002 3.29 shared symmetric key A symmetric key derived from a shared secret value and other information. 3.30 static key A private or public key that is common to many executio
38、ns of a cryptographic scheme. A static public key may be certified. In this standard, the letter “y” represents a static public key, while a static private key is represented by “x”, each with a subscript to represent the owner of the key. See definition of ephemeral key. 3.31 symmetric cryptographi
39、c algorithm A cryptographic algorithm that uses one shared key, a secret key. The key must be kept secret between the two communicating parties. The same key is used for both encryption and decryption. 3.32 symmetric key A cryptographic key that is used in symmetric cryptographic algorithms. The sam
40、e symmetric key that is used for encryption is also used for decryption. 3.32 user keying material UKM An optional field in the cryptographic message syntax used to convey ephemeral keys or nonces. 4 Organization The following normative and informative annexes are integral parts of the standard that
41、, for reasons of convenience, are placed after all normative elements. Annex Contents Normative/Informative A ASN.1 Module for Object Identifiers Normative B X9.73 CMS Syntax Normative C Example Using CKM Informative D Example Using ANS X9.24 Key Management Informative Annexes C and D are informativ
42、e and give additional information that may be useful to implementers of this Standard. 14 2002 All rights reserved ANS X9.73October2002 5 Application The cryptographic message syntax defined in this standard provides the following services: 1) Independent data unit protection, where each message or
43、transaction is protected independently. There is no need for a real-time communications session between the sender and recipient, and no cryptographic sequencing (such as cipher block chaining) between messages. This standard does define attributes that allow applications to maintain relationships b
44、etween messages; 2) Confidentiality, using any ANSI X9 approved symmetric encryption algorithm and any ANSI X9 approved key management algorithm. Typically, the key management algorithm is used to protect a content-encryption key used to encrypt the message. This approach allows the sender to send a
45、n encrypted message to multiple recipients, while only encrypting the actual message once. The syntax is optimized for the common case where the same key management algorithm and parameters are used for all recipients; 3) Integrity and data origin authentication, using any ANSI X9 approved digital s
46、ignature or message authentication algorithm. (When using digital signatures, non-repudiation may also be supported.) The requirements of other ANSI standards for multiple signatures, per-signer authenticated attributes, and countersignatures, are also supported. An optimized syntax is also provided
47、 for the common case where only a single sender signs or authenticates a message. This syntax does not by itself allow for the selective protection of specific fields within a message; rather, it protects and optionally encapsulates the entire message. However, selective field protection can be impl
48、emented by combining multiple protected messages into a composite message. In general, selective field protection requires knowledge of the message and is best left to the application. This syntax specifies enhancements of the cryptographic message syntax defined in RFC 3369, Reference 23. Additiona
49、l attributes for use in financial applications, as well as cryptographic processing required for use with ANSI X9 approved cryptographic algorithms are defined. 6 Message Structures 6.1 General The message syntax is defined using ASN.1. The following subsections describe the various protected message types. A full specification of the syntax using ASN.1 can be found in Annex B. The Cryptographic Message Syntax (CMS) associates a content type identifier with a content. EncapsulatedContentInfo := SEQUENCE eConten
