Digital cinema (D-cinema) operations — Part 1: Key delivery message

ISO 26430-1:2008 defines a “key delivery message” (KDM) for use in digital cinema systems. The KDM has been designed to deliver security parameters and usage rights between digital cinema content processing centres (e.g. from post production to distribution, or from distribution to exhibition). The KDM carries fundamentally three information types: content keys for a specified composition play list (CPL); content key parameters – primarily the permitted key usage date/time window; the trusted device list (TDL) which identifies equipment permitted to use the content keys.

Opérations du cinéma numérique (cinéma D) — Partie 1: Message de remise de clé

General Information

Status
Published
Publication Date
08-Jul-2008
Technical Committee
Drafting Committee
Current Stage
9020 - International Standard under periodical review
Start Date
15-Jul-2011
Completion Date
15-Oct-2022
Ref Project

Buy Standard

Standard
ISO 26430-1:2008 - Digital cinema (D-cinema) operations
English language
15 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

INTERNATIONAL ISO
STANDARD 26430-1
First edition
2008-07-15
Digital cinema (D-cinema) operations —
Part 1:
Key delivery message
Opérations du cinéma numérique (cinéma D) —
Partie 1: Message de remise de clé
Reference number
ISO 26430-1:2008(E)
ISO 2008
---------------------- Page: 1 ----------------------
ISO 26430-1:2008(E)
PDF disclaimer

This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but

shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In

downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat

accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.

Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation

parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In

the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

COPYRIGHT PROTECTED DOCUMENT
© ISO 2008

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,

electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or

ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2008 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 26430-1:2008(E)
Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies

(ISO member bodies). The work of preparing International Standards is normally carried out through ISO

technical committees. Each member body interested in a subject for which a technical committee has been

established has the right to be represented on that committee. International organizations, governmental and

non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the

International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of technical committees is to prepare International Standards. Draft International Standards

adopted by the technical committees are circulated to the member bodies for voting. Publication as an

International Standard requires approval by at least 75 % of the member bodies casting a vote.

ISO 26430-1 was prepared by the Society of Motion Picture and Television Engineers (as

SMPTE 430-1-2006) and was adopted, under a special “fast-track procedure”, by Technical Committee

ISO/TC 36, Cinematography, in parallel with its approval by the ISO member bodies.

ISO 26430 consists of the following parts, under the general title Digital cinema (D-cinema) operations:

⎯ Part 1: Key delivery message
⎯ Part 2: Digital certificate
⎯ Part 3: Generic extra-theater message format
© ISO 2008 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 26430-1:2008(E)
Introduction

The International Organization for Standardization (ISO) draws attention to the fact that it is claimed that

compliance with this document may involve the use of a patent.

ISO takes no position concerning the evidence, validity and scope of this patent right.

The holder of this patent right has assured ISO that he is willing to negotiate licences under reasonable and

non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of

the holder of this patent right is registered with ISO. Information may be obtained from:

Eastman Kodak Company
Intellectual Property Transactions
343 State Street
Rochester, NY 14650
USA

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent

rights other than those identified above. ISO shall not be held responsible for identifying any or all such patent

rights.
iv © ISO 2008 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
SMPTE STANDARD
D-Cinema Operations —
Key Delivery Message
Page 1 of 17 pages
Table of Contents Page

1 Scope .......................................................................................................................................................... 3

2 Normative References ................................................................................................................................ 3

3 Glossary ...................................................................................................................................................... 3

4 Overview of the KDM (Informative)............................................................................................................. 4

4.1 Basic KDM Elements and D-Cinema Relationships........................................................................... 4

4.2 XML Overview of the KDM ................................................................................................................. 6

5 Authenticated and Enencrypted Information............................................................................................... 6

5.1 Message Type .................................................................................................................................... 6

5.2 RequiredExtentions............................................................................................................................. 7

5.2.1 Receipt ..................................................................................................................................... 7

5.2.2 CompositionPlaylisted.............................................................................................................. 7

5.2.3 ContentTitleText....................................................................................................................... 7

5.2.4 ContentAuthenticalor (Optical)................................................................................................. 8

5.2.5 AuthorizedDeviceInfo............................................................................................................... 9

5.2.6 ContentKeysNotValidBefore .................................................................................................... 9

5.2.7 ContentKEysNotValidAfter....................................................................................................... 10

5.2.8 LeyIDList .................................................................................................................................. 10

5.2.9 ForensicMarkFlagList (Optional).............................................................................................. 10

5.3 NonCriticalExtensions......................................................................................................................... 11

6 Authenticated and Excrypted Information................................................................................................... 11

