1、 ETSI TS 119 122-3 V1.1.1 (2017-01) Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 3: Incorporation of Evidence Record Syntax (ERS) mechanisms in CAdES TECHNICAL SPECIFICATION ETSI ETSI TS 119 122-3 V1.1.1 (2017-01)2 Reference DTS/ESI-000120 Keywords ASN.1, CAdES, el
2、ectronic signature, profile, security ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The prese
3、nt document can be downloaded from: http:/www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI
4、. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that th
5、e document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https:/portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: ht
6、tps:/portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not
7、be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2017. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the b
8、enefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 119 122-3 V1.1.1 (2017-01)3 Contents Intellectual Property R
9、ights 4g3Foreword . 4g3Modal verbs terminology 4g3Introduction 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informative references 5g33 Definitions and abbreviations . 6g33.1 Definitions 6g33.2 Abbreviations . 6g34 General requirements . 6g34.1 Introduction 6g34.2 Inclusion of val
10、idation data within a TimeStampToken instance 6g34.3 Inclusion of validation data within CAdES signatures . 7g35 Attribute semantics and syntax . 7g35.1 The evidence-records attributes 7g35.2 The internal-evidence-records attribute . 9g35.3 The external-evidence-records attribute . 11g36 CAdES signa
11、ture level including ERS . 13g36.1 Overview 13g36.2 General requirements . 13g36.3 CAdES-E-ERS . 13g3History 17g3ETSI ETSI TS 119 122-3 V1.1.1 (2017-01)4 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information perta
12、ining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secreta
13、riat. Latest updates are available on the ETSI Web server (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on
14、the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and Infrastructures (ESI). The present document is part 3 of a multi-part deliverable covering C
15、AdES digital signatures. Full details of the entire series can be found in part 1 4. Modal verbs terminology In the present document “shall“, “shall not“, “should“, “should not“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI Dr
16、afting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. Introduction Evidence record syntax (ERS) allows to cover different data objects with a single time-stamp, and subsequently augment the lifeti
17、me of the evidence record (ER) by adding validation data to the previous time-stamp and adding new time-stamps. The aim of the present document is to provide clear indications how to bind an ERS to a CAdES signature which is covered by the ERS. NOTE: ETSI EN 319 162-1 i.5 and ETSI EN 319 162-2 i.6 s
18、pecify the use of ERS in ASiC. ETSI ETSI TS 119 122-3 V1.1.1 (2017-01)5 1 Scope The present document provides mechanism to incorporate evidence records in ASN.1 format within a CAdES signature as outlined in ETSI EN 319 122-1 4, annex B. It specifies the attributes to be used and profiles the ERS st
19、andard (IETF RFC 4998 2) to provide clear rules how to incorporate ERS within a CAdES signature or a legacy CAdES signature. 2 References 2.1 Normative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific
20、references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at https:/docbox.etsi.org/Reference. NO
21、TE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are necessary for the application of the present document. 1 IETF RFC 3161 (2001): “Internet X.509 Public Key Infrastructure Time
22、-Stamp Protocol (TSP)“. 2 IETF RFC 4998 (2007): “Evidence Record Syntax (ERS)“. 3 IETF RFC 5816 (2010): “ESSCertIDv2 Update for RFC 3161“. 4 ETSI EN 319 122-1: “Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures“. 2.2 Info
23、rmative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments
24、) applies. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular s
25、ubject area. i.1 ETSI TR 119 001: “Electronic Signatures and Infrastructures (ESI); The framework for standardization of signatures; Definitions and abbreviations“. i.2 ETSI TS 101 733: “Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures (CAdES)“. i.3 ETSI EN 319 122
26、-2: “Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 2: Extended CAdES signatures“. i.4 ETSI TS 119 312: “Electronic Signatures and Infrastructures (ESI); Cryptographic Suites“. i.5 ETSI EN 319 162-1: “Electronic Signatures and Infrastructures (ESI); Associated Signat
27、ure Containers (ASiC); Part 1: Building blocks and ASiC baseline containers“. i.6 ETSI EN 319 162-2: “Electronic Signatures and Infrastructures (ESI); Associated Signature Containers (ASiC); Part 2: Additional ASiC containers“. ETSI ETSI TS 119 122-3 V1.1.1 (2017-01)6 i.7 ETSI TS 119 172-1: “Electro
28、nic Signatures and Infrastructures (ESI); Signature policies; Part 1: Building blocks and table of contents for human readable signature policy documents“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in ETSI TR 119 001 i.1
29、, ETSI EN 319 122-1 4 and the following apply: archive-timestamp: timestamp which is used for long-term preservation purposes EXAMPLE: An archive-timestamp can for example be a TimeStampToken according to IETF RFC 3161 1 and updated by IETF RFC 5816 3 or an ArchiveTimeStamp according to IETF RFC 499
30、8 2. evidence-record: Evidence Record according to IETF RFC 4998 2. evidence-records attribute: unsigned attribute which contains one or more evidence-records as defined in the present document evidence record renewal: either time-stamp renewal or hash-tree renewal within an evidence record initial
31、ArchiveTimeStamp: the first ArchiveTimeStamp instance of the first ArchiveTimeStampChain instance within the ArchiveTimeStampSequence instance NOTE: ArchiveTimeStamp, ArchiveTimeStampChain and ArchiveTimeStampSequence are as defined in IETF RFC 4998 2. validation data: data that is used to validate
32、a digital signature 3.2 Abbreviations For the purposes of the present document, the abbreviations given in ETSI TR 119 001 i.1 and the following apply: ER Evidence Record ERS Evidence Record Syntax TSU Time Stamping Unit 4 General requirements 4.1 Introduction This clause specifies mechanisms how to
33、 include validation data into the signature. 4.2 Inclusion of validation data within a TimeStampToken instance When including validation data within a TimeStampToken instance according to IETF RFC 3161 1 and updated by IETF RFC 5816 3 one of the following methods shall be used: 1) adding the informa
34、tion in the SignedData of the timestamp token; or ETSI ETSI TS 119 122-3 V1.1.1 (2017-01)7 2) adding the certificate-values attribute according to ETSI EN 319 122-1 4, clause A.1.1.2 and the revocation-values attribute according to ETSI EN 319 122-1 4, clause A.1.2.2 as unsigned attributes within th
35、e TimeStampToken instance. Method 1) should be used. 4.3 Inclusion of validation data within CAdES signatures The present document specifies two strategies for the inclusion of validation data within a CAdES signature, depending on whether attributes for long term availability, as defined in differe
36、nt versions of ETSI TS 101 733 i.2, have already been added to the SignedData: If none of ATSv2 attributes (see clause A.2.4 of ETSI EN 319 122-1 4), or an earlier form of archive time-stamp as defined in ETSI TS 101 733 i.2 or long-term-validation (see clause A.2.5 of ETSI EN 319 122-1 4) attribute
37、s is already present in any SignerInfo of the root SignedData, then the new validation material shall be included within the root SignedData.certificates, or SignedData.crls as applicable. If an ATSv2, or other earlier form of archive time-stamp or a long-term-validation attribute, is present in any
38、 SignerInfo of the root SignedData then the root SignedData.certificates and SignedData.crls contents shall not be modified. The new validation material shall be provided within the TimeStampToken instance of the latest archive time-stamp (which can be an ATSv2 or an ATSv3 as defined in clause 5.5.3
39、 of ETSI EN 319 122-1 4) or within the latest long-term-validation attribute already contained in the SignerInfo as described in ETSI EN 319 122-1 4, clause A.2.5. OCSP responses shall be included as defined in clause 5.4.2 of ETSI EN 319 122-1 4. If the OCSP response is included within SignedData.c
40、rls, it shall be included as defined in clause 5.4.2.2 of ETSI EN 319 122-1 4. When generating a new attribute to include validation data, either initially when creating the signature or later when augmenting the signature, it shall be encoded in DER (see clause 4.7.1 of ETSI EN 319 122-1 4), whilst
41、 preserving the encoding of any signed field included in the attribute. The augmentation shall preserve the binary encoding of already present unsigned attributes and any component contributing to the archive time-stamps message imprint computation input. 5 Attribute semantics and syntax 5.1 The evi
42、dence-records attributes In the present document two attributes are described that allow to include an evidence record (ER) over the whole SignedData instance: The internal-evidence-records attribute (clause 5.2) protects the whole SignedData instance and is used in cases of attached signatures. The
43、 external-evidence-records attribute (clause 5.3) also protects the whole SignedData instance not containing an eContent element within encapContentInfo (a detached signature), and the external signed data. The term “evidence-records attribute“ is used to denote either one of these attributes. ETSI
44、ETSI TS 119 122-3 V1.1.1 (2017-01)8 Semantics The evidence-records attribute shall be an unsigned attribute. At most one of the SignerInfo instances within the SignedData instance shall contain evidence-records attributes. If the SignerInfo instance contains more than one evidence-records attribute,
45、 only the ER(s) in the latest added evidence-records attribute shall be updated. NOTE 1: Updating one of the ER in the other evidence-records attributes will invalidate the ER(s) in the later added evidence-records attribute(s). Once an evidence-records attribute is included within a SignedData inst
46、ance, the only changes that might be applied to the SignedData instance are the renewal of the ER within the evidence-records attribute, the adding of a new ER within a new AttributeValue of the latest evidence record attribute or the adding of another evidence-records attribute. No other changes sh
47、all be applied to the SignedData instance. Syntax The ContentInfo instance shall be DER encoded before computing the hash. The evidence-records attribute may contain one or more instances of AttributeValue type. The evidence-records attribute should contain one instance of AttributeValue type. If th
48、e evidence-records attribute contains more than one instance of AttributeValue type, the input of the message imprint computation of all initial ArchiveTimeStamp within each of the AttributeValue instances shall include at least exactly the same fields within the signature and the signed document. T
49、he parts of the reduced hash-tree not corresponding to the signature or the signed document may be different. NOTE 2: Having more than one instance of AttributeValue type allows to have parallel evidence-records (from different TSAs or with different hash algorithms) protecting the same signature. NOTE 3: This means that if a signature contains already an evidence-records attribute with more than one instance of AttributeValue type, and a new evidence-records attribute is added (with one or mor
