Network Working Group J. Stapleton Internet Draft Innove LLC Category: Informational P. Griffin Griffin Consulting January 2006 Trusted Transactions for Network-Enabled Devices Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft is expected to be published as an Experimental RFC. Abstract This document specifies a cryptographically protected message format and transaction protocol for managing network-enabled devices. The message format consists of a header, content and trailers. The message header uniquely identifies the message type. The message content is afforded (i) authentication by means of a digital signature trailer and (ii) confidentiality by means of encryption trailer; and the whole message (header, content, trailers) is afforded integrity by means of a trusted time stamp trailer. All message structures are defined using ASN.1 and all cryptographic structures use CMS. The transaction protocol consists of request messages, response messages, acknowledgement messages, and notification messages. Stapleton, et al. [Page 1] INTERNET DRAFT January 2006 1 Introduction This document specifies a trusted transaction for use by application management systems to administer network-enabled devices. A trusted transaction consists of an application management transaction and the result of a trusted time stamp on that transaction. An application transaction consists of a message header, the message payload and a cryptographic trailer providing identity and/or confidentiality. In general, one or more request, response, acknowledgement or notification messages constitutes a complete transaction. A network-enabled device can generate, secure and send outgoing transactions and/or receive, validate and process incoming transactions. Network-enabled devices range from infrastructure equipment such as routers and printers to higher-end application equipment such as automated teller machines (ATM) and cash registers used in the financial services industry. So too as more and more commercial appliances become network-enabled and more sophisticated, they will become vulnerable to attack. The trusted transactions specified in this document offers a common and secure method for managing such devices. In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [RFC2119]. 2 Definitions 2.1 Trusted Transaction The trusted tranaction is composed of a value of type Transaction in its encoded form and a value of type TimeStampToken returned from a time stamp authority (TSA). The syntax for a trusted transaction is defined as type TrustedTransaction as follows: TrustedTransaction ::= SEQUENCE { version Version DEFAULT ver1, transaction EncodedTransaction, integrity TimeStampToken } This type contains three components: version, transaction and integrity. The version component contains the integer version of the TrustedTransaction syntax. The value of the version component indicates changes in the underlying transaction schema of a given message to already deployed applications. The transaction component contains a value of type Transaction in its encoded form. The integrity component contains a trusted time stamp computed over the hash of the transaction component. Stapleton, et al. [Page 2] INTERNET DRAFT January 2006 2.2 Application Transaction An application transaction consists of a message header, a payload package and a cryptgraphic message trailer. The syntax for a transaction is defined as type Transaction as follows: Transaction ::= SEQUENCE { version Version DEFAULT ver1, header Header, package Package, trailer Trailer } This type contains four components: version, header, package and trailer. The version component contains the integer version of the Transaction syntax, and its value indicates changes in the underlying transaction schema. The header component contains a value of type Header, which provides information about the content of the transaction and the entities involved in the transaction. The syntax for a transaction header is defined as type Header as follows: Header ::= SEQUENCE { transactionCode TransactionCode, transactionNumber TransactionNumber, transactionCounter TransactionCounter OPTIONAL, messageRouting MessageRouting } The package component contains the enterprise transaction payload. This may be any of the management messages defined in this document and represented using the abstract syntax specified in Annex A: Enterprise Management and Security (EMS) Schmea. The syntax for a transaction payload is defined as type Package as follows: Package ::= CHOICE { plaintext [0] EncodedPlaintext, ciphertext [1] Ciphertext } The trailer component contains cryptographic message syntax that supports transaction level data integrity, origin authentication and confidentiality services. The syntax for a transaction trailer is defined as type Trailer as follows: Trailer ::= SEQUENCE { encrypted Encrypted OPTIONAL, -- Encrypted Plaintext identity SignedData OPTIONAL -- Signed Plaintext } Stapleton, et al. [Page 3] INTERNET DRAFT January 2006 Cryptographic processing must be performed on transaction values in a form that is independent of hardware device, operating system, and programming language considerations. Values of these complex, structured types must be treated as a simple series of octets. A value of type Transaction in its encoded form is defined as type EncodedTransaction as follows: EncodedTransaction ::= ENCODED-VALUE-OF.&Type( Transaction ) 3 Transaction Header The Header type contains four components: transactionCode, transactionNumber, an optional transactionCounter and messageRouting. 3.1 Transaction Code The transactionCode component of type Header (the header component of type Transaction) dentifies the type of transaction and the expected content of the message payload in the package component of type Transaction. The syntax for a transaction code is defined as type TransactionCode as follows: TransactionCode ::= CONTENT.&id({TransactionSet}) Type TransactionCode is defined in terms of the in &id field of the CONTENT information object class. This field is defined as the built in ASN.1 type RELATIVE-OID. Values of this type are relative information object identifiers, a series of one or more integers. Valid values of type TransactionCode are constrained to those specified in the information object set TransactionSet. 3.2 Transaction Number The transactionNumber component of type Header (the header component of type Transaction) is a monotonically increasing message sequence number that identifies a given transaction. The syntax for a transaction number is defined as type TransactionNumber as follows: TransactionNumber ::= INTEGER (0..MAX) A value of type TransactionNumber is a nonnegative integer. 3.3 Transaction Counter The transactionCounter component of type Header (the header component of type Transaction) is an optional, monotonically increasing integer used to chain multiple transactions together to form a transaction set. The syntax for a transaction counter is defined as type TransactionCounter as follows: TransactionCounter ::= INTEGER (0.65535) A value of type TransactionCounter is a nonnegative integer. Stapleton, et al. [Page 4] INTERNET DRAFT January 2006 3.4 Message Routing The messageRouting component of type Header (the header component of type Transaction) contains message sender and recipient information, and optionally, information on any message intermediaries. The syntax for message routing information is defined as type MessageRouting as follows: MessageRouting ::= SEQUENCE { receiverID EntityID, intermediaries Intermediaries OPTIONAL, senderID EntityID } A value of type MessageRouting contains three components named receiverID, intermediaries, and senderID. The receiverID component is a value of type EntityID that identifies the final recipient of the transaction. The sID component is a value of type EntityID that identifies the initiator of the transaction. The optional intermediaries component is a series of one or more values of type EntityID that are participating in the transaction before the final recipient. The syntax is defined as type Intermediaries as follows: Intermediaries ::= SEQUENCE SIZE(1..MAX) OF EntityID The syntax for the transaction message initiator, any intermediaries and the final recipient identifiers is defined as type EntityID as follows: EntityID ::= SEQUENCE { domain Domain, qualifier Qualifier OPTIONAL, country ISO3166CountryCode OPTIONAL } A value of type EntityID contains three components named domain, qualifier, and country. The domain component is a set of choice alternatives, each of which can unambiguously identify an entity within the context of a transaction. The optional qualifier component is related to the domain component and provides a finer degree of specificity of the entity identified by the domain name. The syntax for a domain qualifier is defined as type Qualifier as follows: Qualifier ::= RELATIVE-OID The optional country component is the country of origin as defined in [IS3166]. The syntax for a country identifier is defined as type ISO3166CountryCode as follows: ISO3166CountryCode ::= PrintableString(SIZE(2)) Stapleton, et al. [Page 5] INTERNET DRAFT January 2006 The syntax for a domain identifier is defined as type Domain as follows: Domain ::= CHOICE { directoryName DirectoryName, dnsName DNSName, ediPartyName EDIPartyName, ipAddress IPAddress, entityIdentifier EntityIdentifier, otherName OtherName, rfc822Name RFC822Name, uniformResourceIdentifier UniformResourceIdentifier, universalUniqueIdentifier UniversalUniqueIdentifier, x400Address ORAddress } The entity domain identification choice alternatives are defined in Annex B: Entity Domain Identification. 4 Transaction Package This document defines two types of a transaction package (message payload), plaintext (unencrypted) payload and encrypted payload. 4.1 Plaintext Payload Values of type Plaintext are complex, structured transaction payloads, which must be treated as a simple series of octets when used as inputs to cryptographic processing. The plaintext choice alternative of type Package (the package component of type Transaction) is a value of type Plaintext in its encoded form, a representation that is independent of any hardware, operating system, or programming language considerations. This encoded form of type Plaintext is a simple series of octets. The syntax for an encoded transaction payload is defined as type EncodedPlaintext, as follows: EncodedPlaintext ::= ENCODED-VALUE-OF.&Type( Plaintext ) The syntax for a transaction payload is defined as type Plaintext, as follows: Plaintext ::= SEQUENCE { content TransactionCode, payload CONTENT.&Type({TransactionSet}{@content}) } TransactionCode ::= CONTENT.&id({TransactionSet}) A value of type Plaintext contains two components named content and payload, which are defined in terms of the &id and &Type fields of the information object class CONTENT. The value of the content component is a relative object identifier. The value of the payload Stapleton, et al. [Page 6] INTERNET DRAFT January 2006 component is an open type and can be the value of any ASN.1 type in its encoded form. The valid values of both Plaintext components are constrained by a table of rows of transaction information objects specified in this document. Each row contains one object that defines one transaction. Each object contains one occurance of the &id and &Type fields. In the definition of type Plaintext, the @content notation binds the value of the payload component to the unique identifier value of the content component. Once the identifier in the content component is established, the row of the table constraint is set and the associated type of the payload component is indicated. The syntax for this transaction table constraint is defined as the CONTENT information object set TransactionSet, as follows: TransactionSet CONTENT ::= { AuditManagement | AuthorityManagement | CompromiseManagement | ConfigurationManagement | InitializationManagement | InventoryManagement | KeyManagement | PolicyManagement, ... -- Expect additional transaction objects -- } The notation "|" is equivalent to the ASN.1 information object set operator "UNION". In this Document, TransactionSet is a superset defined as the union of eight extensible transaction information object sets. Each transaction information object set (such as the AuditManagement set) is specified in a separate ASN.1 module (see Appendix A). This design allows each broad category of transactions to be logically collected together and to be versioned independent of all other categories. The extension marker ("...") following the PolicyManagement policy transaction information object set, indicates that additional objects can be added to the transaction set constraint. These may be added by subsequent versions of this Document, or by any community with a need. It should be noted that already deployed applications, in general, may not be able to process the content of any additions made to this set. But they should expect to encounter and gracefully handle any unexpected transaction objects. 4.2 Encrypted Payload The ciphertext choice alternative of type Package (the package component of type Transaction) is an opaque string of octets that contain the results of encrypting a transaction payload, a value of type Plaintext. The syntax for an encrypted transaction payload is defined as type Ciphertext, as follows: Stapleton, et al. [Page 7] INTERNET DRAFT January 2006 Ciphertext ::= ENCRYPTED{ EncodedPlaintext } The encrypted transaction payload is detached from the actual cryptographic message component that fully describes the encryption. Support for two types of cryptographic messages, NamedKeyEncryptedData and EnvelopedData, are required in this document. When the ciphertext choice alternative of type Package is present in a value of type Transaction, one or the other of these cryptographic types shall be present in the trailer component of type Transaction. 5 Transaction Trailer This document defines two types of a transaction trailer, the encrypted trailer and the identity trailer. Note that the use of other symmetric integrity schemes are not supported. 5.1 Encrypted Trailer The encrypted component of type Trailer (the trailer component of type Transaction) is a choice between two cryptographic alternatives, types NamedKeyEncryptedData and EnvelopedData. The syntax for an encoded transaction payload is defined as type Encrypted, as follows: Encrypted ::= CHOICE { namedKey [0] NamedKeyEncryptedData, enveloped [1] EnvelopedData } The type EnvelopedData is defined in RFC 3852 Cryptographic Message Syntax (also in the American National Standards X9.73 Cryptographic Message Syntax (CMS) and X9.96 XML Cryptographic Message Syntax (XCMS), and the working draft ISO 22895 Secure Message Syntax) which share a common ASN.1 schema. However, the type NamedKeyEncryptedData is currently only defined in X9.73, X9.96 and WD ISO 22895. It is expected that NamedKeyEncryptedData will be incorporated into EncryptedData in future versions of the X9 and ISO standards. Regardless, this common abstract schema allows the same abstract values defined in this Document to be concretely represented in an instance of communication in either a compact, efficient binary format or as flexible, verbose XML markup. 5.1.1 Named Key Encrypted Trailer NamedKeyEncryptedData is used when the sender and receiver have previously established a transaction encryption key and can refer to the key by name. NamedKeyEncrytpedData is defined as follows: NamedKeyEncryptedData ::= SEQUENCE { version Version DEFAULT ver1, keyName Keyname OPTIONAL, encryptedContentInfo EncryptedContentInfo } Stapleton, et al. [Page 8] INTERNET DRAFT January 2006 KeyName ::= OCTET STRING (SIZE(1..MAX)) 5.1.2 Enveloped Data Encrypted Trailer EnvelopedData is used when the sender has dynamically generated a transaction encryption key specifically for that transaction. The establishedKey choice alternative is based on the EnvelopedData type. Use of this type assumes the recipient knows the private asymmetric key needed to decrypt the symmetric key used by the sender to encrypt the biometric information. EnvelopedData is defined in RFC 3852 as follows: EnvelopedData ::= SEQUENCE { version CMSVersion, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, recipientInfos RecipientInfos, encryptedContentInfo EncryptedContentInfo, unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } This document does not use the optional unprotectedAttrs. 5.1.3 Originator Information The sender may include public key certificates and certificate revocation lists that may be useful to the recipient in the originatorInfo component, defined as follows: OriginatorInfo ::= SEQUENCE { certs [0] CertificateSet OPTIONAL, crls [1] CertificateRevocationLists OPTIONAL } ALL EXCEPT({ -- none; at least one component is present -- })) Any combination of X.509 certificates [RFC2459] and attribute certificates may be included in the CertificateSet type in any order. There may be more or fewer certificates required for any purpose. Certificates are provided as needed to support content key encryption in the key transport key management technique used in this document. Use of the CertificateSet type to distribute certificates is not required. They may be distributed or obtained by other means, or an online certificate validation service may be used instead. Only version three X.509 certificates, and version two attribute certificates are supported in [IS19092]. Any number of CRLs may be included in the CertificateRevocationLists type in any order. There may be more or fewer CRLs needed for any purpose. CRLs are provided as needed to support certificate validation. Use of the CertificateRevocationLists type to distribute CRLs is not required. CRLs may be obtained by other means, or an online certificate validation service may be used instead. Only version two certificate revocation lists are supported. Stapleton, et al. [Page 9] INTERNET DRAFT January 2006 The certificates and certificate revocation lists are signed binary objects, whose digital signatures have been calculated on values encoded using the Distinguished Encoding Rules (DER) of ASN.1. In order to verify the signatures on these objects, their original encodings must be maintained. But these values must also be represented in XML encodings in a useful textual format when messages in this Document are encoded using XER. The values in the certificates and CRL components of type OriginatorInfo have been base64 armoured to minimize their size when represented using XML markup while preserving their original encodings. When DER is used, the encoding of these values is identical to the encoding used in X.509. 5.1.4 Recipient Information Type RecipientInfos is a set of one value of type RecipientInfo, one value for each recipient of a digital envelope in EnvelopedData. In this Document there is always a single digital envelope recipient. Several key management techniques are defined in ISO 22895 for use in EnvelopedData. Although use of the key transport technique is most commonly used in this Document, other techniques such as Constructive Key Management (CKM) may be employed by an application. RecipientInfo ::= CHOICE { ktri KeyTransRecipientInfo, kari [1] KeyAgreeRecipientInfo, kekri [2] KEKRecipientInfo, pwri [3] PasswordRecipientinfo, ori [4] OtherRecipientInfo } Key transport information is provided to the recipient of a digital envelope so that only the recipient can open the envelope and recover the protected content encryption key. The recipient to decrypt the content may then use the content encryption key. The information required to recover the content encryption key is contained in a value of type KeyTransRecipientInfo, as follows: KeyTransRecipientInfo ::= SEQUENCE { version CMSVersion, rid RecipientIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, encryptedKey EncryptedKey } Type KeyTransRecipientInfo is a sequence of four components. The integer version number is always set to eighty-four in this Document. The recipient uses the rid component to identify the public key that the sender used to encrypt the content encryption key. This public key is bound to a key encryption algorithm in the public key certificate of the recipient. This public key is associated with the Stapleton, et al. [Page 10] INTERNET DRAFT January 2006 recipient private key needed to decrypt the content encryption key used by the sender to encrypt the content. The encrypted content encryption key is a value of type EncryptedKey defined as an opaque string, as follows: EncryptedKey ::= OCTET STRING 5.2 Identity Trailer The identity component of type Trailer (the trailer component of type Transaction) is the cryptographic type SignedData. A signature with a named key allows the sender to indicate the key (i.e., the private key associated with a public key certificate) to be used to validate the signature on a management information package. The type SignedData is defined as follows: SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] CertificateSet OPTIONAL, crls [1] CertificateRevocationLists OPTIONAL, signerInfos SignerInfos } In this document, a simplified version of type SignedData is used, where some of the processing complexity often required in other protocols has been simplified by eliminating options and imposing restrictions. The following constraints apply: 1. Only one signature is present, since there is only one signer of the transaction package. 2. The content being signed is not included in the SignedData type, as it is already present in the Package component of the Transaction object. The absence of the content is sometimes referred to as "detached" data. 3. The signed and unsigned attributes are not present. 4. Typically, the certificates and crls components of type SignedData are not present. When these components are present, their values are treated as opaque data in this document so that their details need not be revealed when values of type SignedData are represented using XML markup. 5.3 Non-use of Other Integrity Schemes Historically, data integrity mechanisms included symmetric schemes such as message authentication codes (MAC) based on symmetric ciphers or HMAC based on keyed hash algorithms; and asymmetric digital signature schemes. However, without a trusted time source to anchor the data content to a verifiable point in time, the so-called Stapleton, et al. [Page 11] INTERNET DRAFT January 2006 integrity is suspect. This topic is discussed in greater detail in [IEEE] and [ISSA]. Essentially, at some given time T1 an entity generates an integrity token such as a MAC, HMAC or digital signature, and later at some time T2 can alter the data, reset its system clock to the same time T1 (or an earlier time T0), and regenerate a valid integrity token. The relying party now has two different data versions with valid integrity tokens without any reliable reference to the actual sequence of events. The reader should note that this is a real-world problem where executives have been convicted, lawyers have been disbarred, and individuals have been incarcerated. Trusted Time Stamp technology provides real data integrity anchored to a verifiable point in time. This technology is defined in [RFC 3161] and [ISO 18014] and more fully in [X9.95]. 6 Time Stamp Token A trusted transaction consists of an enterprise management transaction and a time stamp on that transaction returned from a time stamp authority. The time stamp is carried in the integrity component of type TrustedTransaction. The syntax for the trusted transaction time stamp token is defined in the X9.95 Trusted Time Stamp Standard as a value of type TimeStampToken, as follows: TimeStampToken ::= SEQUENCE { contentType CONTENT.&id({Contents}), content [0] EXPLICIT CONTENT.&Type({Contents}{@contentType}) } Type TimeStampToken contains two components named contentType and content. The contentType component contains an information object identifier whose value is the name of the type of time stamp carried in the content component of type TimeStampToken. Several different types of time stamps are defined in X9.95 and each has different processing requirements and format. 7 References This section provides both normative and informative references. 7.1 Normative References X9.62 American National Standard X9.62-2005 Public Key Cryptographyfor the Financial Services Industry – The Elliptic Curve Digital Signature Algorithm (ECDSA) X9.63 American National Standard for the Financial Services X9.63– 2001 Public Key Cryptography for the Financial Services Industry – Key Agreement and Key Transport Using Elliptic Curve Cryptography Stapleton, et al. [Page 12] INTERNET DRAFT January 2006 X9.73 American National Standard X9.73-2003 Cryptographic Message Syntax (CMS) X9.95 American National Standard X9.95-2005 Trusted Time Stamps X9.96 American National Standard X9.96-2004 Extended Markup Language (XML) Cryptographic Message Syntax (XCMS) RFC791 Internet Protocol, Darpa Internet Program, Protocol Specification, September 1981 RFC822 Standard for The Format Of ARPA Internet Text Messages, August 1982 RFC1035 Mockapetris, Domain Names - Implementation And Specification, November 1987 RFC2119 Bradner, S., Key Words for Use in RFCs to Indicate Requirement Levels, March 1997 RFC2253 Wahl, Kille, Howes, Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names, Dec 1997 RFC2396 Berners-Lee, Fielding, Masinter, Uniform Resource Identifiers (URI): Generic Syntax, August 1998 RFC2459 Housley, Ford, Polk, Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, January 1999 RFC3668 Bradner, S., Intellectual Property Rights in IETF Technology, BCP 79, February 2004 RFC3852 Housley, R., Cryptographic Message Syntax, July 2004 IS3166 ISO 3166 Country Codes – Maintenance Agency IS8601 ISO 8601 Data Elements And Interchange Formats – Information Interchange – Representation Of Dates And Times IS8824 ISO/IEC 8824-1:4 | ITU-T Recommendation X.680, Information Technology - Abstract Syntax Notation One (ASN.1) IS8825 ISO/IEC 8825-1:4 | ITU-T Recommendation X.690, Information Technology - ASN.1 Encoding Rules IS9834 ISO/IEC 9834-8 | ITU-T X.667 Information technology - Open Systems Interconnection – Procedures for the operation of OSI Registration Authorities IS10021 ISO/IEC 10021-4 | ITU-T X.411 Information technology – Message Handling Systems (MHS) IS18014 ISO/IEC 18014-1:3 Information technology – Security techniques – Time-stamping services Stapleton, et al. [Page 13] INTERNET DRAFT January 2006 FIPS197 Federal Information Processing Standards Publication 197 Advanced Encryption Standard (AES), November 2001 7.2 Informative References IEEE Stapleton, Doyle, Teppler Esq., Digital Signature Paradox, 6th IEEE Information Assurance Workshop, "The West Point Workshop", June 2005, United States Military Academy, West Point, New York ISSA Stapleton, Digital Signatures Are Not Enough, ISSA Journal, January 2006 SuiteB National Security Agency, Central Security Service, Information Assurance, Fact Sheet NSA Suite B Cryptography, www.nsa.gov/ia/ 8 Security Considerations This document recommends that application transaction packages are signed by the package content provider for purposes of authentication and encrypted for purposes of confidentiality; and that the application transaction is time stamped using trusted time stamp methods and procedures defined in [X9.95] for purposes of transaction integrity. This document further recommends that a digital signature is not relied upon for data integrity purposes. This document recommends that the encryption algorithm used for the encrypted trailer is the AES as defined in [FIPS197]. Further, this document recommends using AES-128 or AES-256 for future compatibility with the NSA [SuiteB] encryption algorithms. This document recommends that the digital signature algorithm used for the identity trailer is the elliptic curve digital signature algorithm (ECDSA) as defined in [X9.62]. Further, this document recommends using elliptic curves with 256 and 384-bit prime moduli for future compatibility with the NSA [SuiteB] encryption algorithms. This document recommends that the key agreement algorithm used with enveloped data in the encrypted trailer is the Elliptic Curve Diffie- Hellman or Elliptic Curve MQV. Further, this document recommends using elliptic curves with 256 and 384-bit prime moduli for future compatibility with the NSA [SuiteB] encryption algorithms. 9 IANA Considerations This document relies on a new OID arc registered with the IANA based on the X9.113 standard. Other implementations may require other domain specific arcs to be registered. Stapleton, et al. [Page 14] INTERNET DRAFT January 2006 10 IPR Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this document. Please address the information to the IETF at ietf- ipr@ietf.org. 11 Authors’ Addresses Jeff Stapleton Innove LLC 4801 NW Loop 410, Suite 365 Suite 365 San Antonio, TX 78229 jeff.stapleton@innove-us.com Phil Griffin Griffin Consulting 503 Oberlin Road, Suite 206 Cameron Village Raleigh, NC 27605 phil.griffin@asn-1.com Annex A: ASN.1 Module A.1 Introduction This normative Annex defines an ASN.1 schema for the enterprise management types and cryptographic types defined in this Document using the ASN.1 notation defined in the ISO/IEC 8824 series of international standards. ASN.1 notation is used to define the transaction messaging syntax in order to achieve interoperability and information exchenge between applications and to encourage common functionality in vendor product offerings to the financial industry. Stapleton, et al. [Page 15] INTERNET DRAFT January 2006 The single ASN.1 schema defined in this Document provides for both XML markup representations of enterprise management information and compact, efficient and reliable binary representations of the same information. The Distinguished Encoding Rules (DER) and a canonical variant of the XML Encoding Rules (XER) are specified for use in this Document to promote interoperability, consistent with the widespread and growing use of XML markup, and the broad availability of DER based cryptographic tool kits needed to secure enterprise management information. The object identifier ansi-x9-113 registered with the International Standards Organization (ISO) represents the tree containing all the information object identifiers defined in this Document, and has the following value: ansi-x9-113 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(113) } Only abstract syntax is defined here, not the concrete encodings of ASN.1 values for transfer between applications and devices. However, for applications that conform to this Document, such values shall be encoded according to the Distinguished Encoding Rules (DER) and XML Encoding Rules (XER) defined in ISO/IEC 8825. The cryptographic processing, key management techniques and Cryptographic Message Syntax (CMS) types used in these examples are defined in [X9.73] and [X9.96] and are expected to be in [IS22895]. A.2 Enterprise Management Schema The enterprise management, types, information objects, and information object sets are defined in this document, as follows: EnterpriseManagementSchema { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(113) modules(0) ems(0) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- X9.113 Enterprise Audit Management -- AuditManagement FROM EnterpriseAuditManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(113) modules(0) tc(1) am(7) } -- X9.113 Enterprise Authority Management -- AuthorityManagement FROM EnterpriseAuthorityManagement { Stapleton, et al. [Page 16] INTERNET DRAFT January 2006 iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(113) modules(0) tc(1) authm(3) } -- X9.113 Enterprise Compromise Management -- CompromiseManagement FROM EnterpriseCompromiseManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) cm(5) } -- X9.113 Enterprise Configuration Management -- ConfigurationManagement FROM EnterpriseConfigurationManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) config(1) } -- X9.113 Enterprise Initialization Management -- InitializationManagement FROM EnterpriseInitializationManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) im(6) } -- X9.113 Enterprise Inventory Management -- InventoryManagement FROM EnterpriseInventoryManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) ivm(4) } -- X9.113 Enterprise Key Management -- KeyManagement FROM EnterpriseKeyManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) kgen(0) } -- X9.113 Enterprise Policy Management -- PolicyManagement FROM EnterprisePolicyManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) pm(2) } Stapleton, et al. [Page 17] INTERNET DRAFT January 2006 -- X9.73 Cryptographic Message Syntax -- EnvelopedData, NamedKeyEncryptedData, SignedData FROM X973CryptographicMessageSyntax { iso(1) member-body(2) us(840) x973(10060) module(0) 1 } -- X9.95 Trusted Time Stamp -- TimeStampToken FROM TrustedTimeStamp { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) x9-95(95) module(0) tts(1) } -- ISO/IEC 10021-4 | ITU-T Rec X.411:06/1999 ORAddress FROM MTSAbstractService { joint-iso-itu-t mhs(6) mts(3) modules(0) mts-abstract-service(1) version-1999(1)} ; TrustedTransaction ::= SEQUENCE { version Version DEFAULT ver1, transaction EncodedTransaction, integrity TimeStampToken } EncodedTransaction ::= ENCODED-VALUE-OF.&Type( Transaction ) Transaction ::= SEQUENCE { version Version DEFAULT ver1, header Header, package Package, trailer Trailer } Version ::= INTEGER { ver1(1) } (ver1, ... ) Header ::= SEQUENCE { transactionCode TransactionCode, transactionNumber TransactionNumber, transactionCounter TransactionCounter OPTIONAL, messageRouting MessageRouting } TransactionCode ::= CONTENT.&id({TransactionSet}) TransactionNumber ::= INTEGER (0..MAX) TransactionCounter ::= INTEGER (0.65535) MessageRouting ::= SEQUENCE { receiverID EntityID, intermediaries Intermediaries OPTIONAL, senderID EntityID } Stapleton, et al. [Page 18] INTERNET DRAFT January 2006 Intermediaries ::= SEQUENCE SIZE(1..MAX) OF EntityID EntityID ::= SEQUENCE { domain Domain, qualifier Qualifier OPTIONAL, country ISO3166CountryCode OPTIONAL } Domain ::= CHOICE { directoryName DirectoryName, dnsName DNSName, ediPartyName EDIPartyName, ipAddress IPAddress, entityIdentifier EntityIdentifier, otherName OtherName, rfc822Name RFC822Name, uniformResourceIdentifier UniformResourceIdentifier, universalUniqueIdentifier UniversalUniqueIdentifier, x400Address ORAddress } Qualifier ::= RELATIVE-OID ISO3166CountryCode ::= PrintableString(SIZE(2)) DirectoryName ::= VisibleString (SIZE(1..MAX)) -- LDAP string format DNSName ::= VisibleString (SIZE(1..MAX)) (PATTERN "[A-Za-z0-9 .-]+") EDIPartyName ::= SEQUENCE { nameAssigner Party OPTIONAL, partyName Party } Party ::= UTF8String (SIZE(1..MAX)) IPAddress ::= OCTET STRING (SIZE(4..MAX)) EntityIdentifier ::= ENTITY.&id({Entities}) Entities ENTITY ::= { ... -- Expect additional information object identifiers -- } OtherName ::= SEQUENCE { oid OTHER-NAME.&id({OtherNames}), type OTHER-NAME.&Type({OtherNames}{@oid}) OPTIONAL } OTHER-NAME ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type OPTIONAL } Stapleton, et al. [Page 19] INTERNET DRAFT January 2006 WITH SYNTAX { OID &id [TYPE &Type] } OtherNames OTHER-NAME ::= { ... -- Defined as needed -- } RFC822Name ::= VisibleString (SIZE(1..MAX)) UniformResourceIdentifier ::= VisibleString (SIZE(1..MAX)) UniversalUniqueIdentifier ::= OCTET STRING (SIZE(16)) ORAddress ::= OCTET STRING (SIZE(80)) Package ::= CHOICE { plaintext [0] EncodedPlaintext, ciphertext [1] Ciphertext } EncodedPlaintext ::= ENCODED-VALUE-OF.&Type( Plaintext ) Plaintext ::= SEQUENCE { content TransactionCode, payload CONTENT.&Type({TransactionSet}{@content}) } TransactionSet CONTENT ::= { AuditManagement | AuthorityManagement | CompromiseManagement | ConfigurationManagement | InitializationManagement | InventoryManagement | KeyManagement | PolicyManagement, ... -- Expect additional objects -- } Ciphertext ::= ENCRYPTED{ EncodedPlaintext } ENCRYPTED{ ToBeEncrypted } ::= OCTET STRING (CONSTRAINED BY { -- the result of applying an encryption procedure to the cXER- -- or DER-encoded octets of a value of type -- ToBeEncrypted }) Trailer ::= SEQUENCE { encrypted Encrypted OPTIONAL, -- Encrypted Plaintext identity SignedData OPTIONAL -- Signed Plaintext } Encrypted ::= CHOICE { namedKey [0] NamedKeyEncryptedData, enveloped [1] EnvelopedData } Stapleton, et al. [Page 20] INTERNET DRAFT January 2006 -- Supporting definitions ALGORITHM ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type OPTIONAL } WITH SYNTAX { OID &id [PARMS &Type] } CONTENT ::= CLASS { &id ID UNIQUE, &Type OPTIONAL } WITH SYNTAX { ID &id [ TYPE &Type ] } ENCODED-VALUE-OF ::= TYPE-IDENTIFIER -- ISO/IEC 8824-2, Annex A ENTITY ::= TYPE-IDENTIFIER ID ::= RELATIVE-OID -- Alias OID ::= OBJECT IDENTIFIER -- Alias ansi-x9-113 OID ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) } modules OID ::= { ansi-x9-113 modules(0) } transaction-codes OID ::= { ansi-x9-113 tc(1) } examples OID ::= { ansi-x9-113 examples(2) } END -- EnterpriseManagementSchema – A.3 Audit management This section specifies the enterprise audit management, types, information objects, and information object sets defined in this document. EnterpriseAuditManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) am(7) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- X9.113 Enterprise Management Schema -- Stapleton, et al. [Page 21] INTERNET DRAFT January 2006 CONTENT, ID, OID, transaction-codes FROM EnterpriseManagementSchema { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) ems(0) } ; AuditManagement CONTENT ::= { auditAlarmNotice | auditAlarmRequest | auditAlarmResponse | auditAlarmAcknowlege | auditDeviceQueryNotice | auditDeviceQueryRequest | auditDeviceQueryResponse | auditDeviceQueryAcknowlege | auditDatabaseQueryNotice | auditDatabaseQueryRequest | auditDatabaseQueryResponse | auditDatabaseQueryAcknowlege, ... -- Expect additional objects -- } -- Audit alarm notice auditAlarmNotice CONTENT ::= { ID audit-alarm-notice TYPE AuditAlarmNotice } AuditAlarmNotice ::= SEQUENCE { auditSystem OBJECT IDENTIFIER, auditEvent OBJECT IDENTIFIER, auditParms OCTET STRING OPTIONAL } -- Audit alarm request auditAlarmRequest CONTENT ::= { ID audit-alarm-request TYPE AuditAlarmRequest } AuditAlarmRequest ::= OCTET STRING -- future work -- -- Audit alarm response auditAlarmResponse CONTENT ::= { ID audit-alarm-response TYPE AuditAlarmResponse } AuditAlarmResponse ::= OCTET STRING -- future work -- -- Audit alarm acknowlege auditAlarmAcknowlege CONTENT ::= { ID audit-alarm-acknowlege TYPE AuditAlarmAcknowlege } Stapleton, et al. [Page 22] INTERNET DRAFT January 2006 AuditAlarmAcknowlege ::= OCTET STRING -- future work -- -- Audit device query notice auditDeviceQueryNotice CONTENT ::= { ID audit-device-query-notice TYPE AuditDeviceQueryNotice } AuditDeviceQueryNotice ::= OCTET STRING -- future work -- -- Audit device query request auditDeviceQueryRequest CONTENT ::= { ID audit-device-query-request TYPE AuditDeviceQueryRequest } AuditDeviceQueryRequest ::= OCTET STRING -- future work -- -- Audit device query response auditDeviceQueryResponse CONTENT ::= { ID audit-device-query-response TYPE AuditDeviceQueryResponse } AuditDeviceQueryResponse ::= OCTET STRING -- future work -- -- Audit device query acknowlege auditDeviceQueryAcknowlege CONTENT ::= { ID audit-device-query-acknowlege TYPE AuditDeviceQueryAcknowlege } AuditDeviceQueryAcknowlege ::= OCTET STRING -- future work -- -- Audit database query notice auditDatabaseQueryNotice CONTENT ::= { ID audit-database-query-notice TYPE AuditDatabaseQueryNotice } AuditDatabaseQueryNotice ::= OCTET STRING -- future work -- -- Audit database query request auditDatabaseQueryRequest CONTENT ::= { ID audit-database-query-request TYPE AuditDatabaseQueryRequest } AuditDatabaseQueryRequest ::= OCTET STRING -- future work -- -- Audit database query response auditDatabaseQueryResponse CONTENT ::= { ID audit-database-query-response TYPE AuditDatabaseQueryResponse } Stapleton, et al. [Page 23] INTERNET DRAFT January 2006 AuditDatabaseQueryResponse ::= OCTET STRING -- FUTURE WORK -- -- Audit database query acknowlege auditDatabaseQueryAcknowlege CONTENT ::= { ID audit-database-query-acknowlege TYPE AuditDatabaseQueryAcknowlege } AuditDatabaseQueryAcknowlege ::= OCTET STRING -- FUTURE WORK -- -- Audit management transaction identifiers -- audit-management OID ::= { transaction-codes am(7) } audit-alarm OID ::= { audit-management aa(0) } audit-alarm-notice ID ::= { tc(1) am(7) aa(0) notice(0) } audit-alarm-request ID ::= { tc(1) am(7) aa(0) request(1) } audit-alarm-response ID ::= { tc(1) am(7) aa(0) response(2) } audit-alarm-acknowlege ID ::= { tc(1) am(7) aa(0) acknowlege(3) } audit-device-query OID ::= { audit-management adq(1) } audit-device-query-notice ID ::= { tc(1) am(7) adq(1) notice(0) } audit-device-query-request ID ::= { tc(1) am(7) adq(1) request(1) } audit-device-query-response ID ::= { tc(1) am(7) adq(1) response(2) } audit-device-query-acknowlege ID ::= { tc(1) am(7) adq(1) acknowlege(3) } audit-database-query OID ::= { audit-management adbq(2) } audit-database-query-notice ID ::= { tc(1) am(7) adbq(2) notice(0) } audit-database-query-request ID ::= { tc(1) am(7) adbq(2) request(1) } audit-database-query-response ID ::= { tc(1) am(7) adbq(2) response(2) } audit-database-query-acknowlege ID ::= { tc(1) am(7) adbq(2) acknowlege(3) } END -- EnterpriseAuditManagement -- A.4 Authority management This section specifies the enterprise authority management, types, information objects, and information object sets defined in this Document. EnterpriseAuthorityManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) authm(3) } Stapleton, et al. [Page 24] INTERNET DRAFT January 2006 DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- X9.113 Enterprise Management Schema -- CONTENT, ID, OID, transaction-codes FROM EnterpriseManagementSchema { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) ems(0) } ; AuthorityManagement CONTENT ::= { ... -- Expect additional objects -- } -- Authority management transactions authority-management OID ::= { transaction-codes authm(3) } END -- EnterpriseAuthorityManagement -- A.5 Compromise management This section specifies the enterprise compromise management, types, information objects, and information object sets defined in this document. EnterpriseCompromiseManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) cm(5) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- X9.113 Enterprise Management Schema -- CONTENT, ID, OID, transaction-codes FROM EnterpriseManagementSchema { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) ems(0) }; CompromiseManagement CONTENT ::= { ... -- Expect additional objects -- } -- Compromise management transactions compromise-management OID ::= { transaction-codes cm(5) } END -- EnterpriseCompromiseManagement -- Stapleton, et al. [Page 25] INTERNET DRAFT January 2006 A.6 Configuration management This section specifies the enterprise configuration management, types, information objects, and information object sets defined in this document. EnterpriseConfigurationManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) config(1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- X9.113 Enterprise Management Schema -- CONTENT, ID, OID, transaction-codes FROM EnterpriseManagementSchema { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) ems(0) }; ConfigurationManagement CONTENT ::= { ... -- Expect additional objects -- } -- Configuration management transactions -- configuration-management OID ::= { transaction-codes config(1) } END -- EnterpriseConfigurationManagement -- A.7 Initialization management This section specifies the enterprise initialzation management, types, information objects, and information object sets defined in this document. EnterpriseInitializationManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) im(6) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- X9.113 Enterprise Management Schema -- CONTENT, ID, OID, transaction-codes FROM EnterpriseManagementSchema { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) ems(0) }; Stapleton, et al. [Page 26] INTERNET DRAFT January 2006 InitializationManagement CONTENT ::= { ... -- Expect additional objects -- } -- Initialization management transactions initialization-management OID ::= { transaction-codes im(6) } END -- EnterpriseInitializationManagement -- A.8 Inventory management This section specifies the enterprise inventory management, types, information objects, and information object sets defined in this document. EnterpriseInventoryManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) ivm(4) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- X9.113 Enterprise Key Management -- ResponseCode FROM EnterpriseKeyManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) kgen(0) } -- X9.113 Enterprise Management Schema -- CONTENT, ID, OID, transaction-codes FROM EnterpriseManagementSchema { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) ems(0) }; InventoryManagement CONTENT ::= { inventoryDatabaseFileAcknowlege | inventoryDatabaseFileNotice | inventoryDatabaseFileRequest | inventoryDatabaseFileResponse | inventoryDatabaseQueryAcknowlege | inventoryDatabaseQueryNotice | inventoryDatabaseQueryRequest | inventoryDatabaseQueryResponse | inventoryDatabaseUpdateAcknowlege | inventoryDatabaseUpdateNotice | inventoryDatabaseUpdateRequest | inventoryDatabaseUpdateResponse | Stapleton, et al. [Page 27] INTERNET DRAFT January 2006 inventoryDeviceQueryAcknowlege | inventoryDeviceQueryNotice | inventoryDeviceQueryRequest | inventoryDeviceQueryResponse, ... -- Expect additional objects -- } -- Inventory database file messages -- Inventory database file transfer acknowlege inventoryDatabaseFileAcknowlege CONTENT ::= { ID inventory-database-file-acknowlege TYPE InventoryDatabaseFileAcknowlege } InventoryDatabaseFileAcknowlege ::= OCTET STRING -- FUTURE WORK -- -- Inventory database file transfer notice inventoryDatabaseFileNotice CONTENT ::= { ID inventory-database-file-notice TYPE InventoryDatabaseFileNotice } InventoryDatabaseFileNotice ::= OCTET STRING -- FUTURE WORK -- -- Inventory database file transfer request inventoryDatabaseFileRequest CONTENT ::= { ID inventory-database-file-request TYPE DeviceInformation } -- Inventory database file transfer response inventoryDatabaseFileResponse CONTENT ::= { ID inventory-database-file-response TYPE InventoryDatabaseFileResponse } InventoryDatabaseFileResponse ::= SEQUENCE { responseCode ResponseCode, databaseFile DBFile } DBFile ::= SEQUENCE SIZE(1..MAX) OF DeviceInformation -- Inventory database query messages -- Inventory database query acknowlege Stapleton, et al. [Page 28] INTERNET DRAFT January 2006 inventoryDatabaseQueryAcknowlege CONTENT ::= { ID inventory-database-query-acknowlege TYPE InventoryDatabaseQueryAcknowlege } InventoryDatabaseQueryAcknowlege ::= OCTET STRING -- FUTURE WORK -- -- Inventory database query notice inventoryDatabaseQueryNotice CONTENT ::= { ID inventory-database-query-notice TYPE InventoryDatabaseQueryNotice } InventoryDatabaseQueryNotice ::= OCTET STRING -- FUTURE WORK -- -- Inventory database query request inventoryDatabaseQueryRequest CONTENT ::= { ID inventory-database-query-request TYPE DeviceInformation } -- Inventory database query response inventoryDatabaseQueryResponse CONTENT ::= { ID inventory-database-query-response TYPE InventoryDatabaseQueryResponse } InventoryDatabaseQueryResponse ::= SEQUENCE { responseCode ResponseCode, databaseRecord DeviceInformation } -- Inventory database update messages -- Inventory database update acknowlege inventoryDatabaseUpdateAcknowlege CONTENT ::= { ID inventory-database-update-acknowlege TYPE InventoryDatabaseUpdateAcknowlege } InventoryDatabaseUpdateAcknowlege ::= OCTET STRING -- FUTURE WORK -- -- Inventory database update notice inventoryDatabaseUpdateNotice CONTENT ::= { ID inventory-database-update-notice TYPE InventoryDatabaseUpdateNotice } InventoryDatabaseUpdateNotice ::= OCTET STRING -- FUTURE WORK -- Stapleton, et al. [Page 29] INTERNET DRAFT January 2006 -- Inventory database update request inventoryDatabaseUpdateRequest CONTENT ::= { ID inventory-database-update-request TYPE DeviceInformation } -- Inventory database update response inventoryDatabaseUpdateResponse CONTENT ::= { ID inventory-database-update-response TYPE InventoryDatabaseUpdateResponse } InventoryDatabaseUpdateResponse ::= SEQUENCE { responseCode ResponseCode, databaseRecord DeviceInformation } -- Inventory device query messages -- Inventory device query acknowlege inventoryDeviceQueryAcknowlege CONTENT ::= { ID inventory-device-query-acknowlege TYPE InventoryDeviceQueryAcknowlege } InventoryDeviceQueryAcknowlege ::= OCTET STRING -- FUTURE WORK -- -- Inventory device query notice inventoryDeviceQueryNotice CONTENT ::= { ID inventory-device-query-notice TYPE InventoryDeviceQueryNotice } InventoryDeviceQueryNotice ::= OCTET STRING -- FUTURE WORK -- -- Inventory device query request inventoryDeviceQueryRequest CONTENT ::= { ID inventory-device-query-request TYPE InventoryDeviceQueryRequest } InventoryDeviceQueryRequest ::= NULL -- Inventory device query response inventoryDeviceQueryResponse CONTENT ::= { ID inventory-device-query-response TYPE InventoryDeviceQueryResponse } Stapleton, et al. [Page 30] INTERNET DRAFT January 2006 InventoryDeviceQueryResponse ::= SEQUENCE { responseCode ResponseCode, deviceInformation DeviceInformation } DeviceInformation ::= SEQUENCE { deviceType OCTET STRING, -- device type (what) deviceID OCTET STRING, -- device ID (who) deviceModel OCTET STRING, -- model number deviceOS OCTET STRING, -- operating system deviceLOC OCTET STRING, -- where are you netAddress OCTET STRING, -- network address keyTag KeyTag -- crypto information } -- Inventory management transaction identifiers inventory-management OID ::= { transaction-codes ivm(4) } inventory-device-query OID ::= { inventory-management idq(0) } inventory-device-query-notice ID ::= { tc(1) ivm(4) idq(0) notice(0) } inventory-device-query-request ID ::= { tc(1) ivm(4) idq(0) request(1) } inventory-device-query-response ID ::= { tc(1) ivm(4) idq(0) response(2) } inventory-device-query-acknowlege ID ::= { tc(1) ivm(4) idq(0) acknowlege(3) } inventory-database-query OID ::= { inventory-management idbq(1) } inventory-database-query-notice ID ::= { tc(1) ivm(4) idbq(1) notice(0) } inventory-database-query-request ID ::= { tc(1) ivm(4) idbq(1) request(1) } inventory-database-query-response ID ::= { tc(1) ivm(4) idbq(1) response(2) } inventory-database-query-acknowlege ID ::= { tc(1) ivm(4) idbq(1) acknowlege(3) } inventory-database-update OID ::= { inventory-management idbu(2) } inventory-database-update-notice ID ::= { tc(1) ivm(4) idbu(2) notice(0) } inventory-database-update-request ID ::= { tc(1) ivm(4) idbu(2) request(1) } inventory-database-update-response ID ::= { tc(1) ivm(4) idbu(2) response(2) } inventory-database-update-acknowlege ID ::= { tc(1) ivm(4) idbu(2) acknowlege(3) } inventory-database-file OID ::= { inventory-management idbf(3) } Stapleton, et al. [Page 31] INTERNET DRAFT January 2006 inventory-database-file-notice ID ::= { tc(1) ivm(4) idbf(3) notice(0) } inventory-database-file-request ID ::= { tc(1) ivm(4) idbf(3) request(1) } inventory-database-file-response ID ::= { tc(1) ivm(4) idbf(3) response(2) } inventory-database-file-acknowlege ID ::= { tc(1) ivm(4) idbf(3) acknowlege(3) } END -- EnterpriseInventoryManagement -- A.9 Key management This section specifies the enterprise key management, types, information objects, and information object sets defined in this document. EnterpriseKeyManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) kgen(0) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- X9.113 Enterprise Management Schema -- CONTENT, ID, OID, transaction-codes FROM EnterpriseManagementSchema { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) ems(0) } ; KeyManagement CONTENT ::= { keyBackupAcknowlege | keyBackupNotice | keyBackupRequest | keyBackupResponse | keyDistributionNotice | keyDistributionRequest | keyDistributionResponse | keyDistributionAcknowlege | keyGenerationAcknowlege | keyGenerationNotice | keyGenerationRequest | keyGenerationResponse | keyRecoveryAcknowlege | keyRecoveryNotice | keyRecoveryRequest | keyRecoveryResponse | Stapleton, et al. [Page 32] INTERNET DRAFT January 2006 keyRegisrationAcknowlege | keyRegisrationNotice | keyRegisrationRequest | keyRegisrationResponse | keyRevocationAcknowlege | keyRevocationNotice | keyRevocationRequest | keyRevocationResponse | keyTerminationAcknowlege | keyTerminationNotice | keyTerminationRequest | keyTerminationResponse, ... -- Expect additional objects -- } -- Key backup messages -- Key backup acknowledgement keyBackupAcknowlege CONTENT ::= { ID key-backup-acknowlege TYPE KeyBackupAcknowlege } KeyBackupAcknowlege ::= OCTET STRING -- FUTURE WORK -- -- Key backup notice keyBackupNotice CONTENT ::= { ID key-backup-notice TYPE KeyBackupNotice } KeyBackupNotice ::= OCTET STRING -- FUTURE WORK -- -- Key backup request keyBackupRequest CONTENT ::= { ID key-backup-request TYPE KeyBackupRequest } KeyBackupRequest ::= OCTET STRING -- FUTURE WORK -- -- Key backup response keyBackupResponse CONTENT ::= { ID key-backup-response TYPE KeyBackupResponse } KeyBackupResponse ::= OCTET STRING -- FUTURE WORK -- -- Key distribution messages -- Key distribution acknowledgement Stapleton, et al. [Page 33] INTERNET DRAFT January 2006 keyDistributionAcknowlege CONTENT ::= { ID key-distribution-acknowlege TYPE KeyDistributionAcknowlege } KeyDistributionAcknowlege ::= OCTET STRING -- FUTURE WORK -- -- Key distribution notice keyDistributionNotice CONTENT ::= { ID key-distribution-notice TYPE KeyDistributionNotice } KeyDistributionNotice ::= OCTET STRING -- FUTURE WORK -- -- Key distribution request keyDistributionRequest CONTENT ::= { ID key-distribution-request TYPE KeyDistributionRequest } KeyDistributionRequest ::= OCTET STRING -- FUTURE WORK -- -- Key distribution response keyDistributionResponse CONTENT ::= { ID key-distribution-response TYPE KeyDistributionResponse } KeyDistributionResponse ::= OCTET STRING -- FUTURE WORK -- -- Key generation messages -- Key generation acknowledgement keyGenerationAcknowlege CONTENT ::= { ID key-generation-acknowlege TYPE KeyGenerationAcknowlege } KeyGenerationAcknowlege ::= OCTET STRING -- FUTURE WORK -- -- Key generation notice keyGenerationNotice CONTENT ::= { ID key-generation-notice TYPE KeyGenerationNotice } KeyGenerationNotice ::= OCTET STRING -- FUTURE WORK -- -- Key generation request keyGenerationRequest CONTENT ::= { ID key-generation-request TYPE KeyGenerationRequest } Stapleton, et al. [Page 34] INTERNET DRAFT January 2006 KeyGenerationRequest ::= SEQUENCE SIZE(1..MAX) OF KeyTag KeyTag ::= SEQUENCE { keyType ALGORITHM.&id({KeyAlgorithms}), keyParms ALGORITHM.&Type({KeyAlgorithms}{@keyType}) OPTIONAL, keyUsage OBJECT IDENTIFIER, keySize KeySize OPTIONAL -- n-bit key } KeyAlgorithms ALGORITHM ::= { ... -- Expect additional objects -- } KeySize ::= INTEGER (minimumKeySize..MAX) minimumKeySize KeySize ::= 128 -- Key generation response keyGenerationResponse CONTENT ::= { ID key-generation-response TYPE KeyGenerationResponse } KeyGenerationResponse ::= SEQUENCE SIZE(1..MAX) OF KeyResult KeyResult ::= SEQUENCE { responseCode SEQUENCE SIZE(1..MAX) OF ResponseCode, keyTag KeyTag } ResponseCode ::= SEQUENCE { responseCodeType ResponseCodeType, responseCodeValue ResponseCodeValue } ResponseCodeType ::= OBJECT IDENTIFIER -- future work –- ResponseCodeValue ::= INTEGER { completerNoError (0), -- Processing completed with no errors completeWarning (1), -- Processing completed with warning incompletedError (2) -- Processing incomplete with error } (0..2, ... ) -- Key recovery messages -- Key recovery acknowlege keyRecoveryAcknowlege CONTENT ::= { ID key-recovery-acknowlege TYPE KeyRecoveryAcknowlege } KeyRecoveryAcknowlege ::= OCTET STRING -- FUTURE WORK -- Stapleton, et al. [Page 35] INTERNET DRAFT January 2006 -- Key recovery notice keyRecoveryNotice CONTENT ::= { ID key-recovery-notice TYPE KeyRecoveryNotice } KeyRecoveryNotice ::= OCTET STRING -- FUTURE WORK -- -- Key recovery request keyRecoveryRequest CONTENT ::= { ID key-recovery-request TYPE KeyRecoveryRequest } KeyRecoveryRequest ::= OCTET STRING -- FUTURE WORK -- -- Key recovery response keyRecoveryResponse CONTENT ::= { ID key-recovery-response TYPE KeyRecoveryResponse } KeyRecoveryResponse ::= OCTET STRING -- FUTURE WORK -- -- Key registration messages -- Key registration acknowlege keyRegisrationAcknowlege CONTENT ::= { ID key-regisration-acknowlege TYPE KeyRegisrationAcknowlege } KeyRegisrationAcknowlege ::= OCTET STRING -- FUTURE WORK -- -- Key registration notice keyRegisrationNotice CONTENT ::= { ID key-regisration-notice TYPE KeyRegisrationNotice } KeyRegisrationNotice ::= OCTET STRING -- FUTURE WORK -- -- Key registration request keyRegisrationRequest CONTENT ::= { ID key-regisration-request TYPE KeyRegisrationRequest } KeyRegisrationRequest ::= OCTET STRING -- FUTURE WORK -- -- Key registration response Stapleton, et al. [Page 36] INTERNET DRAFT January 2006 keyRegisrationResponse CONTENT ::= { ID key-regisration-response TYPE KeyRegisrationResponse } KeyRegisrationResponse ::= OCTET STRING -- FUTURE WORK -- -- Key revocation messages -- Key revocation acknowlege keyRevocationAcknowlege CONTENT ::= { ID key-revocation-acknowlege TYPE KeyRevocationAcknowlege } KeyRevocationAcknowlege ::= OCTET STRING -- FUTURE WORK -- -- Key revocation notice keyRevocationNotice CONTENT ::= { ID key-revocation-notice TYPE KeyRevocationNotice } KeyRevocationNotice ::= OCTET STRING -- FUTURE WORK -- -- Key revocation request keyRevocationRequest CONTENT ::= { ID key-revocation-request TYPE KeyRevocationRequest } KeyRevocationRequest ::= OCTET STRING -- FUTURE WORK -- -- Key revocation response keyRevocationResponse CONTENT ::= { ID key-revocation-response TYPE KeyRevocationResponse } KeyRevocationResponse ::= OCTET STRING -- FUTURE WORK -- -- Key termination messages -- Key termination notice keyTerminationNotice CONTENT ::= { ID key-termination-notice TYPE KeyTerminationNotice } KeyTerminationNotice ::= OCTET STRING -- FUTURE WORK -- Stapleton, et al. [Page 37] INTERNET DRAFT January 2006 -- Key termination request keyTerminationRequest CONTENT ::= { ID key-termination-request TYPE KeyTerminationRequest } KeyTerminationRequest ::= OCTET STRING -- FUTURE WORK -- -- Key termination response keyTerminationResponse CONTENT ::= { ID key-termination-response TYPE KeyTerminationResponse } KeyTerminationResponse ::= OCTET STRING -- FUTURE WORK -- -- Key management transaction identifiers key-management OID ::= { transaction-codes km(0) } key-generation OID ::= { key-management kgen(0) } key-generation-notice ID ::= { tc(1) km(0) kgen(0) notice(0) } key-generation-request ID ::= { tc(1) km(0) kgen(0) request(1) } key-generation-response ID ::= { tc(1) km(0) kgen(0) response(2) } key-generation-acknowlege ID ::= { tc(1) km(0) kgen(0) acknowlege(3) } key-registration OID ::= { key-management kreg(1) } key-registration-notice ID ::= { tc(1) km(0) kreg(1) notice(0) } key-registration-request ID ::= { tc(1) km(0) kreg(1) request(1) } key-registration-response ID ::= { tc(1) km(0) kreg(1) response(2) } key-registration-acknowlege ID ::= { tc(1) km(0) kreg(1) acknowlege(3) } key-distribution OID ::= { key-management kdis(2) } key-distribution-notice ID ::= { tc(1) km(0) kdis(2) notice(0) } key-distribution-request ID ::= { tc(1) km(0) kdis(2) request(1) } key-distribution-response ID ::= { tc(1) km(0) kdis(2) response(2) } key-distribution-acknowlege ID ::= { tc(1) km(0) kdis(2) acknowlege(3) } key-backup OID ::= { key-management kbac(3) } Stapleton, et al. [Page 38] INTERNET DRAFT January 2006 key-backup-notice ID ::= { tc(1) km(0) kbac(3) notice(0) } key-backup-request ID ::= { tc(1) km(0) kbac(3) request(1) } key-backup-response ID ::= { tc(1) km(0) kbac(3) response(2) } key-backup-acknowlege ID ::= { tc(1) km(0) kbac(3) acknowlege(3) } key-recovery OID ::= { key-management krec(4) } key-recovery-notice ID ::= { tc(1) km(0) krec(4) notice(0) } key-recovery-request ID ::= { tc(1) km(0) krec(4) request(1) } key-recovery-response ID ::= { tc(1) km(0) krec(4) response(2) } key-recovery-acknowlege ID ::= { tc(1) km(0) krec(4) acknowlege(3) } key-termination OID ::= { key-management kter(5) } key-termination-notice ID ::= { tc(1) km(0) kter(5) notice(0) } key-termination-request ID ::= { tc(1) km(0) kter(5) request(1) } key-termination-response ID ::= { tc(1) km(0) kter(5) response(2) } key-termination-acknowlege ID ::= { tc(1) km(0) kter(5) acknowlege(3) } key-revocation OID ::= { key-management krev(6) } key-revocation-notice ID ::= { tc(1) km(0) krev(6) notice(0) } key-revocation-request ID ::= { tc(1) km(0) krev(6) request(1) } key-revocation-response ID ::= { tc(1) km(0) krev(6) response(2) } key-revocation-acknowlege ID ::= { tc(1) km(0) krev(6) acknowlege(3) } END -- EnterpriseKeyManagement – A.10 Policy management This section specifies the enterprise policy management, types, information objects, and information object sets defined in this document. EnterprisePolicyManagement { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) tc(1) pm(2) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS Stapleton, et al. [Page 39] INTERNET DRAFT January 2006 -- X9.113 Enterprise Management Schema -- CONTENT, ID, OID, transaction-codes FROM EnterpriseManagementSchema { iso(1) identified-organization(3) tc68(133) country(16) x9(840) standards(9) ansi-x9-113(999) modules(0) ems(0) }; PolicyManagement CONTENT ::= { ... -- Expect additional objects -- } -- Policy management transaction identifiers policy-management OID ::= { transaction-codes pm(2) } END -- EnterprisePolicyManagement -- Annex B: Entity domain identification B.1 General For every name form used in the Domain type defined in Section 3.4 Message Routing, there shall be a name registration system or reliable process that ensures that any name used to identify an entity participating in the transaction, unambiguously identifies one and only one entity. The entity identification choice alternatives of type Domain are fully defined in this annex. Each choice alternative is presented in a separate section that includes a description of its syntax. B.2 Directory A value of the directoryName component of type Domain is an X.500- series directory name defined in the string format used to represent distinguished names in the Lightweight Directory Access Protocol (LDAP) as specified in [RFC2253]. The syntax for a directory domain name is defined as type DirectoryName. DirectoryName ::= VisibleString (SIZE(1..MAX)) -- LDAP string format Values of type DirectoryName may contain any of the national language characters supported by ASN.1 type UTF8String, but these characters must be escaped before inclusion in a valid directory name string. B.3 Domain Name System A value of the dnsName component of type Domain an Internet domain name defined in accordance with Internet [RFC1035]. The extensible Domain Name System (DNS) stores domain names in a network distributed database. The syntax for a DNS domain name is defined as type DNSName, as follows: Stapleton, et al. [Page 40] INTERNET DRAFT January 2006 DNSName ::= VisibleString (SIZE(1..MAX)) (PATTERN "[A-Za-z0-9 .-]+") Values of type DNSName are constrained to the subset of type of the ASCII characters that are not control characters, and which are valid for use in DNS names. Note that The VisibleString characters are a subset of the IA5String characters which are sometimes referred to as the ASCII or US ASCII characters. This may be because IA5String values include characters which look like and which have been assigned the names of the letters in the modern English alphabet. But these values can also be interpreted as coming from the Hawaiian alphabet or from Romaji, a written form of Japanese. B.4 Electronic Data Interchange (EDI) A value of the ediPartyName component of type Domain is typically the registered incorporated name. The syntax for an EDI party domain name is defined as type EDIPartyName. EDIPartyName ::= SEQUENCE { nameAssigner Party OPTIONAL, partyName Party } Party ::= UTF8String (SIZE(1..MAX)) B.5 Internet Protocol address A value of a ipAddress component of type Domain is an Internet Protocol (IP) domain name defined in accordance with Internet [RFC791]. The syntax for an IP domain name is defined as type IPAddress, as follows: IPAddress ::= OCTET STRING (SIZE(4..MAX)) Values of type IPAddress are constrained in size to be at least four octets (32 bit addresses). B.6 Registered identifier A value of a entityIdentifier component of type Domain is an IANA registered entity. The syntax for a registered information object identifier domain name is defined as type EntityIdentifier. EntityIdentifier ::= ENTITY.&id({Entities}) Entities ENTITY ::= { ... -- Expect additional information object identifiers -- } B.7 Alternative format A value of a otherName component of type Domain is any type for private or experimental use. The syntax for an alternative format Stapleton, et al. [Page 41] INTERNET DRAFT January 2006 domain name is defined as type OtherName, as follows: OtherName ::= SEQUENCE { oid OTHER-NAME.&id({OtherNames}), type OTHER-NAME.&Type({OtherNames}{@oid}) OPTIONAL } OTHER-NAME ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type OPTIONAL } WITH SYNTAX { OID &id [TYPE &Type] } OtherNames OTHER-NAME ::= ANY { ... -- Defined as needed -- } B.8 Internet electronic mail A value of a rfc822Name component of type Domain is an Internet electronic mail name defined in accordance with Internet [RFC822]. The syntax for an Internet electronic mail domain name is defined as type RFC822Name, as follows: RFC822Name ::= VisibleString (SIZE(1..MAX)) B.9 Uniform Resource Identifier A value of a uniformResourceIdentifier component of type Domain is a Uniform Resource Identifier (URI) defined in accordance with [RFC2396]. The syntax for a URI domain name is defined as type UniformResourceIdentifier, as follows: UniformResourceIdentifier ::= VisibleString (SIZE(1..MAX)) B.10 Universal Unique Identifier A value of a universalUniqueIdentifier component of type Domain is a sixteen octet universally unique identifier created by the process defined in ISO/IEC 9834-8 | ITU-T Rec. X.667 [IS9834]. The syntax for a Universal Unique Identifier (UUID) domain name is defined as type UniversalUniqueIdentifier, as follows: UniversalUniqueIdentifier ::= OCTET STRING (SIZE(16)) A UUID value can be represented as an information object identifier, a Universal Resource Name (URN) or as an opaque series of octets. In this document, UUIDs shall be represented as an opaque series of exactly sixteen octets B.11 O/R address A value of an x400Address component of type Domain is ???. The syntax for an ISO/IEC 10021-4 | X.411 [IS10021] O/R address domain name is Stapleton, et al. [Page 42] INTERNET DRAFT January 2006 defined as type ORAddress, as follows: ORAddress ::= SEQUENCE { built-in-standard-attributes BuiltInStandardAttributes, built-in-domain-defined-attributes BuiltInDomainDefinedAttributes OPTIONAL, extension-attributes ExtensionAttributes OPTIONAL } Stapleton, et al. [Page 2] INTERNET DRAFT January 2006 A value of type ORAddress contains extensible attrbutes. The built in standard attributes include a country name and administrative domain, organization and personal name and device identifiers. Full Copyright Statement Copyright (C) The Internet Society (2006). All Rights Reserved. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Stapleton, et al. [Page 43]