6.1 EncryptedKey...................................................................................................................................... 12

6.1.1 KenInfo..................................................................................................................................... 12

6.1.2 CipherData............................................................................................................................... 12

6.2 EncryptedData .................................................................................................................................... 13

7 Signature Information.................................................................................................................................. 13

Annex A Design Features and Secutiry Goals (Informative) ........................................................................ 14

Annex B Bibliography (Informative) .............................................................................................................. 15

Annex C XML Schema for KDM (Normative)................................................................................................ 16

Copyright © 2006 by THE SOCIETY OF
Approved
MOTION PICTURE AND TELEVISION ENGINEERS
October 3, 2006
3 Barker Avenue, White Plains, NY 10601
(914) 761-1100
© ISO 2008 – All rights reserved 1
---------------------- Page: 5 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
Foreword

SMPTE (the Society of Motion Picture and Television Engineers) is an internationally recognized standards

developing organization. Headquartered and incorporated in the United States of America, SMPTE has

members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards,

Recommended Practices and Engineering Guidelines, are prepared by SMPTE’s Technology Committees.

Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates

closely with other standards-developing organizations, including ISO, IEC and ITU.

SMPTE Engineering Documents are drafted in accordance with the rules given in Part XIII of its

Administrative practices.
SMPTE Standard 430-1 was prepared by Technology Committee DC28.
Page 2 of 17 pages
2 © ISO 2008 – All rights reserved
---------------------- Page: 6 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
1 Scope

This specification defines a “Key Delivery Message” (KDM) for use in Digital Cinema (D-Cinema) systems.

The KDM has been designed to deliver security parameters and usage rights between D-Cinema content

processing centers (e.g. from post production to distribution, or from distribution to exhibition). The KDM

carries fundamentally three information types:
• Content keys for a specified Composition Play List (CPL).
• Content key parameters – primarily the permitted key usage date/time window.

• The Trusted Device List (TDL) which identifies equipment permitted to use the content keys.

The KDM is based on the D-Cinema generic Extra-Theater Message (ETM) format [ETM]. It uses XML to

represent the information about the content decryption keys and TDLs, and provides security using

standardized XML encryption and signature primitives. The KDM message uses X.509 digital certificates,

specified in [D-Cinema Digital Certificate], to provide authentication and trust.

NOTE – The brackets convention “[…]” as used herein denotes either a normative or informative reference.

2 Normative References

The following standards contain provisions which, through reference in this text, constitute provisions of this

standard. At the time of publication, the editions indicated were valid. All standards are subject to revision,

and parties to agreements based on this standard are encouraged to investigate the possibility of applying the

most recent edition of the standards indicated below.
[KLV] SMPTE 429-6-2006, D-Cinema Packaging — MXF Track File Essence Encryption

[D-Cinema Digital Certificate] SMPTE 430-2-2006, D-Cinema Operations — Digital Certificate

[ETM] SMPTE 430-3-2006, D-Cinema Operations — Generic Extra Theater Message Format

[RFC2253] Lightweight Directory Access Protocol (v3):UTF-8 String Representation of Distinguished Names,

December 1997. See: http://www.ietf.org/rfc/rfc2253.txt

[Time] UTC, RFC 3339: Date and Time on the Internet: Timestamps. G. Klyne and C. Newman. Informational,

July 2002. See: http://ietf.org/rfc/rfc3339.txt
[UUID] “A Universally Unique Identifier (UUID) URN Namespace” July 2005. See:
http://www.ietf.org/rfc/rfc4122.txt
3 Glossary
The following paragraphs define the acronyms used in this standard.
AES: Advanced Encryption Standard secret key algorithm. See [FIPS-197].
ASN.1: Abstract Syntax Notation 1.
Base64: A printable encoding of binary data. See [Base64].
DES: Data Encryption Standard. See [FIPS-46-3].
ETM: Extra Theatre Message [See ETM]
FIPS: Federal Information Processing Standards of NIST.

HMAC-SHA-1: Hash-based Message Authentication Code based on SHA-1. See [FIPS-198].

IETF: Internet Engineering Task Force standards group.
Page 3 of 17 pages
© ISO 2008 – All rights reserved 3
---------------------- Page: 7 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
IP: Internet Protocol. An IETF standard.
ISO: International Standards Organization.
KEK: Key Encrypting Key
LE: Link Encrypter.
LD: Link Decrypter.
MD: Media Decrypter.
NIST: National Institute of Standards and Technologies.
OAEP: Optimal Asymmetric Encryption Pattern. See [PKCS1].
RO: Rights Owner.
RSA: Rivest Shamir Adleman public key algorithm.
SE: Security Entity. Any Digital Cinema entity that performs cryptography.
SHA-1: Secure Hash Algorithm revision 1. See [FIPS-180-2].
SHA-256: Secure Hash Algorithm. See [FIPS-180-2].
SM: Security Manager.
S/MIME: Secure Multipurpose Internet Mail Extensions.
SPB: Secure Processing Block.

