Extensible Markup Language Evidence Record Syntax (XMLERS)
Extracted elements (27)
Encryption information must be included in the Evidence Record because Evidence Records protect the bit-stream at the time of archiving and encryption schemes cannot be changed afterwards without losing the integrity proof. Only encryption methods that allow unambiguous proof that encrypted data represents original unencrypted data should be used.
The Order attribute is required for all sibling XML elements with the same name in the ArchiveTimeStampSequence structure because XML does not unambiguously define ordering of sibling elements, and correct order is critical for digest value calculations.
XMLERS does not present a direct transformation of ERS in ASN.1 syntax (RFC 4998) because XML processing rules and characteristics differ fundamentally from ASN.1. XMLERS is a standalone document based on RFC 4998 conceptually only, and does not support importing ASN.1 values in XML tags.
Both ArchiveTimeStampChain and ArchiveTimeStamp sequences MUST be sorted by time of the Time-Stamp in ascending order, with order indicated by the Order attribute.
Canonicalization MUST be applied over XML structured archive data and MUST be applied over elements of the Evidence Record (ATS and ATSC) in the renewing process. Algorithm identifiers (URIs) MUST be used as defined in RFC 3275 and RFC 4051.
During hash tree renewal, Archive Time-Stamp Chains and Archive Time-Stamps MUST be chronologically ordered and the canonicalization method C MUST be applied when calculating hash values from the binary representation of the ArchiveTimeStampSequence element.
During Time-Stamp renewal, the complete content of the last <TimeStamp> element MUST be Time-Stamped. The new ATS and its hash tree MUST use the same digest algorithm as the preceding one specified in the <DigestMethod> element.
For non-repudiation proof, the last Archive Time-Stamp MUST be valid at the time of the verification process. Each ATS MUST be valid relative to the time of the succeeding Archive Time-Stamp.
The ATS renewal process MUST continue during the desired archiving period of the archive data objects. A series of successive Archive Time-Stamps is collected in Archive Time-Stamp Chains, and a series of chains in an Archive Time-Stamp Sequence.
The <DigestValue> elements within each <Sequence> element MUST be ordered in binary ascending order to ensure correct digest value calculations at the time of renewal and verification.
The root hash value generated from the <HashTree> element MUST be the same as the Time-Stamped value. Hash values within each Sequence are base64-decoded, sorted in binary ascending order, concatenated, and hashed to produce the next level.
The selected secure hash algorithm MUST be the same as the hash algorithm used in the Time-Stamp Token and for the hash tree computations. The canonicalization method selected MUST also be used for archive data when data is represented in XML format.
The Version attribute MUST be included in the <EvidenceRecord> element to indicate the syntax version and ensure compatibility with future revisions. Current version is 1.0.
When a single Time-Stamp is obtained for a set of archive objects, the LTA MUST construct a hash tree to generate a single hash value binding all archive objects, and then a reduced hash tree MUST be calculated from the hash tree for each archive object respectively.
Within a single Archive Time-Stamp Chain, the digest algorithms used for the hash trees and the Time-Stamp Tokens MUST be the same. When TSA algorithms change, a new ATSC MUST be started using an equal or stronger digest algorithm.
An Evidence Record is represented by the <EvidenceRecord> XML root element containing optional <EncryptionInformation>, optional <SupportingInformationList>, and required <ArchiveTimeStampSequence>. It carries a required Version attribute (currently 1.0) and uses the XML namespace urn:ietf:params:xml:ns:ers.
The <CryptographicInformationList> element stores validation data (certificates, CRLs, OCSP responses, SCVP responses) needed to verify the Time-Stamp Token. Each item goes in a separate <CryptographicInformation> element with required Order and Type attributes. Type values (CRL, OCSP, SCVP, CERT) are IANA-registered and content is DER-encoded and base64-encoded.
The <EncryptionInformation> element is optional and stores parameters of encryption methods used for archive data. Its <EncryptionInformationType> stores the type of encryption information (e.g., algorithm or key) and <EncryptionInformationValue> holds the actual data.
The <TimeStamp> element holds a complete Time-Stamp Token as provided by a TSA. The TimeStampToken Type attribute MUST indicate the format ('RFC3161' or 'XMLENTRUST'). For RFC3161 type, the element MUST contain base64 encoding of a DER-encoded ASN.1 structure.
The XMLERS version numbering scheme is '<major>.<minor>' where both numbers are treated as separate integers. Leading zeros MUST be ignored by recipients and MUST NOT be sent. The major version increments only for format changes that break backward compatibility; the minor version increments for significant new optional capabilities.
This document creates the IANA registry 'XML Evidence Record Syntax (XMLERS)' with two sub-registries: 'Time-Stamp Token Type' (initial values: RFC3161, XMLENTRUST) and 'Cryptographic Information Type' (initial values: CERT, CRL, OCSP, SCVP). Both sub-registries use the 'RFC Required' policy. The XML namespace urn:ietf:params:xml:ns:ers and schema URN urn:ietf:params:xml:schema:ers are also registered.
Cryptographic algorithms used within Archive Time-Stamps must always be secure at the time of generation. Publications on security suitability of cryptographic algorithms (e.g., NIST SP 800-57, ETSI TS 102-176) must be considered during verification.
It is RECOMMENDED to generate and manage at least two redundant Evidence Records for a single data object, with redundant Evidence Records using different hash algorithms and different TSAs using different cryptographic algorithms for Time-Stamp Tokens, to mitigate the risk of algorithm weakening.
Renewed Archive Time-Stamps MUST have the same or higher quality as the initial Archive Time-Stamp of archive data. Archive Time-Stamps used for signed archive data SHOULD have the same or higher quality than the maximum quality of the signatures.
When a new Time-Stamp is applied during renewal, it MUST be ascertained that the certificate of the prior Time-Stamp was not revoked due to a key compromise before the renewal time. Data in <SupportingInformationList> added later must rely on its own authenticity and integrity protection mechanism such as a current strong cryptographic signature.
Archive Time-Stamp renewal has two distinct processes: Time-Stamp renewal (triggered when digest algorithm H equals H', new ATS added to the last ArchiveTimeStampChain) and Hash Tree renewal (triggered when H differs from H', new ATS placed in a new ArchiveTimeStampChain added to the existing ArchiveTimeStampSequence).
The <HashTree> element contains ordered <Sequence> elements each with one or more <DigestValue> elements containing base64-encoded hash values. DigestValue elements within each Sequence MUST be ordered in binary ascending order (by base64-decoded values).