ISO/IEC 18014-2:2009
(Main)Information technology — Security techniques — Time-stamping services — Part 2: Mechanisms producing independent tokens
Information technology — Security techniques — Time-stamping services — Part 2: Mechanisms producing independent tokens
ISO/IEC 18014-2:2009 presents a general framework for the provision of time-stamping services. Time-stamping services may generate, renew and verify time-stamp tokens. Time-stamp tokens are associations between data and points in time, and are created in a way that aims to provide evidence that the data existed at the associated date and time. In addition, the evidence may be used by non-repudiation services. ISO/IEC 18014-2:2004 specifies mechanisms that generate independent time-stamps: in order to verify an independent time-stamp token, verifiers do not need access to any other time-stamp tokens. That is, time-stamp tokens are not linked, as is the case for the token types defined in ISO/IEC 18014-3.
Technologies de l'information — Techniques de sécurité — Services d'horodatage — Partie 2: Mécanismes produisant des jetons indépendants
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 18014-2
Second edition
2009-12-15
Information technology — Security
techniques — Time-stamping services —
Part 2:
Mechanisms producing independent
tokens
Technologies de l'information — Techniques de sécurité — Services
d'horodatage —
Partie 2: Mécanismes produisant des jetons indépendants
Reference number
ISO/IEC 18014-2:2009(E)
©
ISO/IEC 2009
---------------------- Page: 1 ----------------------
ISO/IEC 18014-2:2009(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/IEC 2009
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/IEC 2009 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 18014-2:2009(E)
Contents Page
Foreword .iv
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
4 Notation, symbols and abbreviated terms.5
5 Time-stamping services.5
6 Time-stamp tokens.6
6.1 Contents .6
6.2 Notation .7
6.3 Verification .7
6.4 Renewal .8
6.5 Renewal verification.8
7 Protection mechanisms.9
8 Independent time-stamp tokens .10
8.1 Core structure.10
8.2 Extensions .10
8.3 Protection mechanisms.11
8.3.1 Digital signatures using SignedData.11
8.3.2 Message authentication codes using AuthenticatedData.11
8.3.3 Archival.13
8.3.4 Digital signatures using SignerInfo.13
8.4 Protocols .15
Annex A (normative) ASN.1 Module for Time-Stamping .16
Annex B (informative) Cryptographic Syntax .22
Bibliography.28
© ISO/IEC 2009 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 18014-2:2009(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 18014-2 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques.
This second edition cancels and replaces the first edition (ISO/IEC 18014-2:2002). The text has been revised
to clarify the presentation, and a new time-stamping mechanism has been added.
ISO/IEC 18014 consists of the following parts, under the general title Information technology ― Security
techniques — Time-stamping services:
⎯ Part 1: Framework
⎯ Part 2: Mechanisms producing independent tokens
⎯ Part 3: Mechanisms producing linked tokens
iv © ISO/IEC 2009 – All rights reserved
---------------------- Page: 4 ----------------------
INTERNATIONAL STANDARD ISO/IEC 18014-2:2009(E)
Information technology ― Security techniques —
Time-stamping services —
Part 2:
Mechanisms producing independent tokens
1 Scope
This part of ISO/IEC 18014 presents a general framework for the provision of time-stamping services.
Time-stamping services may generate, renew and verify time-stamp tokens.
Time-stamp tokens are associations between data and points in time, and are created in a way that aims to
provide evidence that the data existed at the associated date and time. In addition, the evidence may be used
by non-repudiation services.
This part of ISO/IEC 18014 specifies mechanisms that generate independent time-stamps: in order to verify
an independent time-stamp token, verifiers do not need access to any other time-stamp tokens. That is, time-
stamp tokens are not linked, as is the case for the token types defined in ISO/IEC 18014-3.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 8824-1:1998, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation
ISO/IEC 9594-8:2005, Information technology — Open Systems Interconnection — The Directory: Public-key
and attribute certificate frameworks
ISO/IEC 18014-1:2008, Information technology — Security techniques — Time-stamping services — Part 1:
Framework
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
asymmetric key pair
pair of related keys where the private key defines the private transformation and the public key defines the
public transformation
NOTE Adapted from ISO/IEC 9798-1.
© ISO/IEC 2009 – All rights reserved 1
---------------------- Page: 5 ----------------------
ISO/IEC 18014-2:2009(E)
3.2
asymmetric signature system
system based on asymmetric techniques whose private transformation is used for signing and whose public
transformation is used for verification
NOTE Adapted from ISO/IEC 9798-1.
3.3
authentication
provision of assurance of the claimed identity of an entity
NOTE Adapted from ISO/IEC 18028-4.
3.4
certification authority
CA
authority trusted by one or more users to create and assign public-key certificates
NOTE Optionally, the certification authority can create the users' keys.
[ISO/IEC 9594-8:2005, definition 3.3.16]
3.5
cryptography
discipline that embodies principles, means, and mechanisms for the transformation of data in order to hide its
information content, prevent its undetected modification and/or prevent its unauthorized use
[ISO/IEC 7498-2:1989, definition 3.3.20]
3.6
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[ISO/IEC 7498-2:1989, definition 3.3.21]
3.7
data origin authentication
corroboration that the source of data received is as claimed
[ISO/IEC 7498-2:1989, definition 3.3.22]
3.8
digital signature
data appended to, or a cryptographic transformation (see cryptography) of, a data unit that allows a recipient
of the data unit to prove the source and integrity of the data unit and protect against forgery, e.g. by the
recipient
[ISO/IEC 7498-2:1989, definition 3.3.26]
3.9
distinguished encoding rules
DER
encoding rules that may be applied to values of types defined using the ASN.1 notation
NOTE 1 As defined in the introduction to ISO/IEC 18028-4.
NOTE 2 Application of these encoding rules produces a transfer syntax for such values. It is implicit that the same rules
are also to be used for decoding. The DER is more suitable if the encoded value is small enough to fit into the available
memory and there is a need to rapidly skip over some nested values.
2 © ISO/IEC 2009 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC 18014-2:2009(E)
3.10
hash-function
function which maps strings of bits to fixed-length strings of bits, satisfying the following two properties:
⎯ it is computationally infeasible to find for a given output, an input which maps to this output
⎯ it is computationally infeasible to find for a given input, a second input which maps to the same output
NOTE Computational feasibility depends on the specific security requirements and environment.
[ISO/IEC 10118-1:2000, definition 3.5]
3.11
hash-value
string of bits which is the output of a hash-function
NOTE Adapted from hash-code as defined in ISO/IEC 10118-1.
3.12
message authentication code
MAC
string of bits which is the output of a MAC algorithm
NOTE A MAC is sometimes called a cryptographic check value (see for example ISO 7498-2).
[ISO/IEC 9797-1:1999, definition 3.2.4]
3.13
message authentication code (MAC) algorithm
algorithm for computing a function which maps strings of bits and a secret key to fixed-length strings of bits,
satisfying the following two properties:
⎯ for any key and any input string the function can be computed efficiently
⎯ for any fixed key, and given no prior knowledge of the key, it is computationally infeasible to compute the
function value on any new input string, even given knowledge of the set of input strings and
corresponding function values, where the value of the ith input string may have been chosen after
observing the value of the first i−1 function values
NOTE 1 A MAC algorithm is sometimes called a cryptographic check function (see for example ISO 7498-2).
NOTE 2 Computational feasibility depends on the user's specific security requirements and environment.
[ISO/IEC 9797-1:1999, definition 3.2.6]
3.14
private key
that key of an entity's asymmetric key pair which should only be used by that entity
[ISO/IEC 9798-1:1997, definition 3.3.17]
3.15
public key
that key of an entity's asymmetric key pair which can be made public
NOTE In the case of an asymmetric signature scheme the public key defines the verification transformation. In the
case of an asymmetric encipherment system the public key defines the encipherment transformation. A key that is
'publicly known' is not necessarily globally available. The key may only be available to all members of a pre-specified
group.
[ISO/IEC 11770-3:2008, definition 3.32]
© ISO/IEC 2009 – All rights reserved 3
---------------------- Page: 7 ----------------------
ISO/IEC 18014-2:2009(E)
3.16
public key certificate
public key information of an entity signed by the certification authority and thereby rendered unforgeable
[ISO/IEC 11770-3:2008, definition 3.33]
3.17
time-stamp requester
entity which possesses data it wants to be time-stamped
[ISO/IEC 18014-1:2008, definition 3.14]
3.18
time-stamp token
TST
data structure containing a verifiable cryptographic binding between a data item's representation and a time-
value
NOTE A time-stamp token can also include additional data items in the binding.
[ISO/IEC 18014-1:2008, definition 3.15]
3.19
time-stamp verifier
entity which possesses data and wants to verify that it has a valid time-stamp bound to it
NOTE The verification process can be performed by the verifier itself or by a trusted third party.
[ISO/IEC 18014-1:2008, definition 3.16]
3.20
time-stamping authority
TSA
trusted third party trusted to provide a time-stamping service
[ISO/IEC 18014-1:2008, definition 3.17]
3.21
time-stamping policy
named set of rules that indicates the applicability of a time-stamp token to a particular community or class of
application with common security requirements
3.22
time-stamping service
TSS
service providing evidence that a data item existed before a certain point in time
[ISO/IEC 18014-1:2008, definition 3.18]
3.23
time-stamping unit
TSU
set of hardware and software which is managed as a unit and generates time-stamp tokens
3.24
trusted third party
security authority, or its agent, trusted by other entities with respect to security related activities
[ISO/IEC 10181-1:1996, definition 3.3.30]
4 © ISO/IEC 2009 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC 18014-2:2009(E)
4 Notation, symbols and abbreviated terms
For the purposes of this document, the following notation and abbreviated terms apply.
logical conjunction, i.e. the and operator of Boolean algebra
∧
ASN.1 Abstract Syntax Notation One
CA certification authority
DER Distinguished Encoding Rules
H(D) hash-value calculated by applying the hash-function H to the data string D
i
i
HMAC hash message authentication code
isValid (TST(t), t ) predicate (i.e. true or false) indicating whether or not the token TST(t) is valid at time t
v v
MAC message authentication code
OID object identifier
PKI public key infrastructure
TSA time-stamping authority
TSS time-stamping service
TST time-stamp token
TST(t) time-stamp token created at time t
TSU time-stamping unit
t, t points in time
v
Hash-functions are specified in the multi-part standard ISO/IEC 10118.
MAC functions are specified in the multi-part standard ISO/IEC 9797.
The HMAC function is specified in ISO/IEC 9797-2.
5 Time-stamping services
Time-stamping services may generate, renew, and verify time-stamp tokens.
Time-stamp tokens are associations between data and points in time, and are created in a way that aims to
provide evidence that the data existed at the associated date and time. In addition, the evidence may be used
by non-repudiation services.
Time-stamping services involve the following entities (defined in ISO/IEC 18014-1):
⎯ the time-stamp requester, that has a document to time-stamp;
⎯ the Time-Stamping Authority (TSA), that generates time-stamp tokens (TSTs);
⎯ the time-stamp verifier, that verifies time-stamps bound to documents.
© ISO/IEC 2009 – All rights reserved 5
---------------------- Page: 9 ----------------------
ISO/IEC 18014-2:2009(E)
A time-stamping service (TSS) provides three specific services:
⎯ time-stamp generation, where the requester submits data items and receives a time-stamp
generated by the TSA;
⎯ time-stamp renewal, a special case of time-stamp generation, where the requester submits an
existing time-stamp and related data items and receives a new time-stamp generated by the TSA,
such that the validity period of the existing time-stamp is extended by the new time-stamp;
⎯ time-stamp verification, in which the verifier validates the time-stamp.
Time-stamping services are provided by means of two protocols, as defined in ISO/IEC 18014-1:
⎯ time-stamp request protocol: the requester requests the TSA to time-stamp a document or renew an
existing time-stamp for a document, and
⎯ time-stamp verification protocol: the verifier submits a time-stamp token to be verified.
6 Time-stamp tokens
6.1 Contents
A time-stamp token is a data structure containing a verifiable binding between a data item's representation
and a time-value. A time-stamp token may also bind additional items to the data item’s representation and the
time-value.
A time-stamp token shall contain
⎯ one or more hash-values of the data that is to be time-stamped; hash-functions are specified in the
multi-part standard ISO/IEC 10118;
⎯ a point in time (a time-value);
⎯ a reference to the policy under which the time-stamp token is generated.
together with any additional information that may be regarded as helpful for the practical provision of the
service, such as
⎯ identification of the time-stamping service provider (to help verifiers in looking for further evidence);
⎯ an indication of the accuracy of the time point (that is, the maximum error in the time representation);
⎯ an indication of ordering (that is, whether the service provider guarantees the relative ordering of
generated tokens);
⎯ identification of the version of the format (foreseeing syntax changes in the future);
⎯ a serial number (to enable reference to be made to the token);
1)
⎯ a reference to the user’s request , to help users in matching requests and responses.
1) Often referred to as a 'nonce', a number or bit string used only once, so that there is no ambiguity about what it is
referring to.
6 © ISO/IEC 2009 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC 18014-2:2009(E)
6.2 Notation
Let
H(D)
i
be a hash-value computed on data D using hash-function H .
i
Let
TST(t)
be a time-stamp token issued at the point in time t.
The time-stamp token TST(t) may be further decomposed into its parts:
2)
TST(t) := < { H (D) }, t , P >
i
3)
where { H (D) } is the set of one or more hash-values on data D. P indicates the policy under which the token
i
was generated.
6.3 Verification
Let t be the moment when the time-stamp token is verified, where t is measured by the entity performing the
v v
validity check.
The validity of a time-stamp token may be verified by checking that:
⎯ the time-stamp token is syntactically well-formed;
4)
⎯ t < t ;
v
⎯ the value of every component H (D) of the time-stamp token matches the hash-value of D evaluated
i
at t over the document subject to scrutiny, using the same hash-function H ;
v i
⎯ at least one of the hash-functions H is not broken at t ;
i v
⎯ the protection of the time-stamp token is technically sound when the time-stamp token is verified at
time t ; that is, the protection mechanism is not broken;
v
⎯ the issuing policy P is acceptable for the verifier's purposes.
If all the previous conditions hold, we say that the time-stamp token is valid at t . The following notation is
v
used for the predicate that evaluates whether a time-stamp token TST(t) is valid at t
v:
isValid (TST(t), t ) = true
v
The verifier may request additional assurance that is outside the scope of this standard.
2) The notation denotes a tuple, that is a sequence of values called the components of the tuple.
3) Each hash-value H(D) shall describe both the hash value and the hash-function used to derived it, altogether with any
i
additional information that might be needed for recreate the hash value in the future (e.g. hash-function parameters).
Hash-functions are standardised in ISO/IEC 10118. Use of hash-functions chosen from amongst those specified in
ISO/IEC 10118 is recommended.
4) The notation t < t indicates that 'time t is previous to time t ' according to the clock of the validating entity. Strict
1 2 1 2
precedence is not always mandatory, and a verifier may specify a tolerance or accepted error margin in time values; if
such a tolerance is used, it shall be a positive number, and it shall be stated in the verifier's practice statement. In such a
case, the mathematical formula becomes t - t < tolerance.
1 2
© ISO/IEC 2009 – All rights reserved 7
---------------------- Page: 11 ----------------------
ISO/IEC 18014-2:2009(E)
6.4 Renewal
A time-stamp generated at t is theoretically valid forever. However, in practice, a time limit should apply, for
0
example for one of the following reasons:
⎯ the strength of any of the underlying cryptographic primitives is under suspicion and is no longer
trusted;
⎯ the TSA’s signing key is about to expire;
⎯ the TSA is about to cease provision of a time-stamping service;
⎯ the policy specifies a time limit that is about to expire.
In such a case, a new time-stamp token is needed to extend the validity beyond the practical limits of the
original token. This new token, generated at t , may extend the previous bound t if generated using the
1 0
renewal architecture described below; that is, the new time-stamp token binds the point in time t to the data,
0
and is valid beyond t . In general, several time-stamp tokens may be part of a renewal chain
1
[ TST(t ) TST(t ) TST(t ) … TST(t ) … ] where t < t < t < … < t < …
0 1 2 i 0 1 1 i
that extends the validity of the binding to t an unlimited number of times.
0
In order to achieve this objective:
⎯ the new time-stamp token at t shall be generated before the previous time-stamp token expires;
i
⎯ the time-stamp token TST(t ) incorporates time-stamp token TST(t ) as part of the protected
i i-1
information;
⎯ the time-stamp request makes explicit the previous time-stamp token so that it can be incorporated
into the response;
⎯ the time-stamp verification shall extend over the chain of renewals.
6.5 Renewal verification
Let
[ TST(t ), TST(t ), …, TST(t ) ]
0 1 n
be a renewal chain, that is, an ordered list of time-stamp tokens:
⎯ which all refer to the same data item D;
⎯ for which the generation time is ordered; that is, t < t < … < t .
0 1 n
Let t be the moment when the time-stamp chain is verified.
v
The validity extension property states that
isValid ( [TST(t ), TST(t )], t ) = isValid (TST(t ), t ) ∧ isValid( TST(t ), t )
0 1 v 0 1 1 v
where
t < t < t
0 1 v
8 © ISO/IEC 2009 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/IEC 18014-2:2009(E)
That is, the first time-stamp token shall be valid when the second one is generated, and the second one shall
be valid when verification is carried out.
The validity of a time-stamp chain may be verified by iterating the previous procedure, i.e.:
isValid ( [TST(t ), …, TST(t )], t ) = isValid (TST(t ), t ) ∧ … ∧ isValid( TST(t ), t )
0 n v 0 1 n v
where
t < t < … < t < t
0 1 n v
If the verification is successful, then the verifier can conclude that data item D existed before time t .
0
The verifier shall also check that the issuing policy (or policies) is acceptable for its purposes.
The verifier may request additional assurance that is outside the scope of this standard.
7 Protection mechanisms
Time-stamp tokens may be protected by a variety of mechanisms, that may be chosen by the requester
and/or imposed by the service provider.
TSAs conformant with this part of ISO/IEC 18014 shall employ at least one of the three possible protection
mechanisms presented below. The first mechanism uses digital signatures to sign the time-stamp token. The
second mechanism uses a message authentication code (MAC) to authenticate the binding in a time-stamp
token, and the third mechanism is based on TSA archiving of information.
• The first mechanism involves asking the time-stamping service provider to digitally sign the binding of
the time to the document so that signature verification continues to validate the evidence.
• The second mechanism involves asking the time-stamping service provider to use a MAC to protect
the binding. The same secret is needed for MAC creation and for MAC verification, and this secret is
kept by the TSA. Therefore, the TSA is required for verification.
• The third mechanism involves asking the time-stamping service provider to archive the token, and only
publish a reference to the archive. Therefore, the TSA is required for archival and verification.
Time-stamping service users may select the mechanism to be used by means of the ExtMethod extension. If
5)
this extension is not present, the TSA uses its default time-stamping mechanism .
5) The ExtMethod extension should be omitted by users requesting the first mechanism, if compatibility with
IETF RFC3161-compliant TSAs is required.
© ISO/IEC 2009 – All rights reserved 9
---------------------- Page: 13 ----------------------
ISO/IEC 18014-2:2009(E)
8 Independent time-stamp tokens
8.1 Core structure
The following ASN.1 structures apply, as specified in ISO/IEC 18014-1:
TSTInfo ::= SEQUENCE {
version Version,
policy TSAPolicyId,
messageImprint MessageImprint,
serialNumber SerialNumber,
genTime GeneralizedTime,
accuracy Accuracy OPTIONAL,
ordering BOOLEAN DEFAULT FALSE,
nonce Nonce OPTIONAL,
tsa [0] EXPLICIT GeneralName OPTIONAL,
extensions [1] Extensions OPTIONAL
}
TSTInfo is encapsulated into TimeStampTokens:
TimeStampToken ::= SEQUENCE {
contentType CONTENT.&id({Contents}),
content [0] EXPLICIT CONTENT.&Type({Contents}{@contentType})
}
Content is built according to the protection mechanism. Possible values for the 'contentType' and 'content'
fields, and related data types for the 'content' field are presented in Clause 8.3.
Contents CONTENT ::= {
time-stamp-mechanism-signature
| time-stamp-mechanism-MAC
| time-stamp-mechanism-archival
| time-stamp-mechanism-signerinfo
-- Expect additional time-stamp mechanisms --
}
8.2 Extensions
Extensions are additional information that may be attached to either time-stamp requests or time-stamp
tokens.
Extensions are encoded into ASN.1 structures, and require identifying OIDs.
tss OBJECT IDENTIFIER ::= { iso(1) standard(0) 18014 }
tss-ext OBJECT IDENTIFIER ::= { tss 1 }
The following extensions apply, as specified in ISO/IEC 18014-1:
• ExtHash identified by
tss-ext-hash OBJECT IDENTIFIER ::= { tss-ext 1 }
• ExtMethod identified by
tss-ext-method OBJECT IDENTIFIER ::= { tss-ext 2 }
• ExtRenewal identified by
tss-ext-renewal OBJECT IDENTIFIER ::= { tss-ext 3 }
This standard does not define new extensions.
10 © ISO/IEC 2009 – All rights reserved
---------------------- Page: 14 ----------------------
ISO/IEC 18014-2:2009(E)
8.3 Protection mechanisms
8.3.1 Digital signatures using SignedData
The requester of the service may specify this mechanism using the ExtMethod extension that is specified in
the extensions field of the time-stamp request message, using the following object identifier:
tss-itm-ds OBJECT IDENTIFIER::= { tss-itm 1 }
A requester of this type of service may omit the ExtMethod extension if the TSA's default time-stamping
6)
mechanism is known to be the digital signature mechanism using SignedDa
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.