TCP: Transmission Control Protocol. IETF standard for reliable bi-directional streams.

TDES: Triple DES. See [FIPS-43-3].
TLS: Transport Layer Security protocol. See [Rescorla].
TMS: Theater Management System.
X.509. A widely used and supported digital certificate standard.
XML: Extensible Markup Language.
4 Overview of the KDM (Informative)
4.1 Basic KDM Elements and D-Cinema Relationships

This standard presents a specification for the Key Delivery Message (KDM) for use in a Digital Cinema (D-

Cinema) system. The D-Cinema Key Delivery Message is normally sent:
1. Between a post-production system and a Distributor, or
2. Between a Distributor and a Theater facility.

D-Cinema systems require that content keys, key usage time window (key parameters) and “trusted

equipment” information (Trusted Device List or TDL) be communicated to exhibition facilities. The KDM

carries all the critical information required to enable content decryption according to a baseline interoperable

security standard. The basic form of the KDM is shown in figure 1.

Access to the full information payload of the KDM requires knowledge of the targeted recipient’s private key.

Having this key, the legitimate recipient may unlock and validate both encrypted and plain text information

contents carried. As is explained further in the appropriate sections of this document, the structure of the KDM

has been designed to allow this without the recipient having stores of root certificates. To preserve intended

security, full KDM information access should only take place within a secure environment (e.g., within a D-

Cinema Secure Processing Block). KDMs can, however, be authenticated by insecure devices if such devices

have copies of the root certificate of the entity that created and signed the KDM.

The KDM uses XML to represent the information about content decryption keys and provides security using

the XML Encryption and Signature primitives. To facilitate efficient processing with hardware security chips,

the KDM individually encrypts each content key (along with other information) with RSA, and is structured to

allow KDMs to be processed by devices that have limited resources of physically secure memory.

Page 4 of 17 pages
4 © ISO 2008 – All rights reserved
---------------------- Page: 8 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
Recipient Recipient
Public Key Private Key
Content Keys Content Keys
Key Delivery
& Parameters & Parameters
Message
Issuer Recipient
TDL TDL
Issuer Issuer
Private Key Public Key
Figure 1 – KDM Information Flow

The KDM message is a particular instance of the generic XML security wrapper defined by the D-Cinema

Generic Extra Theatre Message Format [ETM] and uses digital certificates defined by the D-Cinema Digital

Certificate specification. This document defines the characteristics that are specific to the KDM, and should

be followed in combination with [ETM], which in turn references the digital certificate specification.

The relationship between the KDM and the Composition Play List (CPL) is shown in figure 2.

CPL KDM
Id Message Id
Composition
Play
Track File Asset
Key Id
Key Id List
Key Id
Track File Asset
Key Id
Key Id
EncryptedKey
Key Id
Key Value
EncryptedKey
Key Id
Key Value
Figure 2 – Linking Between CPL and KDM Structures
Page 5 of 17 pages
© ISO 2008 – All rights reserved 5
---------------------- Page: 9 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006

Each CPL is identified by a globally unique value [UUID] that appears in the element named “Id” in the top-

level XML structure for a CPL. There are other elements in the CPL that are also called “Id”, such as the

identifier for a track file, though these are not the identifier of the whole CPL itself. The KDM contains an

element named “CompositionPlaylistId” whose value matches the UUID of the CPL for which it carries keys.

The CPL identifies the (optional) key associated with each track file by a UUID in an element called “KeyId”.

The KDM has matching elements called KeyId. An unencrypted list of the KeyId values that are carried in the

KDM appears in the first part of the KDM. The actual key values (and their matching KeyId) appear in an

encrypted portion of the KDM that can only be decrypted by the intended recipient (typically a Security

Manager in an exhibition facility).
4.2 XML Overview of the KDM

NOTE – The XML figures shown in this specification are informative. See Annex C for the normative XML schema that

defines the KDM. The XML diagrams in this document conform to the legend given in [ETM].

A KDM is an ETM instance which has in the RequiredExtensions element a child element named

KDMRequiredExtensions (defined below), and which also makes use of the AuthenticatedPrivate element of

the ETM to store content encryption keys.

The KDMRequiredExtensions element contains information that must be visible without decryption in order to

properly handle the KDM within D-Cinema systems. The information made available in this element includes

