BSI Technical Guideline 03125 Preservation of Evidence of Cryptographically Signed Documents Annex TR-ESOR-ERS: EvidenceRecord Profiling pursuant to RFC4998 and RFC6283 (Conformity Level 2 - Technical Conformity) Designation
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283 (Conformity Level 2 - Technical Conformity)
Abbreviation Version Date
BSI TR-ESOR-ERS 1.2 19.12.14
Some parts of the document are not barrier-free.
Preservation of Evidence of Cryptographically Signed Documents (TR-ESOR)
Federal Office for Information Security P.O.B. 20 03 63 D-53133 Bonn (Germany) Phone: +49 228 99 9582-0 E-mail:
[email protected] Internet: https://www.bsi.bund.de © Federal Office for Information Security (BSI) 2014 Federal Office for Information Security
BSI TR 03125
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
Table of contents 1. Introduction........................................................................................................................................5 2. Overview............................................................................................................................................7 3. EvidenceRecord profiling (normative)...............................................................................................8 3.1. Introduction.....................................................................................................................................8 3.2. Definition of the degree of obligation..............................................................................................8 3.3. Structures of an EvidenceRecord pursuant to the Basic-ERS-Profile..............................................9 3.3.1. EvidenceRecord type....................................................................................................................9 3.3.1.1. ArchiveTimeStampSequence type and ArchiveTimeStampChain type............................9 3.3.1.2. ArchiveTimeStamp type and PartialHashtree type.........................................................10 3.4. Rules for the TimeStampToken in the ASN.1 format.....................................................................12 3.4.1. TimeStampToken type................................................................................................................12 3.4.2. SignedData type..........................................................................................................................13 3.4.2.1. EncapsulatedContentInfo type.......................................................................................14 3.4.2.2. CertificateSet type and RevocationInfoChoices type.....................................................15 3.4.3. SignerInfo type...........................................................................................................................17 3.4.4. Signed attributes.........................................................................................................................20 3.5. Creating an EvidenceRecord..........................................................................................................22 3.5.1. Handling the archive time stamp................................................................................................22 3.6. Verifying an EvidenceRecord........................................................................................................23 4. Annex A: Profile overview (normative)............................................................................................25 4.1. Basic-ERS-Profile – overview.......................................................................................................25 5. Annex B: Requirements for cryptographic algorithms and parameters (normative).........................27 5.1. Creating an EvidenceRecord pursuant to Basic-ERS-Profile.........................................................27 5.1.1. Hash algorithms..........................................................................................................................27 5.1.2. Signature algorithms...................................................................................................................27 5.2. Verifying an EvidenceRecord........................................................................................................27 5.2.1. Hash algorithms..........................................................................................................................28 5.2.2. Signature algorithms...................................................................................................................28 5.2.3. ESSCertIDv2 and ESSCertID.....................................................................................................29 6. Annex C: Further ERS profiles (informative)...................................................................................30 6.1. Structure of an EvidenceRecords pursuant to the Basic-XERS-Profile.........................................30 6.2. Time stamp renewal using ATSv3 (only CMS-based)....................................................................32 6.2.1. Use of ATSv3..............................................................................................................................32 6.2.2. archive-time-stamp-v3 attribute (ATSv3)...................................................................................33 6.2.3. ats-hash-index attribute...............................................................................................................34 7. Annex D Syntax definitions (informative)........................................................................................37 7.1. Evidence records pursuant to [RFC4998]......................................................................................37 7.1.1. EvidenceRecord element pursuant to [RFC4998].......................................................................37 7.1.2. ArchiveTimeStamp element pursuant to [RFC4998]..................................................................37 7.1.3. ArchiveTimeStampChain and ArchiveTimeStampSequence pursuant to [RFC4889].................37 7.2. Evidence records pursuant to [RFC6283]......................................................................................37 7.2.1.
element pursuant to [RFC6283]..................................................................38
Federal Office for Information Security
3
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283 7.2.2. element pursuant to [RFC6283].............................................................................38 7.2.3. element pursuant to [RFC6283]..........................................................................39
4
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
1. Introduction The goal of the Technical Guideline "Preservation of Evidence of Cryptographically Signed Documents" is to specify security-related requirements for the long-term preservation of evidence of cryptographically signed electronic documents and data along with associated electronic administrative data (meta data). A Middleware defined for this purpose (TR-ESOR-Middleware) in the sense of this Technical Guideline includes all the modules (M) and interfaces (S) ["S" for the German word "Schnittstellen"] used for securing and preserving the authenticity and proving the integrity of the stored documents and data. The Reference Architecture introduced in the Main Document of this Technical Guideline consists of the functions and logical units described below: • The S.4 input interface of the TR-ESOR-Middleware which serves to embed the TR-ESOR-Middleware in the existing IT and infrastructure landscape; • The "ArchiSafe-Module" (see [TR-ESOR-M.1]) which regulates the flow of information in the Middleware, implements the security requirements for the interfaces with the IT applications and ensures that the application systems are decoupled from the ECM/Long-Term Storage; • The "Cryptographic-Module" (see [TR-ESOR-M.2]) and the associated S.1 and S.3 interfaces that provide all the functions needed for creating (optional) and verifying electronic signatures, post-verifying electronic certificates and for obtaining qualified time stamps for the Middleware. Furthermore, it can provide functions for the encryption and decryption of data and documents; • The "ArchiSig-Module" (see [TR-ESOR-M.3]) with the S.6 interface that provides the functions needed for the preservation of evidence of the digitally signed documents; • An ECM/Long-Term Storage with the S.2 and S.5 interfaces that assumes the physical archiving/storage and also the storage of the meta data that preserve evidence. This ECM/Long-Term Storage is no longer directly a part of the Technical Guideline, but requirements will be set for it through the two interfaces that are still part of the TR-ESOR-Middleware. The application layer that can include an XML adapter is not a direct part of the Technical Guideline either, even though this XML adapter can be implemented as part of a Middleware. The IT Reference Architecture depicted in Figure 1 is based on the ArchiSafe1 Reference Architecture and is supposed to make possible and support the logical (functional) interoperability of future products with the goals and requirements of the Technical Guideline.
1
For further information, see http://www.archisafe.de.
Federal Office for Information Security
5
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
Figure 1: Schematic depiction of the IT Reference Architecture
This Technical Guideline has a modular design and the individual annexes to the Main Document specify the functional and security-related requirements for the needed IT components and interfaces of the TR-ESOR-Middleware. The specifications are strictly platform-, product-, and manufacturer-independent. This document bears the designation "Evidence Record Profiling pursuant to RFC 4998/6283" (also "Annex TR-ESOR-ERS" or only "TR-ESOR-ERS" for short) and describes the prescribed field assignment of the evidence records structured pursuant to [RFC4998] and [RFC6283].
6
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
2. Overview The Technical Guideline TR 03125 TR-ESOR provides a concept for the preservation of evidence of electronic documents by the use of cryptographically signed data and documents. The main basis of this concept is therefore, among other things, the creation, verification and return of evidence records as the IT implementation of the IETF's EvidenceRecord 2 Syntax (short: ERS) standard (see [RFC4998] or [RFC6283]3) as well as the verification and, if necessary, creation of evidence-relevant data, such as time stamps, electronic signatures, certificates, revocation information, etc. The following sections include the presentation of the EvidenceRecord profiles and the evidence-relevant data contained therein, especially also with respect to the time stamp signature, with the goal of ensuring the long-term and sustainable preservation of evidence and the technical conformity and interoperability between different systems that conform to TR-ESOR. In order to achieve interoperability, only a limited number of possible elements and attributes which are widely used and are to be considered as interoperable are allowed or prescribed for evidence records and supplemental evidence data in this profile. In particular, two basic profiles for the structure of an EvidenceRecord are presented: • Basic-ERS-Profile – an obligatory profile that controls the structure of an ER pursuant to [RFC4998] (see Chapter 3), • Basic-XERS-Profile – an optional profile that controls the structure of an ER pursuant to [RFC6283] (see Chapter 6.1). Notice! To improve the clarity and readability of the document, fragments of other standards and guidelines were cited in some sections of this document. The redundancy resulting from this is therefore deliberately maintained. In general, preference is given to the original sources. The explicitly desired deviations from the original version of the standards are defined in the document in the form of requirements and marked explicitly.
2 3
Notice! The term "Evidence Record"is also abbreviated with ER in the rest of this document. Notice! The list of sources (bibliography) is maintained in the Main Document of the TR-03125.
Federal Office for Information Security
7
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
3. EvidenceRecord profiling (normative) 3.1. Introduction The purpose of this specification is to create an interoperability profile for the evidence records pursuant to [RFC4998] or [RFC6283] that supports the long-term and largely system- and platform-independent interpretability of the data and interoperability between the different TR-ESOR implementations. In the following sections, the information in [TR-ESOR-F], especially in Chapter 5 "Cryptographic data formats", is further refined on the basis of the • "Cryptographic Message Syntax (CMS)" pursuant to [RFC3852] or [RFC5652], • "Time Stamp Protocol (TSP)" pursuant to [RFC3161] and [RFC5816], • Long-term signature profiles for CMS-based advanced electronic signatures [ETSI 101733] (or [RFC5126]) or [ETSI 103173], (future [ETSI EN 319122-1] or [ETSI EN 319122-2]), • Evidence Record Syntax standards [RFC4998] and [RFC6283] as well as • Long-term signature profile for CMS-based advanced electronic signatures [ISO14533-1] and the long-term signature profile for XML-based advanced electronic signatures [ISO14533-2]. In this respect, the requirements specified in [TR-ESOR-F] are assumed to be known and, if necessary, supplemented as needed. The syntax of the EvidenceRecords pursuant to [RFC4998] and [RFC6283] is outlined in Chapter 7 - Annex D. In the following chapters, the structure of the Basic-ERS-Profile of an EvidenceRecord pursuant to [RFC4998] is presented and described first (see Chapter 3.3, 3.4) and general statements regarding the creation and verification of EvidenceRecords are made (see Chapter 3.5 and 3.6).
3.2. Definition of the degree of obligation The degree of obligation ("VG" for the German term "Grad der Verpflichtung") of the individual elements is marked and indicated by the following symbols: • V – obligatory ("V" for the German term "verpflichtend"), • O – optional, • B – conditional ("B" for the German term "bedingt"). (A3.2-1) Elements with the degree of obligation "V – obligatory “ shall be implemented in an EvidenceRecord pursuant to this profile as specified. If this element has optional subelements, at least one of these subelements shall be implemented. (A3.2-2) If the technical conformity and interoperability of Conformity Level 2 are to be proven during the creation or verification of an EvidenceRecord, the EvidenceRecord shall be implemented on the basis of the "Basic-ERS-Profile" and "Basic-XERS-Profile" profiling described in this document. The creation and verification of an EvidenceRecord pursuant to [RFC4998] is structured in a manner that conforms to the Basic-ERS-Profile below if: • The processing of all elements of the EvidenceRecord which have the required degree of obligation "V – obligatory" in the Basic-ERS-Profile is carried out as specified below in Chapter 3.3 and Chapter 3.4. The creation and verification of an EvidenceRecord pursuant to [RFC6283] is structured in a 8
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
manner that conforms to the Basic-XERS-Profile below if: • The processing of all elements of the EvidenceRecord which have the required degree of obligation "V – obligatory" in the Basic-XERS-Profile is carried out as specified below in Chapter 6.1 and Chapter 3.4. • In particular, all instances of the TimeStampToken element included in the EvidenceRecord contain a time stamp token structured pursuant to the Basic-ERS-Profile (see Chapter 3.4)
3.3. Structures of an EvidenceRecord pursuant to the Basic-ERS-Profile A basic introduction to the EvidenceRecord on the basis of [RFC4998] or [RFC6283] can be found in [TR-ESOR-F], Chapter 5.5. In addition to this, the following sub-chapters describe: • The data structures needed for the EvidenceRecord, • The degree of obligation of the fields, elements or attributes contained therein as well as • The reference to the standards on which they are based and • partly lay down specifications for the contents of the fields, elements or attributes.
3.3.1. EvidenceRecord type The basic field descriptions of the EvidenceRecord type can be found in Annex [TR-ESOR-F], Chapter 5.5.1. The following text defines further descriptions or assignments of the fields. The EvidenceRecord type pursuant to [RFC4998] consists of three obligatory and two optional fields (see Table 1), to which the following applies in this profile: Field
Type
VG
Reference
EvidenceRecord :: =SEQUENCE { version
INTEGER
V(a)
[RFC4998], Chapter 3.1
digestAlgorithms
SEQUENCE OF AlgorithmIdentifier
V
[RFC4998], Chapter 3.1, this document, Chapter 5.1.1
cryptoInfos
CryptoInfos
O(b)
[RFC4998], Chapter 3.1
encryptionInfo
EncryptionInfo
O(c)
[RFC4998], Chapter 3.1
archiveTimeStampSequence ArchiveTimeStampSequence V
[RFC4998], Chapter 3.1
} Requirements (A3.3-1): (a) – The version field shall currently be set to "1" pursuant to [RFC4998], Chapter 3.1. (b) – This cryptoInfos field should not be available as part of the Basic-ERS-Profile. (c) – The encryptionInfo field should not be available as part of the Basic-ERS-Profile. Table 1: Fields of the EvidenceRecord type
3.3.1.1. ArchiveTimeStampSequence type and ArchiveTimeStampChain type
The following definitions apply (see Table 2 and 3).
Federal Office for Information Security
9
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
Type
Subtype
ArchiveTimeStampSequence SEQUENCE OF ArchiveTimeStampChain
VG
Reference
V(a)(b) [RFC4998], Chapter 5.1
Requirements (A3.3-2): (a) – This ArchiveTimeStampSequence field shall contain at least one field of the ArchiveTimeStampChain type. (b) – The fields of the ArchiveTimeStampChain type in the ArchiveTimeStampSequence field shall be sorted chronologically based on the time of the time stamp contained therein 4. Table 2: Structure of the ArchiveTimeStampSequence type
Type ArchiveTimeStampChain
Subtype SEQUENCE OF ArchiveTimeStamp
VG
Reference
V(a)(b) [RFC4998], Chapter 5.1
Requirements (A3.3-3): (a) – The ArchiveTimeStampChain field shall contain at least one field of the ArchiveTimeStamp type. (b) – The ArchiveTimeStamp fields in the ArchiveTimeStampChain field shall be sorted chronologically based on the time of the final time stamp contained therein. Table 3: Structure of the ArchiveTimeStampChain type
3.3.1.2. ArchiveTimeStamp type and PartialHashtree type
The ArchiveTimeStamp type includes three optional and one obligatory field (see [RFC4998], Chapter 4.1 and Table 4). Furthermore, the following requirements apply:
4
10
The sorting algorithm described in [RFC4998], Chapter 5.1, shall be observed.
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
Field
Type
VG
Reference
ArchiveTimeStamp :: = SEQUENCE { digestAlgorithm
AlgorithmIdentifier
O(a)
[RFC4998], Chapter 4.1, this document, Chapter 5.1.1
attributes
Attributes
O(b)
[RFC4998], Chapter 4.1
reducedHashtree
SEQUENCE OF PartialHashtree
O(c)
[RFC4998], Chapter 4.1
timeStamp
ContentInfo
V(d)
[RFC4998], Chapter 4.1
} Requirements (A3.3.-4): (a) – If this digestAlgorithm is missing, then the digest algorithm of the timeStamp time stamp shall be used. (See [RFC4998], Chapter 4.1) (b) – The attributes field should not be available as part of this profile. (c) – All occurrences of reducedHashtree within the individual elements of the ArchiveTimeStamp type of an ArchiveTimeStampChain archive time stamp chain shall use the same hash algorithm (see [RFC4998], Chapter 5.1). (d) – The timeStamp field shall satisfy the requirements for a time stamp token pursuant to [RFC3161]. Table 4: Fields of the ArchiveTimeStamp type
In general, the following applies: reducedHashtree [optional]: The reducedHashtree field consists of one or several lists of hash values, each representing a partial hash tree. This hash tree can be reduced to the extent that it only includes those hash values that are needed for the verification of a single data object. Such a reducedHashtree can be used to connect the timestamp time stamp of the ArchiveTimeStamp and the protected data objects. If the optional reducedHashtree field is missing, then the time stamp of the ArchiveTimeStamps relates to a single data object or a single data object group, that either represents an originally signed data object or is a previous time stamp.
A field of the Table 5).
PartialHahstree
type contains a sequence of chains of the binary data (see
Type PartialHashtree
Subtype SEQUENCE OF OCTET STRING
VG V(a)
Reference [RFC4998], Chapter 4.1
Remarks: (a) – This field includes one or several hash value(s) in the form of binary data that is stored in a sequence. The individual sequence elements are created when the reduced hash tree is created (see [RFC4998], Chapter 4.2). Table 5: Structure of the PartialHashtree type
Federal Office for Information Security
11
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
3.4. Rules for the TimeStampToken in the ASN.1 format This chapter is subdivided into four sections. Based on [RFC5652] and [ETSI 101733], this chapter describes the general characteristics of the TimeStampToken5 in the first part, the SignedData type in the second part, the SignerInfo type in the third part and the SignedAttribute type in the fourth and last part. In general, the following applies: • The value assignment of the elements of the TimeStampToken in the ASN.1 format is carried out in this profile based on [COMMON PKI], Part 3. In the following text, deviations or more detailed information are presented as additional requirements in the respective tables.
3.4.1. TimeStampToken type The ContentInfo type contains two elements and, in general, is a universal (abstract) container for the content data. In general, the following therefore applies: contentType [obligatory]
The contentType element includes an OID of the data type that is contained in content as an "associated and protected object" (see [COMMON PKI], Chapter 3.1). content [obligatory]
The element includes an "associated and protected object", e.g. a CMS signature (see [RFC3852]) that is supplemented by the aspects that serve the preservation of the evidence, such as certificates or certificate revocation lists etc.
Moreover, the following requirements and definitions apply in this profile: Field
Type
VG
Reference
ContentInfo :: = SEQUENCE { contentType
ContentType
V(a)
[RFC5652], Chapter 5.1, [ETSI 101733], Chapter 4.3.1, Chapter 5.3 [RFC4998], Chapter 4.1
content
SignedData
V(b)
[RFC5652], Chapter 5.1 [ETSI 101733], Chapter 5.4
} Requirements (A3.4-2): (a) – This OID for the contentType of SignedData shall be "1.2.840.113549.1.7.2". (b) – The form of the container applicable in this use case shall be the SignedData type (see [RFC3161], Chapter 2.4.2, page 7). Table 6: Fields of the ContentInfo type of a TimeStampToken
5
12
See [RFC3161] or [TR-ESOR-F], Chapter 5.5.1.
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
3.4.2. SignedData type The SignedData type contains six fields (see [RFC5652], Chapter 5.1) which are all obligatory as part of this profile. This deviates from the cited international standards in which the certificates and crls fields are not obligatory6. In general, the following applies: version [obligatory]
The value of this element defines the syntax version on which this SignedData element is based. digestAlgorithms [obligatory]
A collection of identifiers of the hash algorithms that are used for the calculation of the hash value of the object to be signed is stored in this element. encapContentInfo [obligatory]
Specifies and, if necessary, includes the content to be protected (signed). (See also [RFC5652], Chapter 5.2) certificates [obligatory] 7
A possibility to store the certificates that are used for the verification of the signatures. crls [obligatory] 8
A possibility to store the revocation information for the complete verification of the signatures. signerInfos [obligatory]
A collection of data regarding the signer along with corresponding signature 9.
As part of this profile, the following definitions were made:
6
7 8 9
As part of this profile, the two fields are used for the storage of the complete verification information (revocation material, certificates) that makes a successful verification of the signature possible (see LT Level Conformity Level pursuant to [ETSI EN 319122-2]). Deviating from the cited international standards, this element is obligatory in this case. Deviating from the cited international standards, this element is obligatory in this case. See [COMMON PKI], Part 3
Federal Office for Information Security
13
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
Field
Type
VG
Reference
SignedData:: = SEQUENCE { version
CMSVersion
V(a)
[RFC5652], Chapter 5.1 [ETSI 101733], Chapter 5.4
digestAlgorithms
DigestAlgorithmidentifiers
V
[RFC5652], Chapter 5.1 [ETSI 101733], Chapter 5.4 this document, Chapter 5.1.1
encapContentInfo
EncapsulatedContentInfo
V
[RFC5652], Chapter 5.1 [ETSI 101733], Chapter 5.4
certificates
CertificateSet
Here: [RFC5652], Chapter 5.1 V(b) (c) (f) [ETSI 103173], Chapter 8.1 [ETSI EN 319122-2], Chapter 8.1
crls
RevocationInfoChoices
Here: V(d)(f)
[RFC5652], Chapter 5.1 [ETSI 103173], Chapter 8.2, [ETSI EN 319122-2], Chapter 8.2
signerInfos
SignerInfos
V(e)
[RFC5652], Chapter 5.1 [ETSI 101733], Chapter 5.4
} Requirements (A3.4-3): (a) – The value in the version field shall be "3" pursuant to [COMMON PKI], Part 3. (b) – As part of this profile, the certificates used incl. the complete certificate path including the trustworthy root certificates shall be stored within the certificates field. (c) – Notice! The reference to the signature certificate shall be added to the signerInfo field in the signed SigningCertificateReference attribute.10 (d) – As part of this profile, the complete revocation information needed for the verification of the signature shall be stored in the crls field. This information is primary certificate revocation lists (CRLs) or OSCP responses.11 (e) – The signerInfos field shall only contain one instance pursuant to [RFC3161]. (f) – Deviating from the cited international standards, the certificates and crls fields are obligatory in this profile. Table 7: Fields of the SignedData type
3.4.2.1.
EncapsulatedContentInfo type
The encapContentInfo element of the EncapsulatedContentInfo type describes the content which is to be hashed as part of the signature generation. The field consists of an eContentType identifier and the eContent content itself. The following applies in this case: 10 11
14
See also [TR-ESOR-F], Chapter 5.1.1 See also [TR-ESOR-F], Chapter 5.1.1
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283 eContentType [obligatory]
The eContentType element is an object identifier which includes an OID of the data type which is stored in eContent and to be hashed as part of the signature (see [COMMON PKI], Chapter 3.1). eContent [obligatory] 12 In this profile, however, the field always contains a DER-encoded instance of the TSTInfo data structure (see [RFC3161], Chapter 2.4.2). In general, the " messageImprint" attribute includes a hash algorithm OID (see hashAlgorithm in [RFC3161]) in the TSTInfo and the hash value of the data (see hashedMessage in [RFC3161]) that is to be time-stamped.
The encapContentInfo element shall correspond to the structure presented in Table 8 (see [RFC3161] Chapter 2.4.2). Field
Type
VG
Reference
eContentType
ContentType
V(a)
[RFC5652], Chapter 5.2 [ETSI 101733], Chapter 5.5
eContent
OCTET STRING
V(b)(c) [RFC5652], Chapter 5.2 [ETSI 101733], Chapter 5.5
Requirements (A3.4-4): (a) – The value of this eContentType field is constant and shall be "1.2.840.113549.1.9.16.1.4" (id-ct-TSTInfo, see [RFC3161], Chapter 2.4.2). (b) – Pursuant to [RFC5652], the eContent field is optional. In case of a time stamp, this field shall be available (see [RFC3161], Chapter 2.4.2). (c) – Here, the eContent element shall contain a DER-encoded instance of the TSTInfo data structure (see [RFC3161], Chapter 2.4.2). The following applies in this case: If the EvidenceRecord includes a reducedHashtree in the initialArchiveTimeStamp, the DER-encoded "root hash value" of the reducedHashtree shall be contained in the hashedMessage attribute of the TSTInfo.messageImprint. The hash value is taken over by the content of the OCTET STRING without enclosing tags and the length of the OCTET STRING. Otherwise, at least the DER-encoded hash value of the data to be time-stamped of an data object shall be included in the hashedMessage attribute of the TSTInfo.messageImprint in the event of an initialArchiveTimeStamp, as it is the case for a normal time stamp. The hash value is taken over by the content of the OCTET STRING without enclosing tags and the length of the OCTET STRING. In the event of a time stamp renewal, the hash value of the timeStamp of the old archive time stamp element shall be stored in the hashedMessage attribute of the TSTInfo.messageImprint. The hash value is taken by the content of the OCTET STRING without enclosing tags and the length of the OCTET STRING. In the event of the hash tree renewal, the DER-encoded "root hash value" of the new generated reducedHashtree shall be stored here in the hashedMessage attribute of the TSTInfo.messageImprint. Table 8: Fields of the EncapsulatedContentInfo type
3.4.2.2. CertificateSet type and RevocationInfoChoices type
A certificates element of the CertificateSet type consists of a non-empty amount of elements of the CertificateChoices type. 12
Deviating from the cited international standards, this element is obligatory in this case.
Federal Office for Information Security
15
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
Type CertificateSet
Subtype SET OF CertificateChoices
VG V(a)
Reference [RFC5652], Chapter 10.2.3
Requirements (A3.4-5): (a) – This CertificateSet field shall contain at least one element of the CertificateChoices type. Table 9: Structure of the CertificateSet type (pursuant to [RFC5652], Chapter 10.2.3)
The CertificateChoices type specifies a selection of 5 different elements that are available (see Table 10). Field
Type
VG
Reference
CertificateChoices :: =CHOICE { certificate
Certificate
V(a)
[RFC5652], Chapter 10.2.2
extendedCertificate
ExtendedCertificate
B(x)
[RFC5652], Chapter 10.2.2
v1AttrCert
AttributeCertificateV1
B(x)
[RFC5652], Chapter 10.2.2
v2AttrCert
AttributeCertificateV2
B(y)
[RFC5652], Chapter 10.2.2
other
OtherCertificateFormat
B(y)
[RFC5652], Chapter 10.2.2
} Requirements (A3.4-6): (a) – In this profile, certificate of the Certificate type shall be used. Remarks: (x) – This data is already obsolete pursuant to [RFC5652], Chapter 10.2.2, and is thus no longer used as part of this profiling. (y) – Are not supported as part of this profiling. Table 10: Structure of the CertificateChoices type (pursuant to [RFC5652], Chapter 10.2.2) certificate
[obligatory]
Includes an X.509-v3 certificate (see [RFC5280], Chapter 3.1 and 4 as well as [RFC6818] if applicable).
A crls element of the RevocationInfoChoices type consists of a non-empty amount of the elements of the RevocationInfoChoice type (see Table 11). Type RevocationInfoChoices
Subtype
VG
SET OF RevocationInfoChoice V(a)
Reference [RFC5652], Chapter 10.2.1
Requirements (A3.4-7): (a) – This RevocationInfoChoices field shall contain at least one element of the RevocationInfoChoice type. Table 11: Structure of the RevocationInfoChoices type (pursuant to [RFC5652], Chapter 10.2.1)
The RevocationInfoChoice type provides a selection of one of 2 elements that are available (see Table 12).
16
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283 [conditional]
crl
Is the storage space for the certificate revocation list (CRL pursuant to [RFC5280], Chapter 5). other
[conditional]
Includes other revocation information, especially an OCSP response pursuant to [RFC2560], Chapter 4.2. Type
Subtype
VG
Reference
RevocationInfoChoice :: =CHOICE { crl
CertificateList
B(a)
[RFC5652], Chapter 10.2.1
other
OtherRevocationInfoFormat B(b)(c)(d) [RFC5652], Chapter 10.2.1
} Requirements (A3.4-8): (a) – X.509 certificate revocation lists (CRLs) are a source of revocation status information, which is often used. If both revocation information in the form of CRLs and OCSP responses are available for the certificate to be verified, OCSP responses should be used in this case (see [TR-ESOR-F], footnote 20). (b) – If OCSP information is used, the otherRevInfoFormat attribute shall include the id-pkix-ocsp-basic OID with the value "1.3.6.1.5.5.7.48.1.1" and the otherRevInfo attribute shall include the BasicOCSPResponse element. (c) – BasicOCSPResponse pursuant to [RFC2560] shall contain at least one OCSP signer certificate in BasicOCSPResponse.certs. Related to the ResponderID field, the byName selection should be used. (d) – The SingleResponse.singleExtensions contains CertHash, which is defined in [Common PKI], Part 4 and Part 9. Table 12: Structure of the RevocationInfoChoices type (pursuant to [RFC5652], Chapter 10.2.1)
3.4.3. SignerInfo type The SignerInfo type is defined in [RFC5652], Chapter 5.3. In general, the following applies: version [obligatory]
The value of this element describes the version on which the syntax is based. sid [obligatory]
Specifies the signer's certificate and thus the public key used that is needed for the verification of the signature. digestAlgorithm [obligatory]
Contains the identifier (if applicable, also additional parameters) of the hash algorithm and is used for the calculation of the so-called message digest. signedAttrs [obligatory]
This element includes a collection of attributes which were also signed (remark (e) in Table 13 must be observed in particular).
Federal Office for Information Security
17
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283 signatureAlgorithm [obligatory]
Using this element, the identifier of the signature algorithm used is described (if applicable, with additional parameters). signatureValue [obligatory]
Within this element, the result of the private key application on the calculated message digest specified by the content of the signatureAlgorithm element is stored. unsignedAttrs [optional]
This element includes the collection of attributes that were not signed (remark (f) in Table 13 must be observed in particular).
As part of this profiling, the following definitions were made:
18
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
Field
Type
VG
Reference
SignerInfo :: = SEQUENCE { version
CMSVersion
V(a)
[RFC5652], Chapter 5.3 [ETSI 101733], Chapter 5.6 [COMMON PKI], Part 3
sid
SignerIdentifier
V(b)
[RFC5652], Chapter 5.3 [ETSI 101733], Chapter 5.6 [COMMON PKI], Part 3, T. 4
digestAlgorithm
DigestAlgorithIdentifier
V(c)
[RFC5652], Chapter 5.3 [ETSI 101733], Chapter 5.6 this document, Chapter 5.1.1
signedAttrs
SignedAttributes
V(d) (e) [RFC5652], Chapter 5.3 [ETSI 101733], Chapter 5.6
signatureAlgorithm
SignatureAlgorithmIdentifier
V
[RFC5652], Chapter 5.3 [ETSI 101733], Chapter 5.6
signatureValue
SignatureValue
V
[RFC5652], Chapter 5.3 [ETSI 101733], Chapter 5.6
unsignedAttrs
UnsignedAttributes
O(f)
[RFC5652], Chapter 5.3 [ETSI 101733], Chapter 5.6
} Requirements (A3.4-9): (a) – The version field shall contain the value "1" pursuant to [COMMON PKI], Part 3. (b) – In the sid field within this profile, the issuerAndSerialNumber required pursuant to [COMMON PKI], Part 3, shall be used. (c) – The value specified in the digestAlgorithm field shall conform to one of the values in the SignedData.digestAlgorithms field. (d) – Pursuant to [RFC5652], this signedAttrs field is optional, but pursuant to [RFC3161], this field shall contain the SigningCertificate or SigningCertificateV2 attribute and will therefore be obligatory. As part of this profile, the SigningCertificateV2 attribute (see [RFC5035]) shall be used. (e) – The signedAttrs field is a set of attributes that is signed and shall be DER-encoded. (f) – The unsignedAttrs field is optional pursuant to [RFC5652], but it should not be used as part of this profile when generating a TimeStampToken. Table 13: Fields of the SignerInfo type
The SignedAttributes or UnsignedAttributes types are specified in [RFC5652], Chapter 5.3, and consist of two obligatory fields each (see Table 14).
Federal Office for Information Security
19
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
Field
Type
VG
Reference
Attribute::= SEQUENCE { attrType
OBJECT IDENTIFIER
V
[RFC5652], Chapter 5.3
attrValues
SET OF AttributeValue
V
[RFC5652], Chapter 5.3
} Remarks: none Table 14: Fields of the Attribute type pursuant to [RFC5652] attrType [obligatory]
The value of this field describes the type of an attribute. attrValues [obligatory]
This field contains a set of attribute values the value of which was clearly characterised by the value of the attrType. The defined type of the attribute can also restrict the number of the values available.
3.4.4. Signed attributes Table 15 provides a list of the signed attributes relevant to this profiling. The signing-certificate-reference attribute is obligatory in the case of the time stamp pursuant to [RFC3161], Chapter 2.4.2. Notice! [RFC3161] does not prohibit the use of other signed attributes. As part of this profile, only exactly13 the attributes defined in Table 16 may be available, i.e. in addition to the obligatory signed attributes (ContentType and messageDigest) only the signed SigningCertificateV2 attribute in the ESSCertIDv2 form pursuant to [RFC5816] may be available. In general, the following applies: content-type [obligatory]
This attribute describes the content type of the data signed. message-digest [obligatory]
The attribute includes the hash value, calculated based on the content, specified by the SignedData.encapContentInfo.eContent value (see Table 8). signing-certificate-reference [obligatory]
Pursuant to [RFC3161], Chapter 2.4.2, it is absolutely necessary to store the reference to the signature certificate within this attribute.
Furthermore, the following requirements apply:
13
20
The profile defined here deliberately restricts the [RFC3161] definition of a time stamp.
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
Attribute
Type
VG
Reference
SignedAttributes :: = SET OF Attributes { content-type
Attributes
V
[RFC5652], Chapter 11.1 [ETSI 101733], Chapter 5.7.1
message-digest
Attributes
V(a)(b)
[RFC5652], Chapter 11.2 [ETSI 101733], Chapter 5.7.2 this document, Chapter 5.1.1
V(c)
[RFC2634], Chapter 5.4 [RFC5035], Chapter 5.4.1 [ETSI 101733], Chapter 5.7.3 [RFC5816]
signing-certificate-reference Attributes
} Requirements (A3.4-10): (a) – The message-digest attribute may contain only one single attribute value, i.e. the hash value of the content in encapContentInfo.eContent. (b) – The SignedAttributes in a signerInfo may contain only one instance of the message-digest attribute. In this case, it is a hash value via an instance of the TSTInfo element from SignedData. (c) – In this profile,no ESS signing-certificate pursuant to [RFC2634] or [ETSI 101733], Chapter 5.7.3.1, shall be used, since it is based on the hash algorithm SHA-1. Instead, an ESS signing-certificate-v2 attribute pursuant to [RFC5035] or [ETSI 101733], Chapter 5.7.3.2, shall be used. Table 15: Listing of the relevant signed attributes (time stamps pursuant to [RFC3161])
Table 16 provides the form of the signed content-type attribute used for the time stamp token (pursuant to [RFC3161]). Field
Type
VG
Reference
attrType
OBJECT IDENTIFIER
V (a)
[RFC5652], 11.1 [ETSI 101733], 5.7.1
attrValues
ContentType
V (b)(c) [RFC5652], 11.1 [ETSI 101733], 5.7.1
Requirements (A3.4-11): (a) – The OID of attrType in the content-type attribute shall be set to "1.2.840.113549.1.9.3" pursuant to [RFC5652], Chapter 11.1. (b) – The OID of attrValues in the content-type shall be set to "1.2.840.113549.1.9.16.1.4" (TSTInfo) pursuant to [RFC3161], Chapter 2.4.2. (c) – Pursuant to [RFC5625], Chapter 11.1, this value of attrValues attribute content-type shall conform to the value of the SignedData.encapContentInfo.eContentType element. Table 16: content-type attribute pursuant to [RFC5652].
Federal Office for Information Security
21
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
Table 17 describes the syntactic structure of the message-digest attribute. Field
Type
VG
Reference
attrType
OBJECT IDENTIFIER
V (a)
[RFC5652], Chapter 11.2
attrValues
MessageDigest
V
[RFC5652], Chapter 11.2
Requirements (A3.4-12): (a) – The OID of attrValues in the message-digest attribute shall be set to "1.2.840.113549.1.9.4" pursuant to [RFC5652], Chapter 11.2. Table 17: message-digest attribute pursuant to [RFC5652]. attrValues [obligatory]
Contains the hash value calculated based on the data which is defined by the content of the SignedData.encapContentInfo.eContent element. In this profile, it is a DER-encoded instance of the TST-Info element (see Table 8 and [RFC3161], Chapter 2.4.2).
Pursuant
to
[RFC3161]
Chapter 2.4.2, the availability of the signed attributes in a signature of a time stamp is obligatory. The structure of the signing-certificate-v2 attribute (see [RFC5035], Chapter 5.4.1) is shown in Table 18. signing-certificate-reference
Field
Type
VG
Reference
attrType
OBJECT IDENTIFIER
V(a)
[RFC5035], 5.4.1 [ETSI 101733], 5.7.3.2
attrValues
ESS SigningCertificateV2
V(b)(c)(d) [RFC5035], 5.4.1 (e) [ETSI 101733], 5.7.3.2
Requirements (A3.4-13): (a) – The OID of attrValues in the signing-certificate-v2 attribute shall be set to "1.2.840.113549.1.9.16.2.47" pursuant to [RFC5035], Chapter 5.4.1. (b) – The value of the SigningCertificateV2 attribute shall contain at least one ESSCertIDv2 reference to the signer certificate. (c) – The value of the SigningCertificateV2 attribute should include a reference to the complete certificate path including the trustworthy root certificate. (d) – The format of this reference shall correspond to the ESSCertIDv2 pursuant to [RFC5035]. Table 18: signing-certificate-v2 attribute pursuant to [RFC5035].
3.5. Creating an EvidenceRecord (A3.5-1) The creation of an EvidenceRecord pursuant to [RFC4998] the structure of which conforms to the Basic-ERS-Profile shall be supported. (A3.5-2) The creation of an EvidenceRecord pursuant to [RFC6283] the structure of which conforms to the Basic-XERS-Profile(see Chapter 6) can be supported.
3.5.1. Handling the archive time stamp The following requirement applies both to the initially requested time stamp tokens and to the time stamp tokens which are requested in the course of the time stamp renewal or hash tree renewal. Below, an overview of the individual steps that are to be taken in the course of the time stamp 22
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
procurement both on the part of the time stamp provider and on the part of the TR-ESOR-Middleware is outlined. Before the creation of the actual timestamp as part of the ArchiveTimeStamp is completed successfully, at least the following steps shall be taken: • The TR-ESOR-Middleware calculates the hash value to be time-stamped and prepares a time stamp request (TS request), • The TR-ESOR-Middleware sends the prepared time stamp request to the time stamp provider. • The time stamp provider selects the certificate for the generation of the timestamp and creates the complete certificate path including the trustworthy root certificate. • When several certificate paths are possible, a certificate path that is suitable for the verification is chosen. • A time stamp is created on the basis of the hash value included in the time stamp request. In this respect, care must be taken to choose a time stamp provider that fulfils the following conditions: • The certificate for the creation of the timestamp and its complete certificate path including the trustworthy root certificate are stored in the SignedData.certificates field, • A ESSCertIDv2 reference to the signer certificate is stored in the SigningCertificateV2 attribute and • A reference to the complete certificate path including the trustworthy root certificate is stored in the SigningCertificateV2 attribute. • The timestamp created is returned to the TR-ESOR-Middleware. • The TR-ESOR-Middleware verifies the time stamp received using the verifyRequest function (see [TR-ESOR-E], Chapter 4.3.2) and, in doing so, uses the ReturnUpdatedSignature policy with the Type attribute http://www.bsi.bund.de/tr-esor/api/1.2 (see [TR-ESOR-E], Chapter 4.3.2.1) so that all certificates and revocation information used during the verification pursuant to the profiles in this document are stored in the timestamp. Notice! Pursuant to [RFC4998], Chapter 4.2, last paragraph, the following applies to the creation of a archive time stamp: "The data (e.g. certificates, Certificate Revocation Lists (CRLs), or Online Certificate Status Protocol (OCSP) responses) needed to verify the timestamp MUST be preserved, and SHOULD be stored in the timestamp itself unless this causes unnecessary duplication. A timestamp pursuant to [RFC3161] is a CMS object in which certificates can be stored in the certificates field and CRLs can be stored in the crls field of signed data." After the new archive time has been created, it shall contain the complete certificate path including the trustworthy root certificate for the validation of the signature certificates used as part of the archive time stamp.
3.6. Verifying an EvidenceRecord (A3.6-1) The verification of EvidenceRecords structured pursuant to the Basic-ERS-Profile shall be supported. (A3.6-2) The verification of an EvidenceRecord structured pursuant to the Basic-XERS-Profile shall be supported14. 14
In the special case of an import of an EvidenceRecord structured pursuant to Basic-XERS-Profile, it does not necessarily have to be updated in this form.
Federal Office for Information Security
23
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
(A3.6-3) If the SigningCertificateV2 attribute includes information on the certificate path, these certificates shall be used for signature verification. If the complete certificate path including the trustworthy root certificates has not already been stored in the timestamp created last and if the missing information can still be obtained, it is integrated into the verification and should be stored for the future use with the verified artefacts. The following applies in this case:
(A3.6-4) If the complete certificate path including the trustworthy root certificate has not already been stored in the timestamp created last, the signature verification application shall be able to: • Build up the complete certificate path including the trustworthy root certificate, and • Choose a path that is suitable for verification when several certificate paths are available. If an error occurred, either • the verification report in the form of a VerificationReport element or • the archived data object (group) supplemented by this verification information in the form of an xaip:XAIP element contained in the VerifyResponse element as an answer to the VerifyRequest (see [TR-ESOR-E]) is returned. In detail, the following applies: • If the data structures excluded in the Basic-ERS-Profile and Basic-XERS-Profile are found during the verification of an EvidenceRecord (e.g. the cryptoInfos element or the encryptionInfo element etc.), this shall be indicated and marked with a warning. • If additional certificates or revocation information have been obtained during the verification of an EvidenceRecord, they should be stored within the CredentialSection of the associated XAIP container.
24
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
4. Annex A: Profile overview (normative) 4.1. Basic-ERS-Profile – overview The following tables provide an overview of the obligatory elements due to the Basic-ERS-Profile with respect to the ER itself and the time stamp tokens. Element EvidenceRecord digestAlgorithms
Degree of obligation V
Value 1
V (a)
archiveTimeStampSequence
V
ArchiveTimeStampChain
V (b)
ArchiveTimeStamp
V (b)
digestAlgorithm
O (a)
reducedHashtree
O
timeStamp
V
SignedData
Remarks: (a) – See Chapter 5.1.1 (b) – Includes at least one element
Table 19: Overview of the structure of an EvidenceRecord pursuant to the Basic-ERS-Profile
Federal Office for Information Security
25
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
Element ContentType
Degree of obligation V
Value Id-signedData (OID =
Content CMSVersion DigestAlgorithmIdentifiers EncapsulatedContentInfo
"1.2.840.113549.1.7.2")
V
Signed Data
V
3
V (a)
Hash-alg-oid
V
eContentType
V
Id-ct-TSTInfo (OID= "1.2.840.113549.1.9.16.1.4")
eContent
V
DER-encoded value of TSTInfo
CertificateSet (certificates) RevocationInfoChoices (crls)
SignerInfos SignerInfo
V(d) V (c)(d)
V V
SignerIdentifier
V V (a)
SignedAttributes
V
ContentType
V
MessageDigest
V
SigningCertificateReference
V
ESS SigningCertificate v2 SignatureAlgorithmIdentifier SignatureValue
CertificateList or pkix-basic-response (OID="1.3.6.1.5.5.7.48.1.1")
V
CMSVersion
DigestAlgorithmIdentifier
X509v3
V(d)
attrType(OID="1.2.840.113549.1.9.3") attrValues(id-ct-TSTInfo)
ESSCertIDv2 OID="1.2.840.113549.1.9.16.2.47"
V(b) V
UnsignedAttributes
B(e)
ATSHashIndex
B(e)
AttrType: id-aa-ATSHashIndex OID="0.4.0.1733.2.5"
Remarks: (a) – See Chapter 5.1.1 (b) – See Chapter 5.1.2 (c) – If possible, OCSP responses should be used preferably. (d) – Obligatory in this profile, in deviation from the standard (e) – Attribute only permissible if an ATSv3 pursuant to Chapter 6.2 is inserted as part of a time stamp renewal.
Table 20: Overview of the structure of a time stamp pursuant to the Basic-ERS-Profile
26
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
5. Annex B: Requirements for cryptographic algorithms and parameters (normative) 5.1. Creating an EvidenceRecord pursuant to Basic-ERS-Profile When creating an EvidenceRecord pursuant to Basic-ERS-Profile (see Chapter 3), the following specifications regarding the algorithms used shall be observed. The requirements for the cryptographic algorithms and parameters used when creating EvidenceRecords are based on the specifications and recommendations of the Federal Office for Information Security and, insofar as they relate to electronic signatures, are regularly published by the Federal Network Agency (BNetzA) in the scope of the "Announcement Regarding the Electronic Signature pursuant to the Signature Act and the Signature Ordinance", "Overview of Suitable Algorithms" (see [ALGCAT]). These specifications are binding and always have to be updated pursuant to the current recommendations of the Federal Office for Information Security and the Federal Network Agency. The requirement (A4.3-1) of the Cryptographic-Module M.2 applies to the creation of evidence records. The requirement (A4.2-3) of the Cryptographic-Module M.2 applies to the verification of evidence records. During the verification of an EvidenceRecord, the hash algorithms pursuant to [ALGCAT] (see Chapter 6) shall be supported if necessary. The OIDs of the algorithms used shall be taken from [ETSI TR 119312].
5.1.1. Hash algorithms At the moment, only following hash algorithms shall be used for the creation of evidence records pursuant to Chapter 3: Algorithm SHA-256
SHA-384
SHA-512
OID/URN
Normative references
OID: 2.16.840.1.101.3.4.2.1
[RFC4055]
URN: http://www.w3.org/2001/04/xmlenc#sha256
[XMLENC]
OID: 2.16.840.1.101.3.4.2.2
[RFC4055]
URN: http://www.w3.org/2001/04/xmldsig-more#sha384
[RFC6931]
OID: 2.16.840.1.101.3.4.2.3
[RFC4055]
URN: http://www.w3.org/2001/04/xmlenc#sha512
[XMLENC]
Table 21: Currently allowed hash algorithms for the creation of evidence records (as of 30th of September 2014)
5.1.2. Signature algorithms Here, the specifications and recommendations of the Federal Office for Information Security (see [ALGCAT]) shall be observed.
5.2. Verifying an EvidenceRecord In addition to the algorithms listed in Chapter 5.1.1, the following hash algorithms should be supported during the verification of an EvidenceRecord.
Federal Office for Information Security
27
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
5.2.1. Hash algorithms To verify an EvidenceRecord, all algorithms used in this evidence record shall be supported. The hash and signature algorithms whose suitability as security measures has expired, shall also still be supported by the system for the validation of the evidence records. At the moment, at least the following hash algorithms shall also be additionally supported if necessary. In general, [ALGCAT], especially Chapter 6, applies in the respectively valid version. Algorithm SHA-1
SHA-224
OID/URN
Normative references
OID: 1.3.14.3.2.26
[RFC3279]
URN: http://www.w3.org/2000/09/xmldsig#sha1
[XMLENC]
OID: 2.16.840.1.101.3.4.2.1
[RFC4055]
URN: http://www.w3.org/2001/04/xmldsig-more#sha384
[RFC4051] [CRYPTO3N2]
RIPEMD-160 OID: 1.3.36.3.2.1 URN: http://www.w3.org/2001/04/xmlenc#ripemd160
[XMLENC]
Table 22: Currently additionally required hash algorithms for the verification of an EvidenceRecord (as of 01/08/2014)
5.2.2. Signature algorithms For the creation, the specifications and recommendations of the Federal Office for Information Security shall be observed pursuant to [ALGCAT]. Moreover, the following signature algorithms should also be supported for the verification based on current information (see Table 23):
28
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
Algorithm
OID/URN
sha1WithRSAEncryption
OID: 1.2.840.113549.1.1.5
Normative references [RFC3279]
URN: http://www.w3.org/2000/09/xmldsig#rsa-sha1 [XMLDSIG] sha224WithRSAEncryption
RSASSA-PSS mgf1-SHA-1 and: • SHA-1 • SHA-224
OID: 1.2.840.113549.1.1.14
[RFC4055]
URN: http://www.w3.org/2000/09/xmldsig#rsa-sha244
[XMLDSIG]
with OID: 1.2.840.113549.1.1.10
[RFC4055]
URN: [RFC6931] http://www.w3.org/2007/05/xmldsig-more#sha1-rsaMGF1 http://www.w3.org/2007/05/xmldsig-more#sha224-rs a-MGF1
dsa-with-sha1
OID: 1.2.840.10040.4.3
[RFC3279]
URN: http://www.w3.org/2000/09/xmldsig#dsa-sha1 [XMLDSIG]
dsa-with-sha224
OID: 2.16.840.1.101.3.4.3.1
[RFC5758]
URN: urn:oid:2.16.840.1.101.3.4.3.1
ecdsa-with-sha1
OID: 1.2.840.10045.4.1
[ANSI X9.62]
URN: [RFC6931] http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha 1
ecdsa-with-sha224
OID: 1.2.840.10045.4.3.1
[ANSI X9.62]
URN: [RFC6931] http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha 224
ecgSignatureWithsha115
OID: 1.3.36.3.3.2.5.4.2 URN: urn:oid:1.3.36.3.3.2.5.4.2
ecgSignatureWithsha224
15
OID: 1.3.36.3.3.2.5.4.3 URN: urn:oid:1.3.36.3.3.2.5.4.3
Table 23: Additional signature suites that are currently to be supported during the verification of an EvidenceRecord (as of 1st of August 2014)
5.2.3. ESSCertIDv2 and ESSCertID (A5.2-1) The certificate references in the ESSCertIDv2 form (see [RFC5816]) shall and the ESSCertID form (see [RFC2634]) should be supported during the verification of an EvidenceRecord.
15
See https://www.teletrust.de/fileadmin/docs/projekte/oid/OID-Liste_1_3_36_3_3_2_5.pdf.
Federal Office for Information Security
29
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
6. Annex C: Further ERS profiles (informative) 6.1. Structure of an EvidenceRecords pursuant to the Basic-XERS-Profile In the document [TR-ESOR-M.3], an XML-based form of the EvidenceRecord pursuant to [RFC6283] is described in detail and an example of an XML-based time stamp is presented. In order to preserve the evidentiary value of the time stamp in the long-term, it must be enhanced with revocation information. The following sub-chapters describe the Basic-XERS-Profile that ensures the long-term and sustainable preservation of evidence of an EvidenceRecord created pursuant to [RFC6283]. The EvidenceRecordType has the following structure: Version [obligatory]
This attribute describes the syntax version. EncryptionInformation [optional]
If necessary, this element includes information regarding the encryption used. SupportinginformationList [optional]
Using this element, information on the necessary processing of EvidenceRecords can be specified (e.g. the input of specific policies). ArchiveTimeStampSequence [obligatory]
This element shall be available. ArchiveTimeStampChain [obligatory]
This element shall be available and contain a sequence of archive time stamps. Field
Type
VG
Reference
Version (Attr)
decimal (x)
V(a) [RFC6283], Chapter 2.1
EncryptionInformation
EncryptionInfo
O(b) [RFC6283], Chapter 2.1
SupportingInformationList
SupportingInformationType
O(c) [RFC6283], Chapter 2.1
ArchiveTimeStampSequence
ArchiveTimeStampSequenceType V
ArchiveTimeStampChain
(inline definition)
[RFC6283], Chapter 2.1
V(d) [RFC6283], Chapter 2.1
Requirements (A6.1-1): (x) – Definition is specified by XML schema (see [XSD2012]). (a) – The Version field is fixed and shall be set to "1.0". (b) – The EncryptionInformation field should NOT be available in the Basic-XERS-Profile. (b) – The SupportingInformationList field should NOT be available in the Basic-XERS-Profile. (d) – At least one ArchiveTimeStampChain field shall be included. Table 24: The EvidenceRecordType pursuant to [RFC6283] and Basic-XERS-Profile
An ArchiveTimeStampChain element is structured as follows: @Order [obligatory]
This attribute makes it possible to sort the individual time stamp chains in the order they were created.
30
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283 DigestMethod [obligatory]
The content of this element specifies the hash algorithm that is used within the current time stamp chain for the calculation of the hash values. CanonicalizationMethod [obligatory]
The content of this element specifies which canonicalization methods should be applied to the XML-based elements before they are hashed. ArchiveTimeStamp [obligatory]
The actual archive time stamp shall be stored in this element. Field
Type
VG
Reference
Order (Attr)
INTEGER
V(a) [RFC6283], Chapter 2.1
DigestMethod
DigestMethodType
V(b) [RFC6283], Chapter 2.1 this document, Chapter 5.1.1
CanonicalizationMethod
CanonicalizationMethodType V(c) [RFC6283], Chapter 2.1
ArchiveTimeStamp
ArchiveTimeStampType
V(d) [RFC6283], Chapter 2.1
Requirements (A6.1-2): (a) – The Order attribute shall be set. (b) – The value of this DigestMethod element shall be set and is restricted by the list in Chapter 5.1.1. (c) – The CanonicalizationMethod field shall be available. (d) – The ArchiveTimeStamp attribute shall contain at least one element. Table 25: The ArchiveTimeStampChainType pursuant to [RFC6283] and Basic-XERS-Profile
The ArchiveTimeStampType has the following structure: HashTree [optional]
An optional element which includes the corresponding reduced hash tree. TimeStamp [obligatory]
The time stamp token shall be stored in this element. Attributes [optional]
This element can container further information (e.g. policies) that is required to process the EvidenceRecord. In the Basic-XERS-Profile, this element should not be available. Field
Type
VG
Reference
HashTree
HashTreeType
O
[RFC6283], Chapter 3.1
TimeStamp
TimeStampType
V(a) [RFC6283], Chapter 3.1
Attributes
Attributes
O(b) [RFC6283], Chapter 3.1
Requirements (A6.1-3): (a) – In the TimeStamp element, the time stamp token shall be stored. (b) – The Attributes element should not be available in the Basic-XERS-Profile. Table 26: The ArchiveTimeStampType pursuant to [RFC6283] and Basic-XERS-Profile
Federal Office for Information Security
31
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
The TimeStampType has the following structure: TimeStampToken [obligatory]
Within this element, the time stamp token shall be stored in the form of raw data. TimeStampToken.Type [obligatory]
This attribute shall be set and the value of this attribute shall be "RFC3161" within the Basic-XERS-Profile. CryptographicInformationList [optional]
This element offers a possibility to store additional validation information (e.g. certificates or certificate revocation lists or OCSP responses) if it cannot be stored within the time stamp token itself. Field
Type
VG
Reference
TimeStampToken
any
V(a)(b) [RFC6283], Chapter 3.1.2 this document, Chapter 3.4
TimeStampToken.Type (Attr)
NMTOKEN
V(c)
[RFC6283], Chapter 3.1.2
CryptographicInformationList
CryptographicInformationType O(d)
[RFC6283], Chapter 3.1.3
Remarks: (a) – The TimeStampToken value shall consists of a time stamp token pursuant to [RFC3161]. (b) – The TimeStampToken value shall conform to the Basic-ERS-Profile. (c) – The TimeStampToken.Type value is fixed and shall be set to "RFC3161". (d) – The CryptographicInformationList element should not be available in the Basic-XERS-Profile. Table 27: The TimeStampType pursuant to [RFC6283] and Basic-XERS-Profile
6.2. Time stamp renewal using ATSv3 (only CMS-based) 6.2.1. Use of ATSv3 A time stamp chain using an ATSv3 time stamp can also be completed as part of a time stamp renewal or used as an archive time stamp if only one archived data object (group) is available. In the event of the time stamp renewal, such an ATSv3 time stamp will refer to the last already available time stamp of the last already available time stamp chain (see Figure 2).
32
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
Figure 2: Time stamp renewal using ATSv3
(A6.2-1) The verification of time stamp tokens included in the EvidenceRecord pursuant to ATSv3 should be supported. The advantage of ATSv3 is that other crls and certificatescan be stored in signedData.certificates or signedData.crls in the last ATSv3 time stamp without destroying the last ATSv3. Another advantage of the ATSv3 time stamp is that a time stamp structured in this manner pursuant to Basic-ERS-Profile can satisfy the "LTA-Level" conformity requirements pursuant to [ETSI EN 319122-2], Chapter 9, Table 13. On the other hand a separate time stamp is required for each archived data object (group) to be protected; the use of hash trees has not been planned yet for ATSv3-type time stamps. An EvidenceRecord created pursuant to [RFC4998] and the Basic-ERS-Profile includes a sequence of archive time stamps (see Chapter 3 and [RFC4998], Chapter 3.1). An individual archive time stamp includes a time stamp token issued pursuant to [RFC3161] (see [RFC4998], Chapter 4.1) that was extended pursuant to the Basic-ERS-Profile (see Chapter 3.4). For a data structure prepared in this manner, a time stamp renewal can also be carried out by means of the alternative method described here by using a time stamp of the archive-time-stamp-v3 (ATSv3) type along with the revocation information collected for this operation. The ATSv3 attribute created is then stored as an unsigned attribute of the signature of the last valid archive time stamp (see Figure 2).
6.2.2. archive-time-stamp-v3 attribute (ATSv3) Several instances of an ATSv3 can occur in a signature (in this respect, see [ETSI 101733], Chapter 6.4.3). The structure of the ATSv3 attribute is based on [RFC5652], Chapter 5.3, as defined in Table 28.
Federal Office for Information Security
33
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
Field
Type
VG
Reference
attrType
OBJECT IDENTIFIER (a)
V
[ETSI 101733], Chapter 6.4.3
attrValues
ArchiveTimeStampToken (b)(c)
V
[ETSI 101733], Chapter 7.4
Remarks: (a) – Pursuant to [ETSI 101733] (Chapter 6.4.3), the attrType field is set to "0.4.0.1733.2.4". (b) – Pursuant to [ETSI 101733] (Chapter 6.4.3), an ATSv3 attribute shall contain exactly one attrValue in the form of an ArchiveTimeStampToken. (c) – The contents of the archive time stamps contained therein, especially with respect to the structure of the so-called "message imprint", shall be created pursuant to [ETSI 101733], Chapter 6.4.3 and 6.4.2. Table 28: archive-time-stamp-v3 attribute pursuant to [ETSI 101733] Chapter 6.4.3
Table 29 outlines the structure of the "message imprint" pursuant to [ETSI 101733], Chapter 6.4.3. The order is important. The values of the individual fields are concatenated with each other. Field SignedData encapContentInfo eContentType
Type
ContentType
Hash value over signed OCTET STRING data (a) SignedData SignerInfo (b) version sid digestAlgorithm signedAttrs signatureAlgorithm signature
CMSVersion SignerIdentifier DigestAlgorithmIdentifier SignedAttributes SignatureAlgorithmIdentifier SignatureValue
ATSHashindex (c)
ats-hash-index
VG
Reference
V
[RFC5652], Chapter 5.2
V
[ETSI 101733], Chapter 6.4.3, Item 2) [RFC5652], Chapter 5.4
V
[RFC5652], Chapter 5.3
V
[ETSI 101733], Chapter 6.4.2
Remarks: (a) – Is calculated analogously to the signed message-digest attribute of the signature. (b) – All instances of the SignerInfo element are taken into account in the order in which they occur and will be sealed with an extra instance of ATSv3. (c) – For further information, see Chapter 6.2.3. Table 29: Structure of message imprint of an ATSv3
6.2.3. ats-hash-index attribute An ats-hash-index is an attribute in the sense of [RFC5652], Chapter 5.3, the structure of which can be found in Table 30.
34
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
Field
Type
VG
Reference
attrType
OBJECT IDENTIFIER (a)
V
[ETSI 101733], Chapter 6.4.2
attrValues
ATSHashIndex (b)
V
[ETSI 101733], Chapter 6.4.2
Remarks: (a) – Pursuant to [ETSI 101733] (Chapter 6.4.3), set to "0.4.0.1733.2.5". (b) – Pursuant to [ETSI 101733] (Chapter 6.4.2), an ats-hash-index attribute shall contain exactly one value element. Table 30: The ats-hash-index attribute
An ats-hash-index attribute refers to a CAdES signature which is secured with an ATSv3. The ATSv3 references the ats-hash-index attribute and includes it as an unsigned attribute of its own signature (see Figure 3).
Figure 3: Connection between CAdES signature, ATSv3 and ats-hash-index
Using the ats-hash-index attribute makes it possible to add certificates, revocation information in SignedData.certificate and SignedData.crls (see Table 7), even after an archive time stamp has already been created for this signature (see [ETSI 101733], Chapter 6.4.2, Note 3 or [ETSI 319122], Chapter 6.5.1, Note 3). The structure of the element of the ATSHashIndex type that represents the value of the ats-hash-index attribute can be found in Table 31. Field
Type
VG
Reference
hashIndAlgorithm
AlgorithmIdentifier (a)
V
[ETSI 101733], Chapter 6.4.2
certificatesHashIndex
SEQ OF OCTET STRING
V
[ETSI 101733], Chapter 6.4.2
crlsHashIndex
SEQ OF OCTET STRING
V
[ETSI 101733], Chapter 6.4.2
unsignedAttrsHashIndex SEQ OF OCTET STRING
V
[ETSI 101733], Chapter 6.4.2
Remarks: (a) – Pursuant to [ETSI 101733], Chapter 6.4.2, id-sha256 by default Table 31: Fields of the ATSHashIndex type
Federal Office for Information Security
35
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
hashIndAlgorithm [obligatory]
Contains the identifier of the hash algorithm used for the generation of the hash values of certificatesHashIndex, crlsHashIndex and unsignedAttrsHashIndex. The algorithm should be identical to the algorithm from the creation of the message imprint element in the associated ATSv3. certificatesHashIndex [obligatory]
A sequence of hash values calculated over each element (in this case, of the CertificateChoices type) of the SignedData.certificates field (see Table 7). crlsHashIndex [obligatory]
A sequence of the hash values calculated over each element (in this case, of the RevocationInfoChoice type) of the SignedData.crls field (see Table 7). unsignedAttrsHashIndex [obligatory]
The content of this element represents a sequence of hash values calculated over each attribute from the set of unsigned attributes with respect to each instance of the SignerInfo element (see Table 13).
36
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
7. Annex D Syntax definitions (informative) This chapter includes an extract of the most important syntax definitions from the documents [RFC4998] and [RFC6283] which is to be used as a reference guide.
7.1. Evidence records pursuant to [RFC4998] An EvidenceRecord is encoded pursuant to [RFC4889] using ASN.1. The following chapters provide the syntactic structure of an ASN.1 EvidenceRecord as extracts from [RFC4998].
7.1.1. EvidenceRecord element pursuant to [RFC4998] The EvidenceRecord has the following ASN.1 syntax (see Listing 1). EvidenceRecord ::= SEQUENCE { version INTEGER { v1(1) } , digestAlgorithms SEQUENCE OF AlgorithmIdentifier, cryptoInfos [0] CryptoInfos OPTIONAL, encryptionInfo [1] EncryptionInfo OPTIONAL, archiveTimeStampSequence ArchiveTimeStampSequence } CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute Listing 1: The EvidenceRecord element pursuant to [RFC4998]
7.1.2. ArchiveTimeStamp element pursuant to [RFC4998] The ArchiveTimeStamp has the following ASN.1 syntax (see Listing 2): ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, attributes [1] Attributes OPTIONAL, reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL, timeStamp ContentInfo} PartialHashtree ::= SEQUENCE OF OCTET STRING Attributes ::= SET SIZE (1..MAX) OF Attribute Listing 2: The ArchiveTimeStamp element pursuant to [RFC4998]
7.1.3. ArchiveTimeStampChain and ArchiveTimeStampSequence pursuant to [RFC4889] The ArchiveTimeStampChain and ASN.1 syntax (see Listing 3).
ArchiveTimeStampSequence
elements have the following
ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp ArchiveTimeStampSequence ::= SEQUENCE OF ArchiveTimeStampChain Listing 3: ArchiveTimeStampChain and ArchiveTimeStampSequence elements pursuant to [RFC4998]
Notice! The elements of the ArchiveTimeStampChain type and of the ArchiveTimeStampSequence type shall be stored chronologically based on the time of the time stamp. Within an element of the ArchiveTimeStampChain type, all contained reduceHashtrees of all ArchiveTimeStamps contained shall use the same hash algorithm.
7.2. Evidence records pursuant to [RFC6283] An EvidenceRecord pursuant to [RFC6283] is defined using the Extensible Markup Language Federal Office for Information Security
37
EvidenceRecord Profiling pursuant to RFC4998 and RFC 6283
(XML). Below, the structure of an EvidenceRecord is represented using the extracts from the [RFC6283]. Notice! The following definitions were represented using a pseudo XML dialect. The following assumptions regarding the cardinality of the elements apply: - "?" - means 0 or 1 (0..1), - "+" - means 1 or more (1..n), - "*" - means 0 or more (0..n).
7.2.1. element pursuant to [RFC6283] Pursuant to [RFC6283], the element has the structure shown in Listing 4. ? + ? ? + ? + ? + + Listing 4: The element
7.2.2. element pursuant to [RFC6283] The element must correspond to the following data structure (see Listing 5).
38
Federal Office for Information Security
EvidenceRecord Profiling pursuant to RFC4998 and RFC6283
base64 encoded hash value + + Listing 5: The element
7.2.3. element pursuant to [RFC6283] Depending on the value of the Type attribute, the element contains either a time stamp token created pursuant to [RFC3161] or an alternative form, such as [TS-ENTRUST] (see [RFC6283], Chapter 3.1.2).
Federal Office for Information Security
39