a list of the Content Key Ids (but not the value of those keys) in the message.

The AuthenticatedPrivate portion contains a collection of content decryption keys each encrypted in an

EncryptedKey element. These RSA encrypted elements also include the KeyId and validity dates for each

content key. The optional EncryptedData element defined in [ETM] is not used by the KDM. A KDM has a

single recipient, so all the EncryptedKey elements can be decrypted with the same RSA private key.

The Signature element defined in [ETM] carries the signer’s certificate chain and protects the integrity and

authenticity of the AuthenticatedPublic portion and the AuthenticatedPrivate portion (both plaintext and

ciphertext versions). The Signature section is not authenticated, though it is believed if an attacker made any

beneficial modifications to the Signature section, then the authentication of the other sections would fail.

A single KDM can carry multiple content decryption keys for the same content (the same

CompositionPlaylistId), and a Composition Play List may require keys that are carried in multiple KDMs. For

example, a separate KDM could be used to deliver content keys for region-specific dialog tracks.

5 Authenticated and Unencrypted Information

The KDM extends the ETM by including the KDMRequiredExtensions element (see Figure 4 below) in its

RequiredExtensions element. The normative schema is defined in annex C. The information in the

AuthenticatedPublic element of the ETM (and thus, KDM) is digitally signed, and trust in the signature can be

verified using the certificate chain in the Signature portion. This element is not encrypted, so any entity that

has access to the message can extract this information. The word “public” that appears in the XML label for

this element means that any entity that receives the message can view this portion.

The certificate chain is part of the information that is protected by the digital signature, which reduces the risk

of an attacker who is able to create a small number of legitimate certificates (e.g., through social engineering).

The following sections describe the elements in this portion.
5.1 MessageType

The MessageType field is defined in [ETM]. In a KDM, this field shall contain the following URI:

http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type
Page 6 of 17 pages
6 © ISO 2008 – All rights reserved
---------------------- Page: 10 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
5.2 RequiredExtentions

The RequiredExtentions element of the KDM shall contain exactly one KDMRequiredExtensions element, as

defined in Annex C and illustrated in figure 3. The KDMRequiredExtensions element shall have the following

child elements:
5.2.1 Recipient

The Recipient field shall identify the intended certificate/subject of this KDM. The public key identified in this

certificate is used to encrypt the keys found in the AuthenticatedPrivate portion of the KDM message. An

X.509 certificate is identified by the name of the Certificate Authority (CA) that issued it, called IssuerName,

and the unique serial number assigned by the CA, called SerialNumber. To aid in routing of KDMs, the X.509

SubjectName that is found in the certificate shall also be placed in the Recipient element. The Distinguished

Name value in the X509IssuerName element shall be compliant with RFC 2253 [RFC2253].

5.2.2 CompositionPlaylistId

This field contains a machine-readable identifier for the Rights Owner’s content (such as a Composition

Playlist). It is a 128-bit UUID represented in “urn:uuid:” format when used with XML [UUID].

This is an informational field that is a copy of the definitive value that appears in the RSA protected

EncryptedKey structure. It may be ignored by mechanisms that process the EncryptedKey field.

5.2.3 ContentTitleText

The ContentTitleText parameter shall contain a human-readable title for the composition; e.g., When Pigs Will

Fly II. It is strictly meant as a display hint to the user. The optional language attribute is an ISO 3166 language

code and indicates the language used. If the language attribute is not present, the content of the field shall be

English.
Page 7 of 17 pages
© ISO 2008 – All rights reserved 7
---------------------- Page: 11 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
Figure 3 – KDMRequiredExtensions Element (Informative)
5.2.4 ContentAuthenticator (Optional)

This field, if present, shall contain a certificate thumbprint (defined in [D-Cinema Digital Certificate]) that

supports authentication of the content as an authorized version (e.g. through a Composition Playlist [CPL]).

This field may be absent at the discretion of the KDM creator (who acts on behalf of the rights owner), but it is

part of the RequiredExtentions elements because compliant receiving equipment is required to understand

and process it when present.
Page 8 of 17 pages
8 © ISO 2008 – All rights reserved
---------------------- Page: 12 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
INFORMATIVE NOTES

1 If this field is present, then it is intended that the recipient crosscheck the certificate chain for the signer of the CPL

against this value. Specifically, one of the certificates in the signer chain of the CPL should have a certificate thumbprint

that matches this field in the KDM.

2 This field facilitates the business requirement of allowing an exhibitor to show content produced by a wide range of

studios without needing to have a business relationship with all those studios (e.g., without needing to know the root

certificates for all studios). The exhibitor has a relationship with a set of distributors (and knows their root certificates), and

the distributors in turn have relationships with studios. To support business flexibility, the ContentAuthenticator is not

necessarily the thumbprint of the studio’s root certificate.

3 Of course, nothing precludes an exhibitor from knowing the root certificates of specific studios and using those

certificates as part of validating CPL.
5.2.5 AuthorizedDeviceInfo
This item contains three elements as described below.

INFORMATIVE NOTE – This field is intended to support authorization of devices which process keys delivered by the

KDM, or perform other security services related to content protected by those keys. The AuthorizedDeviceInfo field does

not play any role in validating the KDM itself. This field facilitates the dual business requirements of (a) allowing exhibition

equipment to be implemented as multiple secure devices (e.g. image media block, sound media block, projector) and (b)

allowing a rights owner to limit delivery of his content or keys to specific trustworthy devices.

5.2.5.1 DeviceListIdentifier

This field shall contain a value uniquely identifying a list of trusted equipment. It is a required member of the

AuthorizedDeviceInfo structure.

INFORMATIVE NOTE – This field is an aid to management of device lists and tracking of updates to them.

5.2.5.2 DeviceListDescription (Optional)

The DeviceListDescription parameter, where present, shall contain a human-readable title description of the

device list, e.g. “Bigtown Multiplex facility equipment list updated June 20, 2006”. It is strictly meant as a

display hint to the user. The optional language attribute is an ISO 3166 language code and indicates the

language used. If the language attribute is not present, the content of the field shall be English.

5.2.5.3 DeviceList

The DeviceList item shall contain a set of one or more certificate thumbprints [See D-Cinema Certificate].

INFORMATIVE NOTE – Each entry typically represents a specific device which is authorized for use in connection with

some of the keys in this KDM. However, the normative behavior of receiving equipment is outside the scope of this

standard.
5.2.6 ContentKeysNotValidBefore

This field specifies the time before which the content keys contained in this KDM are not valid. The time shall

be in the form of a Universal Coordinated Time timestamp as specified in RFC 3339. Timestamps shall not

include fractional seconds. It is possible for a separate KDM to provide a different time window for the same

keys (e.g., to allow a pre-view showing, or to extend an engagement).

This is an informational field that is a copy of the definitive value that appears in the RSA protected

EncryptedKey structure. It may be ignored by mechanisms that process the EncryptedKey field. The time

windows of all content keys shall be the same in the RSA protected blocks.
Page 9 of 17 pages
© ISO 2008 – All rights reserved 9
---------------------- Page: 13 ----------------------
ISO 26430-1:2008(E)
SMPTE 430-1-2006
5.2.7 ContentKeysNotValidAfter

This field specifies the time after which the content keys contained in this KDM are not valid. The time shall be

in the form of a Universal Coordinated Time timestampas specified in RFC 3339. Timestamps shall not

include fractional seconds. It is possible for a separate KDM to provide a different time window for the same

keys (e.g., to allow a pre-view showing, or to extend an engagement).

This is an informational field that is a copy of the definitive value that appears in the RSA protected

EncryptedKey structure. It may be ignored by mechanisms that process the EncryptedKey field. The time

windows of all content keys shall be the same in the RSA protected blocks.
5.2.8 KeyIdList

This field shall contain an unordered list of one or more TypedKeyId elements, which are defined below. This

is an informational field that is a copy of the definitive values that appear in the RSA protected EncryptedKey

structures (see 6.1). It may be ignored by mechanisms that process the EncryptedKey field.

5.2.8.1 KeyId

KeyIds are 128-bit UUIDs that shall be represented in “urn:uuid:” format when they appear as an XML value

[UUID]. The KeyId parameter uniquely identifies the content decryption key. All keys shall be for use with the same

content (identified by the CompositionPlaylistId field). As shown below, it shall be used to identify the cryptographic

key used in encrypting d-cinema assets, as defined by [KLV]. It shall be represented by a UUID [UUID].

5.2.8.2 TypedKeyId

A TypedKeyId is a compound element consisting of a KeyType field and a KeyId. The KeyType shall be a

string of characters, further constrained as described below. The KeyType distinguishes keys targeted to

different types of devices (e.g. image media decryptor, sound media decryptor). The KeyID shall be as

defined in 5.2.8.1. Binding a KeyType to each KeyId assists in defending against cross-system attacks.

The KeyType element shall contain a symbol composed of four (4) characters from the set of 52 upper and

lower case ASCII letters A-Z (0x41-0x5A) and a-z (0x61-0x7A).
The KeyType elemen
...

Questions, Comments and Discussion

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