SIST EN 319 142-2 V1.1.1:2016
(Main)Electronic Signatures and Infrastructures (ESI) - PAdES digital signatures - Part 2: Additional PAdES signatures profiles
Electronic Signatures and Infrastructures (ESI) - PAdES digital signatures - Part 2: Additional PAdES signatures profiles
The present document defines multiple profiles for PAdES digital signatures which are digital signatures embedded
within a PDF file.
The present document contains a profile for the use of PDF signatures, as described in ISO 32000-1 [1] and based on
CMS digital signatures [i.6], that enables greater interoperability for PDF signatures by providing additional restrictions
beyond those of ISO 32000-1 [1]. This first profile is not related to ETSI EN 319 142-1 [4].
The present document also contains a second set of profiles that extend the scope of the profile in PAdES part 1 [5],
while keeping some features that enhance interoperability of PAdES signatures. These profiles define three levels of
PAdES extended signatures addressing incremental requirements to maintain the validity of the signatures over the long
term, in a way that a certain level always addresses all the requirements addressed at levels that are below it. These
PAdES extended signatures offer a higher degree of optionality than the PAdES baseline signatures specified in ETSI
EN 319 142-1 [4].
The present document also defines a third profile for usage of an arbitrary XML document signed with XAdES
signatures that is embedded within a PDF file.
The profiles defined in the present document provide equivalent requirements to profiles found in ETSI
TS 102 778 [i.10].
Procedures for creation, augmentation, and validation of PAdES digital signatures are out of scope and specified in
ETSI EN 319 102-1 [i.11]. Guidance on creation, augmentation and validation of PAdES digital signatures including
the usage of the different attributes is provided in ETSI TR 119 100 [i.9].
The present document does not repeat the base requirements of the referenced standards, but instead aims to maximize
interoperability of digital signatures in various business areas.
Elektronski podpisi in infrastruktura (ESI) - Digitalni podpisi PAdES - 2. del: Dodatni profili podpisov PAdES
V tem dokumentu je določenih več profilov za digitalne podpise PAdES, ki so vdelani v datoteko PDF.
Ta dokument vključuje profil za uporabo podpisov PDF, kot je opisano v standardu ISO 32000-1 [1], na podlagi digitalnih podpisov CMS [i.6], kar omogoča večjo interoperabilnost za podpise PDF z zagotavljanjem dodatnih omejitev, poleg omejitev iz standarda ISO 32000-1 [1]. Ta prvi profil ni povezan s standardom ETSI EN 319 142-1 [4].
Dokument vključuje še en sklop profilov, ki razširjajo obseg profila iz 1.dela PAdES [5] in hkrati ohranjajo nekatere funkcije, ki izboljšajo interoperabilnost podpisov PAdES. Ti profili določajo tri ravni razširjenih podpisov PAdES, ki obravnavajo naraščajoče zahteve po dolgoročnem ohranjanju veljavnosti podpisov, pri čemer določena raven vedno obravnava vse zahteve, obravnavane na njenih podravneh. Ti razširjeni podpisi PAdES nudijo večjo možnost izbire kot izhodiščni podpisi PAdES iz standarda ETSI EN 319 142-1 [4].
V tem dokumentu je določen še tretji profil za uporabo poljubnega dokumenta XML s podpisi XAdES, ki je vdelan v datoteko PDF.
Zahteve profilov, določenih v tem dokumentu, so enakovredne zahtevam profilov iz standarda ETSI TS 102 778 [i.10].
Postopki izdelave, razširitve in potrjevanja digitalnih podpisov PAdES v tem dokumentu niso zajeti ter so določeni v standardu ETSI EN 319 102-1 [i.11]. Smernice glede izdelave, razširitve in potrjevanja digitalnih podpisov PAdES, vključno z uporabo različnih atributov, so podane v standardu ETSI TR 119 100 [i.9].
Ta dokument ne ponavlja osnovnih zahtev navedenih standardov, temveč poskuša povečati interoperabilnost digitalnih podpisov na različnih poslovnih področjih.
General Information
Standards Content (Sample)
Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
EUROPEAN STANDARD
Electronic Signatures and Infrastructures (ESI);
PAdES digital signatures;
Part 2: Additional PAdES signatures profiles
2 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
Reference
DEN/ESI-0019142-2
Keywords
electronic signature, PAdES, 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 enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present 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. 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 the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
https://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 be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2015.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP 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
3 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions and abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 10
4 Profile for CMS digital signatures in PDF . 10
4.1 Features . 10
4.2 Requirements of Profile for CMS Signatures in PDF . 10
4.2.1 Requirements on PDF signatures . 10
4.2.2 Requirements on PDF signature handlers . 11
4.2.3 Requirements on signature validation . 11
4.2.4 Requirements on Time Stamping . 11
4.2.4.1 Requirements on electronic time-stamp creation . 11
4.2.4.2 Requirements on electronic time-stamp validation . 12
4.2.5 Requirements on revocation checking . 12
4.2.6 Requirements on Seed Values . 12
4.2.7 Requirements on encryption . 12
5 Extended PAdES signature profiles . 12
5.1 Features . 12
5.2 General Requirements . 12
5.2.1 Requirements from Part 1 . 12
5.2.2 Notation of Requirements . 12
5.3 PAdES-E-BES Level . 13
5.4 PAdES-E-EPES Level . 15
5.5 PAdES-E-LTV Level . 15
6 Profiles for XAdES Signatures signing XML content in PDF . 15
6.1 Features . 15
6.2 Profiles for XAdES signatures of signed XML documents embedded in PDF containers . 15
6.2.1 Overview . 15
6.2.2 Profile for Basic XAdES signatures of XML documents embedded in PDF containers . 17
6.2.2.1 Features . 17
6.2.2.2 General syntax and requirements . 18
6.2.2.3 Requirements for applications generating signed XML document to be embedded . 18
6.2.2.4 Mandatory operations. 19
6.2.2.4.1 Protecting the signing certificate . 19
6.2.2.5 Requirements on XAdES optional properties . 19
6.2.2.6 Serial Signatures . 19
6.2.2.7 Parallel Signatures . 19
6.2.2.8 PAdES Signatures . 20
6.2.3 Profile for long-term XAdES signatures of signed XML documents embedded in PDF containers . 20
6.2.3.1 Features . 20
6.2.3.2 Augmentation mechanism . 20
6.2.3.3 Optional properties . 20
6.2.3.4 Validation Process . 20
6.3 Profiles for XAdES signatures on XFA Forms . 20
6.3.1 Overview . 20
6.3.2 Profile for Basic XAdES signatures on XFA forms . 23
ETSI
4 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
6.3.2.1 Features . 23
6.3.2.2 General syntax and requirements . 23
6.3.2.3 Mandatory operations. 24
6.3.2.3.1 Protecting the signing certificate . 24
6.3.2.4 Requirements on XAdES optional properties . 24
6.3.2.5 Serial Signatures . 25
6.3.2.6 Parallel Signatures . 26
6.3.3 Profile for long-term validation XAdES signatures on XFA forms . 26
6.3.3.1 Overview . 26
6.3.3.2 Features . 26
6.3.3.3 General Requirements . 26
6.3.4 Extensions Dictionary . 26
Annex A (informative): General Features . 27
A.1 PDF signatures . 27
A.2 PDF Signature types . 28
A.3 PDF Signature Handlers . 28
A.4 PDF serial signatures . 28
A.5 PDF signature Validation and Time-stamping . 29
A.6 ISO 19005-1: 2005 (PDF/A-1) . 29
A.7 ISO 19005-2:2011 (PDF/A-2) . 30
A.8 Seed Values and Signature Policies . 30
History . 31
ETSI
5 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining 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 Secretariat. Latest updates are available on the ETSI Web
server (http://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 the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This draft European Standard (EN) has been produced by ETSI Technical Committee Electronic Signatures and
Infrastructures (ESI), and is now submitted for the combined Public Enquiry and Vote phase of the ETSI standards EN
Approval Procedure.
The present document is part 2 of a multi-part deliverable covering the PDF digital signatures (PAdES), as identified
below.
Part 1: "Building blocks and PAdES baseline signatures";
Part 2: "Additional PAdES signatures profiles".
Proposed national transposition dates
Date of latest announcement of this EN (doa): 3 months after ETSI publication
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 6 months after doa
Date of withdrawal of any conflicting National Standard (dow): 6 months after doa
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 Drafting 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
Electronic commerce has emerged as a frequent way of doing business between companies across local, wide area and
global networks. Trust in this way of doing business is essential for the success and continued development of
electronic commerce. It is therefore important that companies using this electronic means of doing business have
suitable security controls and mechanisms in place to protect their transactions and to ensure trust and confidence with
their business partners. In this respect digital signatures are an important security component that can be used to protect
information and provide trust in electronic business.
The present document is intended to cover digital signatures supported by PKI and public key certificates. This includes
evidence as to its validity even if the signer or verifying party later attempts to deny (i.e. repudiates; see
ISO/IEC 10181-4 [i.1]) the validity of the signature.
ETSI
6 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
Thus, the present document can be used for any document encoded in a portable document format (PDF) produced by
an individual and a company, and exchanged between companies, between an individual and a governmental body, etc.
The present document is independent of any environment; it can be applied to any environment, e.g. smart cards, SIM
cards, special programs for digital signatures, etc.
The present document is part of a rationalized framework of standards (see ETSI TR 119 000 [i.8]). See ETSI
TR 119 100 [i.9] for getting guidance on how to use the present document within the aforementioned framework.
ETSI
7 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
1 Scope
The present document defines multiple profiles for PAdES digital signatures which are digital signatures embedded
within a PDF file.
The present document contains a profile for the use of PDF signatures, as described in ISO 32000-1 [1] and based on
CMS digital signatures [i.6], that enables greater interoperability for PDF signatures by providing additional restrictions
beyond those of ISO 32000-1 [1]. This first profile is not related to part 1 of ETSI EN 319 142 [4].
The present document also contains a second set of profiles that extend the scope of the profile in PAdES part 1 [5],
while keeping some features that enhance interoperability of PAdES signatures. These profiles define three levels of
PAdES extended signatures addressing incremental requirements to maintain the validity of the signatures over the long
term, in a way that a certain level always addresses all the requirements addressed at levels that are below it. These
PAdES extended signatures offer a higher degree of optionality than the PAdES baseline signatures specified in part 1
of ETSI EN 319 142 [4].
The present document also defines a third profile for usage of an arbitrary XML document signed with XAdES
signatures that is embedded within a PDF file.
The profiles defined in the present document provide equivalent requirements to profiles found in ETSI
ETSI TS 102 778 [i.10].
The present document does not repeat the base requirements of the referenced standards, but instead aims to maximize
interoperability of digital signatures in various business areas.
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 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
http://docbox.etsi.org/Reference.
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 necessary for the application of the present document.
[1] ISO 32000-1: "Document management - Portable document format - Part 1: PDF 1.7".
NOTE: Available at http://www.adobe.com/devnet/acrobat/pdfs/PDF32000_2008.pdf.
[2] IETF RFC 2315: "PKCS #7: Cryptographic Message Syntax Version 1.5".
[3] IETF RFC 5280: "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile".
[4] ETSI EN 319 142-1: "Electronic Signatures and Infrastructures (ESI); PAdES digital signatures;
Part 1: Building blocks and PAdES baseline signatures".
[5] ETSI EN 319 122-1: "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures;
Part 1: Building blocks and CAdES baseline signatures".
[6] ETSI EN 319 132-1: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures;
Part 1: Building blocks and XAdES baseline signatures".
[7] ETSI EN 319 132-2: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures;
Part 2: Extended XAdES signatures".
ETSI
8 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
[8] Adobe ® XFA: "XML Forms Architecture (XFA) Specification" version 2.5, (June 2007), Adobe
Systems Incorporated".
[9] W3C Recommendation: "XML-Signature Syntax and Processing. Version 1.1".
[10] IETF RFC 5035 (2007): "Enhanced Security Services (ESS) Update: Adding CertID Algorithm
Agility".
[11] IETF RFC 3161 (2001): "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)".
[12] IETF RFC 5816 (2010): "ESSCertIDv2 Update for RFC 3161".
2.2 Informative 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
reference document (including any amendments) 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 subject area.
[i.1] ISO/IEC 10181-4: "Information technology - Open Systems Interconnection - Security
frameworks for open systems: Non-repudiation framework".
[i.2] ETSI TS 119 312: "Electronic Signatures and Infrastructures (ESI); Cryptographic Suites".
[i.3] IETF RFC 5755: "An Internet Attribute Certificate Profile for Authorization".
[i.4] W3C® Working Group Note, XML Signature Best Practices, 11 April 2013.
[i.5] ISO 19005-1:2005: "Document management - Electronic document file format for long-term
preservation - Part 1: Use of PDF 1.4 (PDF/A-1)".
[i.6] IETF RFC 5652 (2009): "Cryptographic Message Syntax (CMS)".
[i.7] ISO 19005-2 (2011): "Document management - Electronic document file format for long-term
preservation - Part 2: Use of ISO 32000-1 (PDF/A-2)".
[i.8] ETSI TR 119 000: "Electronic Signatures and Infrastructures (ESI); Rationalized structure for
Electronic Signature Standardization".
[i.9] ETSI TR 119 100: "Electronic Signatures and Infrastructures (ESI); Business Driven Guidance for
Signature Creation and Validation".
[i.10] ETSI TS 102 778: "Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic
Signature Profiles; CMS Profile based on ISO 32000-1".
ETSI
9 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ISO 32000-1 [1] and the following apply:
certificate: public key of a user, together with some other information, rendered un-forgeable by encipherment with the
private key of the certification authority which issued it
certificate policy (CP): named set of rules that indicates the applicability of a certificate to a particular community
and/or class of application with common security requirements
Certificate Revocation List (CRL): signed list indicating a set of public key certificates that are no longer considered
valid by the certificate issuer
Certification Authority (CA): authority trusted by one or more users to create and assign public key certificates;
optionally, the certification authority may create the users' keys
certification signature: digital signature that is used in conjunction with Modification Detection Permissions (MDP) as
defined by ISO 32000-1 [1], clause 12.8.2.2
electronic time-stamp: data object that binds a representation of a datum to a particular time, thus establishing
evidence that the datum existed at that time
NOTE: In the case of IETF RFC 3161 [11] updated by IETF RFC 5816 [12] protocol, the electronic time-stamp
is referring to the timeStampToken field within the TimeStampResp element (the TSA's response
returned to the requesting client).
PAdES signature: digital signature that satisfies the requirements specified within the present document
PDF serial signature: specific digital signature where the second (and subsequent) signers of a PDF not only sign the
document but also the signature of the previous signer and any modification that can also have taken place (e.g. form
fill-in)
PDF signature: DER-encoded binary data object based on the PKCS #7 [2] or the CMS (IETF RFC 5652 [i.6]) or
related syntax containing a digital signature and other information necessary to validate the electronic signature such as
the signer's certificate along with any supplied revocation information placed within a PDF document structure as
specified in ISO 32000-1 [1], clause 12.8
relying party: natural or legal person that relies upon electronic identification or trust service
seed value dictionary: PDF data structure, of type dictionary, as described in ISO 32000-1 [1], clause 12.7.4.5,
table 234, that contains information that constrains the properties of a digital signature that is applied to a specific
Signature field
signature dictionary: PDF data structure, of type dictionary, as described in ISO 32000-1 [1], clause 12.8.1, table 252
that contains all information about the digital signature
signature handler: software application, or part of a software application, that knows how to perform digital signature
operations (e.g. signing and/or validating) in conformance with ISO 32000-1 [1] and the requirements of the appropriate
profile
signer: natural or legal person who creates a digital signature
Time-Stamping Authority (TSA): trusted third party that creates electronic time-stamps in order to indicate that a
datum existed at a particular point in time
validation data: data that can be used by a verifier of digital signatures to determine that a digital signature is valid
(e.g. certificates, CRLs, OCSP responses)
ETSI
10 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
CA Certification Authority
CAdES CMS Advanced Electronic Signatures
NOTE: As per ETSI EN 319 122-1 [5].
CMS Cryptographic Message Syntax
NOTE: As specified in IETF RFC 5652 [i.6].
CRL Certificate Revocation List
DER Distinguished Encoding Rules
OCSP Online Certificate Status Protocol
PDF Portable Document Format
TSA Time-Stamping Authority
4 Profile for CMS digital signatures in PDF
4.1 Features
The present profile specifies digital signatures that:
• Are encoded in CMS as defined by PKCS #7 1.5 (see IETF RFC 2315 [2]).
• Support serial signatures.
• Optionally include signature time-stamps.
• Optionally include revocation information.
• Protect integrity of the document and authenticates the signer identity information included in the signing
certificate.
• Can optionally include the "reasons" for the signature.
• Can optionally include a description of the location of signing.
• Can optionally include contact info of the signer.
A "legal content attestation" can be used to indicate to the relying party the PDF capabilities which may affect the
signed document (e.g. JavaScript).
4.2 Requirements of Profile for CMS Signatures in PDF
4.2.1 Requirements on PDF signatures
While ISO 32000-1 [1], clause 12.8 clearly states the majority of the requirements necessary for conformance with this
profile, this clause specifies additional requirements for conformance.
a) PDF Signatures shall be as specified in ISO 32000-1 [1], clause 12.8.
b) The signature information shall be embedded into the document itself and the ByteRange shall be the entire
file, including the signature dictionary but excluding the PDF Signature itself.
c) The PDF Signature (a DER-encoded PKCS#7 binary data object) shall be placed into the Contents entry of
the signature dictionary.
ETSI
11 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
d) The PKCS#7 object shall conform to the PKCS#7 specification in IETF RFC 2315 [2]. At minimum, it shall
include the signer's X.509 signing certificate.
NOTE 1: Although ISO 32000-1 [1] also allows the value of the Contents entry of signature dictionary to be a
DER-encoded PKCS#1 binary data object, that format is not supported by this profile.
e) Timestamping and revocation information should be included in the PDF Signature. This revocation
information and as much of the complete chain of certificates as is available should be captured and validated
before completing the creation of the PDF Signature.
f) If present, any revocation information shall be a signed attribute of the PDF Signature.
g) IETF RFC 5755 [i.3] attribute certificates associated with the signer certificate should not be used.
NOTE 2: ISO 32000-1 [1] allows the inclusion of one or more IETF RFC 5755 [i.3] attribute certificates associated
with the signer certificate. However, attribute certificates are not widely supported and hence use of this
attribute will reduce interoperability.
h) There shall only be a single signer (i.e. one single component of "SignerInfo" type within "signerInfos"
element) in any PDF Signature.
4.2.2 Requirements on PDF signature handlers
a) A PDF reader may substitute a different signature handler, other than that specified in Filter, when validating
the signature, as long as it supports the specified SubFilter format.
b) Only the two values for SubFilter listed in ISO 32000-1 [1], clause 12.8.3.3.1 (i.e. adbe.pkcs7.detached and
adbe.pkcs7.sha1) shall be used.
NOTE: While the names of the SubFilters can imply specific algorithms, the actual list of supported algorithms
can be found in ISO 32000-1 [1], clause 12.8.3.3.2, table 257. Consult ETSI TS 119 312 [i.2] for
guidance on algorithm choices.
The use of SHA-1 is being phased out and hence other hashing algorithms should be used.
4.2.3 Requirements on signature validation
When the user opens a signed document and requests validation of the signature(s) present in the PDF, a reader shall
invoke the appropriate signature handler that shall perform the following steps to validate them.
a) Validate that the document digest matches that in the signature as specified in ISO 32000-1 [1], clause 12.8.1.
b) Validate the path of certificates used to validate the binding between the subject distinguished name and
subject public key as specified in IETF RFC 5280 [3]. The validity checks shall be carried out at the time
indicated either by electronic time-stamp applied as per clause 4.2.4 or some other trusted indication of the
signing time. The revocation status shall be checked as specified in clause 4.2.5.
c) To achieve consistent validation results with existing signatures and existing implementations of signature
handlers, that did not know this attribute, the signing certificate reference attribute itself should be ignored
during validation if present.
NOTE: Unlike any other Profile in the present document inclusion of the certificate hash (see CAdES [5],
clause 5.2.2) is not required by this profile. Applications requiring the existence of certificate hash can
use signatures based on PAdES baseline profiles [4] or the profile defined in clause 5.3 or the profile
defined in clause 5.4.
4.2.4 Requirements on Time Stamping
4.2.4.1 Requirements on electronic time-stamp creation
a) An electronic time-stamp from a trusted TSA should be applied to the digital signature as soon as possible
after the signature is created so the electronic time-stamp reflects the time after the document was signed.
b) If a signature handler chooses to embed an electronic time-stamp into the PDF Signature, then it shall be
embedded as described in ISO 32000-1 [1], clause 12.8.3.3.1.
ETSI
12 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
4.2.4.2 Requirements on electronic time-stamp validation
a) A signature handler shall take the signature field of the PKCS#7 signature, encode it and compute the digest of
the resulting byte stream using the algorithm indicated in the electronic time-stamp.
b) A signature handler shall check if the value obtained in the first step is the same as the digest present in the
electronic time-stamp.
4.2.5 Requirements on revocation checking
When validating the PDF Signature, a signature handler may ignore any embedded revocation information in favour of
alternative storage or referenced data as per its own policies.
4.2.6 Requirements on Seed Values
Seed values that would require a signature handler to violate this profile shall not be used.
EXAMPLE: Seed values that specify the use of PKCS#1 are not permitted as the present document requires use
of PKCS#7.
4.2.7 Requirements on encryption
The Requirements in PAdES Part 1 [4], clause 5.5 shall apply.
5 Extended PAdES signature profiles
5.1 Features
The profiles in this clause define PAdES signatures based on the building blocks defined in PAdES Part 1 [4]. These
profiles define three levels of PAdES extended signatures that offer a higher degree of optionality than the PAdES
baseline signatures specified in part 1 [4].
PAdES-E-BES Level allows basic digital signatures embedded within a PDF file. There is a unambiguous connection
from the signature to the identity of a certificate intended to identify the signer.
PAdES-E-EPES Level is built on top of the PAdES-E-BES Level and allows inclusion of signature policies.
PAdES-E-LTV can build on either PAdES-E-BES Level or PAdES-E-EPES Level addressing incremental requirements
to maintain the validity of the signatures over the long term.
5.2 General Requirements
5.2.1 Requirements from Part 1
The requirements given in clause 4.1 of [4] (PAdES Part 1) shall apply to all profiles in this clause.
5.2.2 Notation of Requirements
The present clause describes the notation used for defining the requirements of the different extended PAdES signature
profiles.
The requirements on the attributes and certain signature fields are expressed in tables. A row in the table either specifies
requirements for an attribute or a service.
These tables contain five columns.
1) Column "Attribute/Field/Service":
- this cell contains the name of the attribute or signature field.
ETSI
13 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
2) Colum "Presence": This cell contains the specification of the presence of the attribute or signature as follows:
- "shall be present": means that the attributes or signature fields shall be present, and shall be as specified
in the document referenced in column "References", further profiled with the additional requirements
referenced in column "Requirements", and with the cardinality indicated in column "Cardinality".
- "shall not be present": means that the attributes or signature fields shall not be present.
- "may be present": means that the attributes or signature fields may be present, and shall be as specified in
the document referenced in column "References", further profiled with the additional requirements
referenced in column "Requirements", and with the cardinality indicated in column "Cardinality".
- "conditioned presence": means that the presence of the item identified in the first column is conditioned
as per the requirement(s) specified in column "Requirements" and requirements referenced by column
"References" with the cardinality indicated in column "Cardinality".
3) Column "Cardinality". This cell indicates the cardinality of the attribute or signature field as follows:
- 0: The signature shall not incorporate any instance of the attribute or signature field.
- 1: The signature shall incorporate exactly one instance of the attribute or signature field.
- 0 or 1: The signature shall incorporate zero or one instance of the attribute or signature field.
- ≥ 0: The signature shall incorporate zero or more instances of the attribute or signature field.
- ≥ 1: The signature shall incorporate one or more instances of the attribute or signature field.
4) Column "Additional notes and requirements". This cell contains numbers referencing notes and/or letters
referencing additional requirements on the attribute or signature field. Both notes and additional requirements
are listed below the table.
5) Column "Reference": This cell contains either the number of the clause specifying the attribute in the present
document, or a reference to the document and clause that specifies the signature field.
5.3 PAdES-E-BES Level
The requirements and the attributes within signature dictionary and SignerInfo are as defined in table 1.
For any optional unsigned attribute incorporated in the signature, DER encoding shall be used for this attribute, whilst
preserving the encoding of any other attribute field.
ETSI
14 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
Table 1: Requirements for the main attributes in PAdES-BES signature
Attribute/Field/Service Presence Cardinality Additional notes Reference
and requirements
content-type
1 a ETSI EN 319 122-1 [5],
shall be present
clause 5.1.1
message-digest
1 ETSI EN 319 122-1 [5],
shall be present
clause 5.1.2
signing-certificate reference
shall be present 1 b, c, d
signer-attributes-v2 may be present 0 or 1 ETSI EN 319 122-1 [5],
clause 5.2.6.1
content-time-stamp may be present ≥ 0 ETSI EN 319 122-1 [5],
clause 5.2.8
signature-time-stamp
may be present ≥ 0 ETSI EN 319 122-1 [5],
clause 5.3
entry with key M in the
may be present 0 or 1 e ISO 32000-1 [1],
Signature Dictionary
clause 12.8.1
entry with key Location in
may be present 0 or 1 ISO 32000-1 [1],
the Signature Dictionary
clause 12.8.1
entry with key Reason in the
may be present 0 or 1 ISO 32000-1 [1],
Signature Dictionary
clause 12.8.1
f
entry with key Filter in the 1 ISO 32000-1 [1],
shall be present
Signature Dictionary
clause 12.8.1
g
entry with key ByteRange in
1 ISO 32000-1 [1],
shall be present
the Signature Dictionary
clause 12.8.1
entry with key SubFilter in h
1 ISO 32000-1 [1],
shall be present
the Signature Dictionary
clause 12.8.1
entry with key Contents in i
1 ISO 32000-1 [1],
shall be present
the Signature Dictionary
clause 12.8.1
entry with key Name in the 0 or 1 ISO 32000-1 [1],
may be present
Signature Dictionary
clause 12.8.1
entry with key ContactInfo in 0 or 1 ISO 32000-1 [1],
may be present
the Signature Dictionary
clause 12.8.1
entry with key Cert in the
shall not be 0 ISO 32000-1 [1],
Signature Dictionary
present clause 12.8.1
Additional requirements:
a) The content-type attribute shall have value id-data.
b) As specified in IETF RFC 5035 [10], the ESS signing-certificate attribute shall be used if the SHA-1
hash algorithm is used.
c) As specified in IETF RFC 5035 [10], the ESS signing-certificate-v2 attribute shall be used when
another hash algorithms than SHA-1 is used.
d) The generator should migrate to the use of ESS signing-certificate-v2 in preference to ESS
signing-certificate in line with the guidance regarding limited lifetime for the use of SHA-1 given in
ETSI TS 119 312 [i.2].
e) The generator should include the claimed UTC time of the signature in a format defined in ISO 32000-1 [1],
clause 7.9.4 as content of this element.
f) A verifier may substitute a different signature handler, other than that specified in Filter, when validating the
signature, as long as it supports the specified SubFilter format.
g) The ByteRange shall cover the entire file, including the signature dictionary but excluding the PDF Signature
itself.
h) The signature dictionary shall contain a value of ETSI.CAdES.detached for the key SubFilter.
i) Requirements specified in ISO 32000-1 [1], clauses 12.8.3.2 (PKCS#1) and 12.8.3.3 (PKCS#7) shall not be
used.
ETSI
15 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
5.4 PAdES-E-EPES Level
The requirements and the attributes within SignerInfo are as defined in table 1 to which those ones defined in
table 2 shall be added/replaced.
For any optional unsigned attribute incorporated in the signature, DER encoding shall be used for this attribute, whilst
preserving the encoding of any other attribute field.
Table 2: Requirements for the main CAdES attributes in PAdES-E-EPES level
Attribute/Field/Service Presence Cardinality Additional notes and Reference
requirements
signature-policy-identifier
shall be 1 ETSI EN 319 122-1 [5],
present clause 5.2.9
commitment-type-indication may be 0 or 1 ETSI EN 319 122-1 [5],
present clause 5.2.3
entry with key Reason in the
shall not be 0 ISO 32000-1 [1],
Signature Dictionary
present clause 12.8.1
5.5 PAdES-E-LTV Level
Signature handlers creating and/or validating PDF documents with PAdES-LTV shall support PDF documents with:
a) Document security store information as specified in clause 5.4.2 in ETSI EN 319 142-1 [4].
b) Document time-stamps as specified in clause 5.4.3 in ETSI EN 319 142-1 [4].
Signed PDF documents should contain DSS followed by a document time-stamp.
Validation data shall be carried by values within the DSS.
NOTE 1: Use of validation data in DSS referencing external sources is not supported by the current profile.
Systems shall support creation and/or validation of signatures with one or more DSS entries and document time-stamps.
NOTE 2: Object IDs should not be reused when adding new validation data, because of the possibility to "hide"
already existing validation data. A signature handler may check the existence of older validation data
having the same Object IDs to be explicitly aware of the fact that the latest objects could contain invalid
or unusable validation data.
6 Profiles for XAdES Signatures signing XML content
in PDF
6.1 Features
The profiles in this clause allow the signing of XML Data that is embedded in a PDF file. The first two profiles allow
inclusion of XAdES signatures in PDF and the augmentation of these signatures to achieve long-term validation. The
second two profiles allow signatures on XFA-forms and the augmentation of these signatures to achieve long-term
validation.
6.2 Profiles for XAdES signatures of signed XML documents
embedded in PDF containers
6.2.1 Overview
This clause defines a profile for usage of an arbitrary XML document signed with XAdES signatures that is embedded
within a PDF file, for providing integrity, authentication and non-repudiation services on the data objects that are signed
with the XAdES signature. This XML document can be aligned with any XML language, i.e. a signed UBL e-Invoice.
ETSI
16 Draft ETSI EN 319 142-2 V1.0.0 (2015-06)
NOTE 1: The term "data object" applies to any resource that is referenced by the XMLDSig mechanisms. It does
apply to the XML document when it is signed as a whole, and also to a collection of elements of the XML
document if only these elements are signed.
This clause defines two profiles, namely: a basic profile for XAdES-E-BES, XAdES-E-EPES, and XAdES-E-T
signature levels, and a long-term profile for signature levels from XAdES-E-C to XAdES-E-A.
The scenario for usage of the first profile, specified in clause 6.2.2, is described below and shown in figure 1:
1) An XML document is created and signed with XAdES (levels XAdES-E-BES, XAdE
...
Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
EUROPEAN STANDARD
Electronic Signatures and Infrastructures (ESI);
PAdES digital signatures;
Part 2: Additional PAdES signatures profiles
2 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
Reference
DEN/ESI-0019142-2
Keywords
electronic signature, PAdES, 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 enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present 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. 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 the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
https://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 be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2016.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP 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
3 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions and abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 10
4 Profile for CMS digital signatures in PDF . 10
4.1 Features . 10
4.2 Requirements of Profile for CMS Signatures in PDF . 11
4.2.1 Requirements on PDF signatures . 11
4.2.2 Requirements on PDF signature handlers . 11
4.2.3 Requirements on signature validation . 11
4.2.4 Requirements on Time Stamping . 12
4.2.4.1 Requirements on electronic time-stamp creation . 12
4.2.4.2 Requirements on electronic time-stamp validation . 12
4.2.5 Requirements on revocation checking . 12
4.2.6 Requirements on Seed Values . 12
4.2.7 Requirements on encryption . 12
5 Extended PAdES signature profiles . 12
5.1 Features . 12
5.2 General Requirements . 13
5.2.1 Requirements from Part 1 . 13
5.2.2 Notation of Requirements . 13
5.3 PAdES-E-BES Level . 13
5.4 PAdES-E-EPES Level . 15
5.5 PAdES-E-LTV Level . 15
6 Profiles for XAdES Signatures signing XML content in PDF . 15
6.1 Features . 15
6.2 Profiles for XAdES signatures of signed XML documents embedded in PDF containers . 16
6.2.1 Overview . 16
6.2.2 Profile for Basic XAdES signatures of XML documents embedded in PDF containers . 18
6.2.2.1 Features . 18
6.2.2.2 General syntax and requirements . 18
6.2.2.3 Requirements for applications generating signed XML document to be embedded . 18
6.2.2.4 Mandatory operations. 19
6.2.2.4.1 Protecting the signing certificate . 19
6.2.2.5 Requirements on XAdES optional properties . 19
6.2.2.6 Serial Signatures . 20
6.2.2.7 Parallel Signatures . 20
6.2.2.8 PAdES Signatures . 20
6.2.3 Profile for long-term XAdES signatures of signed XML documents embedded in PDF containers . 20
6.2.3.1 Features . 20
6.2.3.2 Augmentation mechanism . 20
6.2.3.3 Optional properties . 20
6.2.3.4 Validation Process . 20
6.3 Profiles for XAdES signatures on XFA Forms . 21
6.3.1 Overview . 21
6.3.2 Profile for Basic XAdES signatures on XFA forms . 23
ETSI
4 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
6.3.2.1 Features . 23
6.3.2.2 General syntax and requirements . 23
6.3.2.3 Mandatory operations. 24
6.3.2.3.1 Protecting the signing certificate . 24
6.3.2.4 Requirements on XAdES optional properties . 24
6.3.2.5 Serial Signatures . 25
6.3.2.6 Parallel Signatures . 26
6.3.3 Profile for long-term validation XAdES signatures on XFA forms . 26
6.3.3.1 Overview . 26
6.3.3.2 Features . 26
6.3.3.3 General Requirements . 26
6.3.4 Extensions Dictionary . 26
Annex A (informative): General Features . 27
A.1 PDF signatures . 27
A.2 PDF Signature types . 28
A.3 PDF Signature Handlers . 28
A.4 PDF serial signatures . 28
A.5 PDF signature Validation and Time-stamping . 29
A.6 ISO 19005-1: 2005 (PDF/A-1) . 29
A.7 ISO 19005-2:2011 (PDF/A-2) . 30
A.8 Seed Values and Signature Policies . 30
History . 31
ETSI
5 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining 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 Secretariat. 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 the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This final draft European Standard (EN) has been produced by ETSI Technical Committee Electronic Signatures and
Infrastructures (ESI), and is now submitted for the Vote phase of the ETSI standards EN Approval Procedure.
The present document is part 2 of a multi-part deliverable covering the PDF digital signatures (PAdES), as identified
below.
Part 1: "Building blocks and PAdES baseline signatures";
Part 2: "Additional PAdES signatures profiles".
Proposed national transposition dates
Date of latest announcement of this EN (doa): 3 months after ETSI publication
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 6 months after doa
Date of withdrawal of any conflicting National Standard (dow): 6 months after doa
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 Drafting 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
Electronic commerce has emerged as a frequent way of doing business between companies across local, wide area and
global networks. Trust in this way of doing business is essential for the success and continued development of
electronic commerce. It is therefore important that companies using this electronic means of doing business have
suitable security controls and mechanisms in place to protect their transactions and to ensure trust and confidence with
their business partners. In this respect digital signatures are an important security component that can be used to protect
information and provide trust in electronic business.
The present document is intended to cover digital signatures supported by PKI and public key certificates. This includes
evidence as to its validity even if the signer or verifying party later attempts to deny (i.e. repudiates; see
ISO/IEC 10181-4 [i.1]) the validity of the signature.
ETSI
6 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
Thus, the present document can be used for any document encoded in a portable document format (PDF) produced by
an individual and a company, and exchanged between companies, between an individual and a governmental body, etc.
The present document is independent of any environment; it can be applied to any environment, e.g. smart cards, SIM
cards, special programs for digital signatures, etc.
The present document is part of a rationalized framework of standards (see ETSI TR 119 000 [i.8]). See ETSI
TR 119 100 [i.9] for getting guidance on how to use the present document within the aforementioned framework.
ETSI
7 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
1 Scope
The present document defines multiple profiles for PAdES digital signatures which are digital signatures embedded
within a PDF file.
The present document contains a profile for the use of PDF signatures, as described in ISO 32000-1 [1] and based on
CMS digital signatures [i.6], that enables greater interoperability for PDF signatures by providing additional restrictions
beyond those of ISO 32000-1 [1]. This first profile is not related to ETSI EN 319 142-1 [4].
The present document also contains a second set of profiles that extend the scope of the profile in PAdES part 1 [5],
while keeping some features that enhance interoperability of PAdES signatures. These profiles define three levels of
PAdES extended signatures addressing incremental requirements to maintain the validity of the signatures over the long
term, in a way that a certain level always addresses all the requirements addressed at levels that are below it. These
PAdES extended signatures offer a higher degree of optionality than the PAdES baseline signatures specified in ETSI
EN 319 142-1 [4].
The present document also defines a third profile for usage of an arbitrary XML document signed with XAdES
signatures that is embedded within a PDF file.
The profiles defined in the present document provide equivalent requirements to profiles found in ETSI
TS 102 778 [i.10].
Procedures for creation, augmentation, and validation of PAdES digital signatures are out of scope and specified in
ETSI EN 319 102-1 [i.11]. Guidance on creation, augmentation and validation of PAdES digital signatures including
the usage of the different attributes is provided in ETSI TR 119 100 [i.9].
The present document does not repeat the base requirements of the referenced standards, but instead aims to maximize
interoperability of digital signatures in various business areas.
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 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
http://docbox.etsi.org/Reference.
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 necessary for the application of the present document.
[1] ISO 32000-1: "Document management - Portable document format - Part 1: PDF 1.7".
NOTE: Available at http://www.adobe.com/devnet/acrobat/pdfs/PDF32000_2008.pdf.
[2] IETF RFC 2315: "PKCS #7: Cryptographic Message Syntax Version 1.5".
[3] IETF RFC 5280: "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile".
[4] ETSI EN 319 142-1: "Electronic Signatures and Infrastructures (ESI); PAdES digital signatures;
Part 1: Building blocks and PAdES baseline signatures".
[5] ETSI EN 319 122-1: "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures;
Part 1: Building blocks and CAdES baseline signatures".
[6] ETSI EN 319 132-1: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures;
Part 1: Building blocks and XAdES baseline signatures".
ETSI
8 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
[7] ETSI EN 319 132-2: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures;
Part 2: Extended XAdES signatures".
[8] Adobe ® XFA: "XML Forms Architecture (XFA) Specification" version 2.5, (June 2007), Adobe
Systems Incorporated".
[9] W3C Recommendation: "XML-Signature Syntax and Processing. Version 1.1".
[10] IETF RFC 5035 (2007): "Enhanced Security Services (ESS) Update: Adding CertID Algorithm
Agility".
[11] IETF RFC 3161 (2001): "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)".
[12] IETF RFC 5816 (2010): "ESSCertIDv2 Update for RFC 3161".
2.2 Informative 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
reference document (including any amendments) 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 subject area.
[i.1] ISO/IEC 10181-4: "Information technology - Open Systems Interconnection - Security
frameworks for open systems: Non-repudiation framework".
[i.2] ETSI TS 119 312: "Electronic Signatures and Infrastructures (ESI); Cryptographic Suites".
[i.3] IETF RFC 5755: "An Internet Attribute Certificate Profile for Authorization".
[i.4] W3C® Working Group Note, XML Signature Best Practices, 11 April 2013.
[i.5] ISO 19005-1:2005: "Document management - Electronic document file format for long-term
preservation - Part 1: Use of PDF 1.4 (PDF/A-1)".
[i.6] IETF RFC 5652 (2009): "Cryptographic Message Syntax (CMS)".
[i.7] ISO 19005-2 (2011): "Document management - Electronic document file format for long-term
preservation - Part 2: Use of ISO 32000-1 (PDF/A-2)".
[i.8] ETSI TR 119 000: "Electronic Signatures and Infrastructures (ESI); The framework for
standardization of signatures: overview".
[i.9] ETSI TR 119 100: "Electronic Signatures and Infrastructures (ESI); Business Driven Guidance for
Signature Creation and Validation".
[i.10] ETSI TS 102 778: "Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic
Signature Profiles; CMS Profile based on ISO 32000-1".
[i.11] ETSI EN 319 102-1: "Electronic Signatures and Infrastructures (ESI); Procedures for Creation and
Validation of AdES Digital Signatures; Part 1: Creation and Validation".
[i.12] ETSI TR 119 001: "Electronic Signatures and Infrastructures (ESI); The framework for
standardization of signatures; Definitions and abbreviations".
ETSI
9 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ISO 32000-1 [1] and the following apply:
certificate: public key of a user, together with some other information, rendered un-forgeable by encipherment with the
private key of the certification authority which issued it
certificate policy (CP): named set of rules that indicates the applicability of a certificate to a particular community
and/or class of application with common security requirements
Certificate Revocation List (CRL): signed list indicating a set of public key certificates that are no longer considered
valid by the certificate issuer
Certification Authority (CA): authority trusted by one or more users to create and assign public key certificates;
optionally, the certification authority may create the users' keys
certification signature: digital signature that is used in conjunction with Modification Detection Permissions (MDP) as
defined by ISO 32000-1 [1], clause 12.8.2.2
digital signature: data appended to, or a cryptographic transformation of a data unit that allows a recipient of the data
unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient
digital signature value: result of the cryptographic transformation of a data unit that allows a recipient of the data unit
to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient
electronic time-stamp: data object that binds a representation of a datum to a particular time, thus establishing
evidence that the datum existed at that time
NOTE: In the case of IETF RFC 3161 [11] updated by IETF RFC 5816 [12] protocol, the electronic time-stamp
is referring to the timeStampToken field within the TimeStampResp element (the TSA's response
returned to the requesting client).
PAdES signature: digital signature that satisfies the requirements specified within the present document
PDF serial signature: specific digital signature where the second (and subsequent) signers of a PDF not only sign the
document but also the signature of the previous signer and any modification that can also have taken place (e.g. form
fill-in)
PDF signature: DER-encoded binary data object based on the PKCS #7 [2] or the CMS (IETF RFC 5652 [i.6]) or
related syntax containing a digital signature and other information necessary to validate the electronic signature such as
the signer's certificate along with any supplied revocation information placed within a PDF document structure as
specified in ISO 32000-1 [1], clause 12.8
relying party: natural or legal person that relies upon electronic identification or trust service
seed value dictionary: PDF data structure, of type dictionary, as described in ISO 32000-1 [1], clause 12.7.4.5,
table 234, that contains information that constrains the properties of a digital signature that is applied to a specific
Signature field
signature augmentation policy: set of rules, applicable to one or more digital signatures, that defines the technical and
procedural requirements for their augmentation, in order to meet a particular business need, and under which the digital
signature(s) can be determined to be conformant
signature creation policy: set of rules, applicable to one or more digital signatures, that defines the technical and
procedural requirements for their creation, in order to meet a particular business need, and under which the digital
signature(s) can be determined to be conformant
signature dictionary: PDF data structure, of type dictionary, as described in ISO 32000-1 [1], clause 12.8.1, table 252
that contains all information about the digital signature
ETSI
10 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
signature handler: software application, or part of a software application, that knows how to perform digital signature
operations (e.g. signing and/or validating) in conformance with ISO 32000-1 [1] and the requirements of the appropriate
profile
signature policy: signature creation policy, signature augmentation policy, signature validation policy or any
combination thereof, applicable to the same signature or set of signatures
signature validation policy: set of rules, applicable to one or more digital signatures, that defines the technical and
procedural requirements for their validation, in order to meet a particular business need, and under which the digital
signature(s) can be determined to be valid
signer: natural or legal person who creates a digital signature
Time-Stamping Authority (TSA): trusted third party that creates electronic time-stamps in order to indicate that a
datum existed at a particular point in time
validation data: data that is used to validate a digital signature
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TR 119 001 [i.12] and the following apply:
CA Certification Authority
CAdES CMS Signatures
NOTE: As per ETSI EN 319 122-1 [5].
CMS Cryptographic Message Syntax
NOTE: As specified in IETF RFC 5652 [i.6].
CRL Certificate Revocation List
DER Distinguished Encoding Rules
ESS Enhanced Security Services
MDP Modification Detection and Prevention
OCSP Online Certificate Status Protocol
PDF Portable Document Format
SIM Subscriber Identity Module
TSA Time-Stamping Authority
UTC Universal Business Language
XML XML Forms Architecture
XMP Extensible Metadata Platform
4 Profile for CMS digital signatures in PDF
4.1 Features
The present profile specifies digital signatures that:
• Are encoded in CMS as defined by PKCS #7 1.5 (see IETF RFC 2315 [2]).
• Support serial signatures.
• Optionally include signature time-stamps.
• Optionally include revocation information.
• Protect integrity of the document and authenticates the signer identity information included in the signing
certificate.
• Can optionally include the "reasons" for the signature.
• Can optionally include a description of the location of signing.
ETSI
11 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
• Can optionally include contact info of the signer.
A "legal content attestation" can be used to indicate to the relying party the PDF capabilities which may affect the
signed document (e.g. JavaScript).
4.2 Requirements of Profile for CMS Signatures in PDF
4.2.1 Requirements on PDF signatures
While ISO 32000-1 [1], clause 12.8 clearly states the majority of the requirements necessary for conformance with this
profile, this clause specifies additional requirements for conformance.
a) PDF Signatures shall be as specified in ISO 32000-1 [1], clause 12.8.
b) The signature information shall be embedded into the document itself and the ByteRange shall be the entire
file, including the signature dictionary but excluding the PDF Signature itself.
c) The PDF Signature (a DER-encoded PKCS#7 binary data object) shall be placed into the Contents entry of
the signature dictionary.
d) The PKCS#7 object shall conform to the PKCS#7 specification in IETF RFC 2315 [2]. At minimum, it shall
include the signer's X.509 signing certificate.
NOTE 1: Although ISO 32000-1 [1] also allows the value of the Contents entry of signature dictionary to be a
DER-encoded PKCS#1 binary data object, that format is not supported by this profile.
e) Timestamping and revocation information should be included in the PDF Signature. This revocation
information and as much of the complete chain of certificates as is available should be captured and validated
before completing the creation of the PDF Signature.
f) If present, any revocation information shall be a signed attribute of the PDF Signature.
g) IETF RFC 5755 [i.3] attribute certificates associated with the signer certificate should not be used.
NOTE 2: ISO 32000-1 [1] allows the inclusion of one or more IETF RFC 5755 [i.3] attribute certificates associated
with the signer certificate. However, attribute certificates are not widely supported and hence use of this
attribute will reduce interoperability.
h) There shall only be a single signer (i.e. one single component of "SignerInfo" type within "signerInfos"
element) in any PDF Signature.
4.2.2 Requirements on PDF signature handlers
a) A PDF reader may substitute a different signature handler, other than that specified in Filter, when validating
the signature, as long as it supports the specified SubFilter format.
b) Only the two values for SubFilter listed in ISO 32000-1 [1], clause 12.8.3.3.1 (i.e. adbe.pkcs7.detached and
adbe.pkcs7.sha1) shall be used.
NOTE: While the names of the SubFilters can imply specific algorithms, the actual list of supported algorithms
can be found in ISO 32000-1 [1], clause 12.8.3.3.2, table 257. Consult ETSI TS 119 312 [i.2] for
guidance on algorithm choices.
The use of SHA-1 is being phased out and hence other hashing algorithms should be used.
4.2.3 Requirements on signature validation
When the user opens a signed document and requests validation of the signature(s) present in the PDF, a reader shall
invoke the appropriate signature handler that shall perform the following steps to validate them.
a) Validate that the document digest matches that in the signature as specified in ISO 32000-1 [1], clause 12.8.1.
ETSI
12 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
b) Validate the path of certificates used to validate the binding between the subject distinguished name and
subject public key as specified in IETF RFC 5280 [3]. The validity checks shall be carried out at the time
indicated either by electronic time-stamp applied as per clause 4.2.4 or some other trusted indication of the
signing time. The revocation status shall be checked as specified in clause 4.2.5.
c) To achieve consistent validation results with existing signatures and existing implementations of signature
handlers, that did not know this attribute, the signing certificate reference attribute itself should be ignored
during validation if present.
NOTE: Unlike any other Profile in the present document inclusion of the certificate hash (see CAdES [5],
clause 5.2.2) is not required by this profile. Applications requiring the existence of certificate hash can
use signatures based on PAdES baseline profiles [4] or the profile defined in clause 5.3 or the profile
defined in clause 5.4.
4.2.4 Requirements on Time Stamping
4.2.4.1 Requirements on electronic time-stamp creation
a) An electronic time-stamp from a trusted TSA should be applied to the digital signature as soon as possible
after the signature is created so the electronic time-stamp reflects the time after the document was signed.
b) If a signature handler chooses to embed an electronic time-stamp into the PDF Signature, then it shall be
embedded as described in ISO 32000-1 [1], clause 12.8.3.3.1.
4.2.4.2 Requirements on electronic time-stamp validation
a) A signature handler shall take the signature field of the PKCS#7 signature, encode it and compute the digest of
the resulting byte stream using the algorithm indicated in the electronic time-stamp.
b) A signature handler shall check if the value obtained in the first step is the same as the digest present in the
electronic time-stamp.
4.2.5 Requirements on revocation checking
When validating the PDF Signature, a signature handler may ignore any embedded revocation information in favour of
alternative storage or referenced data as per its own policies.
4.2.6 Requirements on Seed Values
Seed values that would require a signature handler to violate this profile shall not be used.
EXAMPLE: Seed values that specify the use of PKCS#1 are not permitted as the present document requires use
of PKCS#7.
4.2.7 Requirements on encryption
The Requirements in PAdES Part 1 [4], clause 5.5 shall apply.
5 Extended PAdES signature profiles
5.1 Features
The profiles in this clause define PAdES signatures based on the building blocks defined in PAdES Part 1 [4]. These
profiles define three levels of PAdES extended signatures that offer a higher degree of optionality than the PAdES
baseline signatures specified in part 1 [4].
PAdES-E-BES Level allows basic digital signatures embedded within a PDF file. There is a unambiguous connection
from the signature to the identity of a certificate intended to identify the signer.
PAdES-E-EPES Level is built on top of the PAdES-E-BES Level and allows inclusion of signature policies.
ETSI
13 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
PAdES-E-LTV can build on either PAdES-E-BES Level or PAdES-E-EPES Level addressing incremental requirements
to maintain the validity of the signatures over the long term.
5.2 General Requirements
5.2.1 Requirements from Part 1
The requirements given in clauses 4.1 and 6.2.1 of [4] (PAdES Part 1) shall apply to all profiles in this clause.
5.2.2 Notation of Requirements
The present clause describes the notation used for defining the requirements of the different extended PAdES signature
profiles.
The requirements on the attributes and certain signature fields are expressed in tables. A row in the table either specifies
requirements for an attribute or a service.
These tables contain five columns.
1) Column "Attribute/Field/Service":
- this cell contains the name of the attribute or signature field.
2) Colum "Presence": This cell contains the specification of the presence of the attribute or signature as follows:
- "shall be present": means that the attributes or signature fields shall be present, and shall be as specified
in the document referenced in column "References", further profiled with the additional requirements
referenced in column "Requirements", and with the cardinality indicated in column "Cardinality".
- "shall not be present": means that the attributes or signature fields shall not be present.
- "may be present": means that the attributes or signature fields may be present, and shall be as specified in
the document referenced in column "References", further profiled with the additional requirements
referenced in column "Requirements", and with the cardinality indicated in column "Cardinality".
- "conditioned presence": means that the presence of the item identified in the first column is conditioned
as per the requirement(s) specified in column "Requirements" and requirements referenced by column
"References" with the cardinality indicated in column "Cardinality".
3) Column "Cardinality": This cell indicates the cardinality of the attribute or signature field as follows:
- 0: The signature shall not incorporate any instance of the attribute or signature field.
- 1: The signature shall incorporate exactly one instance of the attribute or signature field.
- 0 or 1: The signature shall incorporate zero or one instance of the attribute or signature field.
- ≥ 0: The signature shall incorporate zero or more instances of the attribute or signature field.
- ≥ 1: The signature shall incorporate one or more instances of the attribute or signature field.
4) Column "Additional notes and requirements": This cell contains numbers referencing notes and/or letters
referencing additional requirements on the attribute or signature field. Both notes and additional requirements
are listed below the table.
5) Column "Reference": This cell contains either the number of the clause specifying the attribute in the present
document, or a reference to the document and clause that specifies the signature field.
5.3 PAdES-E-BES Level
The requirements and the attributes within signature dictionary and SignerInfo are as defined in table 1.
For any optional unsigned attribute incorporated in the signature, DER encoding shall be used for this attribute, whilst
preserving the encoding of any other attribute field.
ETSI
14 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
Table 1: Requirements for the main attributes in PAdES-E-BES signatures
Attribute/Field/Service Presence Cardinality Additional notes Reference
and requirements
content-type
1 a ETSI EN 319 122-1 [5],
shall be present
clause 5.1.1
message-digest
1 ETSI EN 319 122-1 [5],
shall be present
clause 5.1.2
signing-certificate reference
shall be present 1 b, c, d
signer-attributes-v2 may be present 0 or 1 ETSI EN 319 122-1 [5],
clause 5.2.6.1
content-time-stamp may be present ≥ 0 ETSI EN 319 122-1 [5],
clause 5.2.8
signature-time-stamp
may be present ≥ 0 ETSI EN 319 122-1 [5],
clause 5.3
commitment-type-indication conditioned 0 or 1 e ETSI EN 319 122-1 [5],
presence clause 5.2.3
entry with key M in the
may be present 0 or 1 f ISO 32000-1 [1],
Signature Dictionary
clause 12.8.1
entry with key Location in
may be present 0 or 1 ISO 32000-1 [1],
the Signature Dictionary
clause 12.8.1
entry with key Reason in the conditioned 0 or 1 g ISO 32000-1 [1],
Signature Dictionary
presence clause 12.8.1
h
entry with key Filter in the
1 ISO 32000-1 [1],
shall be present
Signature Dictionary
clause 12.8.1
entry with key ByteRange in i
1 ISO 32000-1 [1],
shall be present
the Signature Dictionary
clause 12.8.1
entry with key SubFilter in j
1 ISO 32000-1 [1],
shall be present
the Signature Dictionary
clause 12.8.1
entry with key Contents in k
1 ISO 32000-1 [1],
shall be present
the Signature Dictionary
clause 12.8.1
entry with key Name in the 0 or 1 ISO 32000-1 [1],
may be present
Signature Dictionary
clause 12.8.1
entry with key ContactInfo in
0 or 1 ISO 32000-1 [1],
may be present
the Signature Dictionary
clause 12.8.1
entry with key Cert in the
shall not be 0 ISO 32000-1 [1],
Signature Dictionary
present clause 12.8.1
Additional requirements:
a) The content-type attribute shall have value id-data.
b) As specified in IETF RFC 5035 [10], the ESS signing-certificate attribute shall be used if the SHA-1
hash algorithm is used.
c) As specified in IETF RFC 5035 [10], the ESS signing-certificate-v2 attribute shall be used when
another hash algorithms than SHA-1 is used.
d) The generator should migrate to the use of ESS signing-certificate-v2 in preference to ESS
signing-certificate in line with the guidance regarding limited lifetime for the use of SHA-1 given in
ETSI TS 119 312 [i.2].
e) The commitment-type-indication attribute may be incorporated in the CMS signature only if the
entry with the key Reason is not used. Otherwise the commitment-type-indication shall not be
incorporated in the CMS signature.
f) The generator should include the claimed UTC time of the signature in a format defined in ISO 32000-1 [1],
clause 7.9.4 as content of this element.
g) The entry with the key Reason shall not be used if the commitment-type-indication attribute is
present in the CMS signature.
h) A verifier may substitute a different signature handler, other than that specified in Filter, when validating the
signature, as long as it supports the specified SubFilter format.
ETSI
15 Final draft ETSI EN 319 142-2 V1.1.0 (2016-02)
i) The ByteRange shall cover the entire file, including the signature dictionary but excluding the PDF Signature
itself.
j) The signature dictionary shall contain a value of ETSI.CAdES.detached for the key SubFilter.
k) Requirements specified in ISO 32000-1 [1], clauses 12.8.3.2 (PKCS#1) and 12.8.3.3 (PKCS#7) shall not be
used.
5.4 PAdES-E-EPES Level
The requirements and the attributes within SignerInfo are as defined in table 1 to which those ones defined in
table 2 shall be added/replaced.
For any optional unsigned attribute incorporated in the signature, DER encoding shall be used for this attribute, whilst
preserving the encoding of any other attribute field.
Table 2: Requirements for the main CAdES attributes in PAdES-E-EPES level
Attribute/Field/Service Presence Cardinality Additional notes and Reference
requirements
signature-policy-identifier
shall be 1 ETSI EN 319 122-1 [5],
present clause 5.2.9
entry with key Reason in the
shall not be 0 ISO 32000-1 [1],
Signa
...
EUROPEAN STANDARD
Electronic Signatures and Infrastructures (ESI);
PAdES digital signatures;
Part 2: Additional PAdES signatures profiles
2 ETSI EN 319 142-2 V1.1.1 (2016-04)
Reference
DEN/ESI-0019142-2
Keywords
electronic signature, PAdES, 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 enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present 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. 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 the 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:
https://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 be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2016.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP 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
3 ETSI EN 319 142-2 V1.1.1 (2016-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions and abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 9
4 Profile for CMS digital signatures in PDF . 9
4.1 Features . 9
4.2 Requirements of Profile for CMS Signatures in PDF . 10
4.2.1 Requirements on PDF signatures . 10
4.2.2 Requirements on PDF signature handlers . 10
4.2.3 Requirements on signature validation . 10
4.2.4 Requirements on Time Stamping . 11
4.2.4.1 Requirements on electronic time-stamp creation . 11
4.2.4.2 Requirements on electronic time-stamp validation . 11
4.2.5 Requirements on revocation checking . 11
4.2.6 Requirements on Seed Values . 11
4.2.7 Requirements on encryption . 11
5 Extended PAdES signature profiles . 11
5.1 Features . 11
5.2 General Requirements . 11
5.2.1 Requirements from Part 1 . 11
5.2.2 Notation of Requirements . 12
5.3 PAdES-E-BES Level . 12
5.4 PAdES-E-EPES Level . 14
5.5 PAdES-E-LTV Level . 14
6 Profiles for XAdES Signatures signing XML content in PDF . 14
6.1 Features . 14
6.2 Profiles for XAdES signatures of signed XML documents embedded in PDF containers . 15
6.2.1 Overview . 15
6.2.2 Profile for Basic XAdES signatures of XML documents embedded in PDF containers . 17
6.2.2.1 Features . 17
6.2.2.2 General syntax and requirements . 17
6.2.2.3 Requirements for applications generating signed XML document to be embedded . 17
6.2.2.4 Mandatory operations. 18
6.2.2.4.1 Protecting the signing certificate . 18
6.2.2.5 Requirements on XAdES optional properties . 18
6.2.2.6 Serial Signatures . 19
6.2.2.7 Parallel Signatures . 19
6.2.2.8 PAdES Signatures . 19
6.2.3 Profile for long-term XAdES signatures of signed XML documents embedded in PDF containers . 19
6.2.3.1 Features . 19
6.2.3.2 Augmentation mechanism . 19
6.2.3.3 Optional properties . 19
6.2.3.4 Validation Process . 19
6.3 Profiles for XAdES signatures on XFA Forms . 20
6.3.1 Overview . 20
6.3.2 Profile for Basic XAdES signatures on XFA forms . 22
ETSI
4 ETSI EN 319 142-2 V1.1.1 (2016-04)
6.3.2.1 Features . 22
6.3.2.2 General syntax and requirements . 22
6.3.2.3 Mandatory operations. 23
6.3.2.3.1 Protecting the signing certificate . 23
6.3.2.4 Requirements on XAdES optional properties . 23
6.3.2.5 Serial Signatures . 24
6.3.2.6 Parallel Signatures . 25
6.3.3 Profile for long-term validation XAdES signatures on XFA forms . 25
6.3.3.1 Overview . 25
6.3.3.2 Features . 25
6.3.3.3 General Requirements . 25
6.3.4 Extensions Dictionary . 25
Annex A (informative): General Features . 26
A.1 PDF signatures . 26
A.2 PDF Signature types . 27
A.3 PDF Signature Handlers . 27
A.4 PDF serial signatures . 27
A.5 PDF signature Validation and Time-stamping . 28
A.6 ISO 19005-1: 2005 (PDF/A-1) . 28
A.7 ISO 19005-2:2011 (PDF/A-2) . 29
A.8 Seed Values and Signature Policies . 29
History . 30
ETSI
5 ETSI EN 319 142-2 V1.1.1 (2016-04)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining 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 Secretariat. 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 the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Electronic Signatures and
Infrastructures (ESI).
The present document is part 2 of a multi-part deliverable covering the PDF digital signatures (PAdES). Full details of
the entire series can be found in part 1 [4].
National transposition dates
Date of adoption of this EN: 1 April 2016
Date of latest announcement of this EN (doa): 31 July 2016
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 January 2017
Date of withdrawal of any conflicting National Standard (dow): 31 January 2017
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 Drafting 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
Electronic commerce has emerged as a frequent way of doing business between companies across local, wide area and
global networks. Trust in this way of doing business is essential for the success and continued development of
electronic commerce. It is therefore important that companies using this electronic means of doing business have
suitable security controls and mechanisms in place to protect their transactions and to ensure trust and confidence with
their business partners. In this respect digital signatures are an important security component that can be used to protect
information and provide trust in electronic business.
The present document is intended to cover digital signatures supported by PKI and public key certificates. This includes
evidence as to its validity even if the signer or verifying party later attempts to deny (i.e. repudiates; see
ISO/IEC 10181-4 [i.1]) the validity of the signature.
ETSI
6 ETSI EN 319 142-2 V1.1.1 (2016-04)
Thus, the present document can be used for any document encoded in a portable document format (PDF) produced by
an individual and a company, and exchanged between companies, between an individual and a governmental body, etc.
The present document is independent of any environment; it can be applied to any environment, e.g. smart cards, SIM
cards, special programs for digital signatures, etc.
The present document is part of a rationalized framework of standards (see ETSI TR 119 000 [i.8]). See ETSI
TR 119 100 [i.9] for getting guidance on how to use the present document within the aforementioned framework.
ETSI
7 ETSI EN 319 142-2 V1.1.1 (2016-04)
1 Scope
The present document defines multiple profiles for PAdES digital signatures which are digital signatures embedded
within a PDF file.
The present document contains a profile for the use of PDF signatures, as described in ISO 32000-1 [1] and based on
CMS digital signatures [i.6], that enables greater interoperability for PDF signatures by providing additional restrictions
beyond those of ISO 32000-1 [1]. This first profile is not related to ETSI EN 319 142-1 [4].
The present document also contains a second set of profiles that extend the scope of the profile in PAdES part 1 [5],
while keeping some features that enhance interoperability of PAdES signatures. These profiles define three levels of
PAdES extended signatures addressing incremental requirements to maintain the validity of the signatures over the long
term, in a way that a certain level always addresses all the requirements addressed at levels that are below it. These
PAdES extended signatures offer a higher degree of optionality than the PAdES baseline signatures specified in ETSI
EN 319 142-1 [4].
The present document also defines a third profile for usage of an arbitrary XML document signed with XAdES
signatures that is embedded within a PDF file.
The profiles defined in the present document provide equivalent requirements to profiles found in ETSI
TS 102 778 [i.10].
Procedures for creation, augmentation, and validation of PAdES digital signatures are out of scope and specified in
ETSI EN 319 102-1 [i.11]. Guidance on creation, augmentation and validation of PAdES digital signatures including
the usage of the different attributes is provided in ETSI TR 119 100 [i.9].
The present document does not repeat the base requirements of the referenced standards, but instead aims to maximize
interoperability of digital signatures in various business areas.
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 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
http://docbox.etsi.org/Reference.
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 necessary for the application of the present document.
[1] ISO 32000-1: "Document management - Portable document format - Part 1: PDF 1.7".
NOTE: Available at http://www.adobe.com/devnet/acrobat/pdfs/PDF32000_2008.pdf.
[2] IETF RFC 2315: "PKCS #7: Cryptographic Message Syntax Version 1.5".
[3] IETF RFC 5280: "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile".
[4] ETSI EN 319 142-1: "Electronic Signatures and Infrastructures (ESI); PAdES digital signatures;
Part 1: Building blocks and PAdES baseline signatures".
[5] ETSI EN 319 122-1: "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures;
Part 1: Building blocks and CAdES baseline signatures".
[6] ETSI EN 319 132-1: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures;
Part 1: Building blocks and XAdES baseline signatures".
ETSI
8 ETSI EN 319 142-2 V1.1.1 (2016-04)
[7] ETSI EN 319 132-2: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures;
Part 2: Extended XAdES signatures".
[8] Adobe ® XFA: "XML Forms Architecture (XFA) Specification" version 2.5, (June 2007), Adobe
Systems Incorporated".
[9] W3C Recommendation: "XML-Signature Syntax and Processing. Version 1.1".
[10] IETF RFC 5035 (2007): "Enhanced Security Services (ESS) Update: Adding CertID Algorithm
Agility".
[11] IETF RFC 3161 (2001): "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)".
[12] IETF RFC 5816 (2010): "ESSCertIDv2 Update for RFC 3161".
2.2 Informative 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) 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 subject area.
[i.1] ISO/IEC 10181-4: "Information technology - Open Systems Interconnection - Security
frameworks for open systems: Non-repudiation framework".
[i.2] ETSI TS 119 312: "Electronic Signatures and Infrastructures (ESI); Cryptographic Suites".
[i.3] IETF RFC 5755: "An Internet Attribute Certificate Profile for Authorization".
[i.4] W3C® Working Group Note, XML Signature Best Practices, 11 April 2013.
[i.5] ISO 19005-1:2005: "Document management - Electronic document file format for long-term
preservation - Part 1: Use of PDF 1.4 (PDF/A-1)".
[i.6] IETF RFC 5652 (2009): "Cryptographic Message Syntax (CMS)".
[i.7] ISO 19005-2 (2011): "Document management - Electronic document file format for long-term
preservation - Part 2: Use of ISO 32000-1 (PDF/A-2)".
[i.8] ETSI TR 119 000: "Electronic Signatures and Infrastructures (ESI); The framework for
standardization of signatures: overview".
[i.9] ETSI TR 119 100: "Electronic Signatures and Infrastructures (ESI); Business Driven Guidance for
Signature Creation and Validation".
[i.10] ETSI TS 102 778: "Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic
Signature Profiles; CMS Profile based on ISO 32000-1".
[i.11] ETSI EN 319 102-1: "Electronic Signatures and Infrastructures (ESI); Procedures for Creation and
Validation of AdES Digital Signatures; Part 1: Creation and Validation".
[i.12] ETSI TR 119 001: "Electronic Signatures and Infrastructures (ESI); The framework for
standardization of signatures; Definitions and abbreviations".
ETSI
9 ETSI EN 319 142-2 V1.1.1 (2016-04)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ISO 32000-1 [1], ETSI TR 119 001 [i.12]
and ETSI EN 319 142-1 [4] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TR 119 001 [i.12] and the following apply:
CA Certification Authority
CMS Cryptographic Message Syntax
NOTE: As specified in IETF RFC 5652 [i.6].
CRL Certificate Revocation List
DER Distinguished Encoding Rules
ESS Enhanced Security Services
MDP Modification Detection and Prevention
OCSP Online Certificate Status Protocol
PDF Portable Document Format
SIM Subscriber Identity Module
TSA Time-Stamping Authority
UBL Universal Business Language
UTC Coordinated Universal Time
XML XML Forms Architecture
XMP Extensible Metadata Platform
4 Profile for CMS digital signatures in PDF
4.1 Features
The present profile specifies digital signatures that:
• Are encoded in CMS as defined by PKCS #7 1.5 (see IETF RFC 2315 [2]).
• Support serial signatures.
• Optionally include signature time-stamps.
• Optionally include revocation information.
• Protect integrity of the document and authenticates the signer identity information included in the signing
certificate.
• Can optionally include the "reasons" for the signature.
• Can optionally include a description of the location of signing.
• Can optionally include contact info of the signer.
A "legal content attestation" can be used to indicate to the relying party the PDF capabilities which may affect the
signed document (e.g. JavaScript).
ETSI
10 ETSI EN 319 142-2 V1.1.1 (2016-04)
4.2 Requirements of Profile for CMS Signatures in PDF
4.2.1 Requirements on PDF signatures
While ISO 32000-1 [1], clause 12.8 clearly states the majority of the requirements necessary for conformance with this
profile, this clause specifies additional requirements for conformance.
a) PDF Signatures shall be as specified in ISO 32000-1 [1], clause 12.8.
b) The signature information shall be embedded into the document itself and the ByteRange shall be the entire
file, including the signature dictionary but excluding the PDF Signature itself.
c) The PDF Signature (a DER-encoded PKCS#7 binary data object) shall be placed into the Contents entry of
the signature dictionary.
d) The PKCS#7 object shall conform to the PKCS#7 specification in IETF RFC 2315 [2]. At minimum, it shall
include the signer's X.509 signing certificate.
NOTE 1: Although ISO 32000-1 [1] also allows the value of the Contents entry of signature dictionary to be a
DER-encoded PKCS#1 binary data object, that format is not supported by this profile.
e) Timestamping and revocation information should be included in the PDF Signature. This revocation
information and as much of the complete chain of certificates as is available should be captured and validated
before completing the creation of the PDF Signature.
f) If present, any revocation information shall be a signed attribute of the PDF Signature.
g) IETF RFC 5755 [i.3] attribute certificates associated with the signer certificate should not be used.
NOTE 2: ISO 32000-1 [1] allows the inclusion of one or more IETF RFC 5755 [i.3] attribute certificates associated
with the signer certificate. However, attribute certificates are not widely supported and hence use of this
attribute will reduce interoperability.
h) There shall only be a single signer (i.e. one single component of "SignerInfo" type within "signerInfos"
element) in any PDF Signature.
4.2.2 Requirements on PDF signature handlers
a) A PDF reader may substitute a different signature handler, other than that specified in Filter, when validating
the signature, as long as it supports the specified SubFilter format.
b) Only the two values for SubFilter listed in ISO 32000-1 [1], clause 12.8.3.3.1 (i.e. adbe.pkcs7.detached and
adbe.pkcs7.sha1) shall be used.
NOTE: While the names of the SubFilters can imply specific algorithms, the actual list of supported algorithms
can be found in ISO 32000-1 [1], clause 12.8.3.3.2, table 257. Consult ETSI TS 119 312 [i.2] for
guidance on algorithm choices.
The use of SHA-1 is being phased out and hence other hashing algorithms should be used.
4.2.3 Requirements on signature validation
When the user opens a signed document and requests validation of the signature(s) present in the PDF, a reader shall
invoke the appropriate signature handler that shall perform the following steps to validate them.
a) Validate that the document digest matches that in the signature as specified in ISO 32000-1 [1], clause 12.8.1.
b) Validate the path of certificates used to validate the binding between the subject distinguished name and
subject public key as specified in IETF RFC 5280 [3]. The validity checks shall be carried out at the time
indicated either by electronic time-stamp applied as per clause 4.2.4 or some other trusted indication of the
signing time. The revocation status shall be checked as specified in clause 4.2.5.
c) To achieve consistent validation results with existing signatures and existing implementations of signature
handlers, that did not know this attribute, the signing certificate reference attribute itself should be ignored
during validation if present.
ETSI
11 ETSI EN 319 142-2 V1.1.1 (2016-04)
NOTE: Unlike any other Profile in the present document inclusion of the certificate hash (see CAdES [5],
clause 5.2.2) is not required by this profile. Applications requiring the existence of certificate hash can
use signatures based on PAdES baseline profiles [4] or the profile defined in clause 5.3 or the profile
defined in clause 5.4.
4.2.4 Requirements on Time Stamping
4.2.4.1 Requirements on electronic time-stamp creation
a) An electronic time-stamp from a trusted TSA should be applied to the digital signature as soon as possible
after the signature is created so the electronic time-stamp reflects the time after the document was signed.
b) If a signature handler chooses to embed an electronic time-stamp into the PDF Signature, then it shall be
embedded as described in ISO 32000-1 [1], clause 12.8.3.3.1.
4.2.4.2 Requirements on electronic time-stamp validation
a) A signature handler shall take the signature field of the PKCS#7 signature, encode it and compute the digest of
the resulting byte stream using the algorithm indicated in the electronic time-stamp.
b) A signature handler shall check if the value obtained in the first step is the same as the digest present in the
electronic time-stamp.
4.2.5 Requirements on revocation checking
When validating the PDF Signature, a signature handler may ignore any embedded revocation information in favour of
alternative storage or referenced data as per its own policies.
4.2.6 Requirements on Seed Values
Seed values that would require a signature handler to violate this profile shall not be used.
EXAMPLE: Seed values that specify the use of PKCS#1 are not permitted as the present document requires use
of PKCS#7.
4.2.7 Requirements on encryption
The Requirements in PAdES Part 1 [4], clause 5.5 shall apply.
5 Extended PAdES signature profiles
5.1 Features
The profiles in this clause define PAdES signatures based on the building blocks defined in PAdES Part 1 [4]. These
profiles define three levels of PAdES extended signatures that offer a higher degree of optionality than the PAdES
baseline signatures specified in part 1 [4].
PAdES-E-BES Level allows basic digital signatures embedded within a PDF file. There is a unambiguous connection
from the signature to the identity of a certificate intended to identify the signer.
PAdES-E-EPES Level is built on top of the PAdES-E-BES Level and allows inclusion of signature policies.
PAdES-E-LTV can build on either PAdES-E-BES Level or PAdES-E-EPES Level addressing incremental requirements
to maintain the validity of the signatures over the long term.
5.2 General Requirements
5.2.1 Requirements from Part 1
The requirements given in clauses 4.1 and 6.2.1 of [4] (PAdES Part 1) shall apply to all profiles in this clause.
ETSI
12 ETSI EN 319 142-2 V1.1.1 (2016-04)
5.2.2 Notation of Requirements
The present clause describes the notation used for defining the requirements of the different extended PAdES signature
profiles.
The requirements on the attributes and certain signature fields are expressed in tables. A row in the table either specifies
requirements for an attribute or a service.
These tables contain five columns.
1) Column "Attribute/Field/Service":
- this cell contains the name of the attribute or signature field.
2) Colum "Presence": This cell contains the specification of the presence of the attribute or signature as follows:
- "shall be present": means that the attributes or signature fields shall be present, and shall be as specified
in the document referenced in column "References", further profiled with the additional requirements
referenced in column "Requirements", and with the cardinality indicated in column "Cardinality".
- "shall not be present": means that the attributes or signature fields shall not be present.
- "may be present": means that the attributes or signature fields may be present, and shall be as specified in
the document referenced in column "References", further profiled with the additional requirements
referenced in column "Requirements", and with the cardinality indicated in column "Cardinality".
- "conditioned presence": means that the presence of the item identified in the first column is conditioned
as per the requirement(s) specified in column "Requirements" and requirements referenced by column
"References" with the cardinality indicated in column "Cardinality".
3) Column "Cardinality": This cell indicates the cardinality of the attribute or signature field as follows:
- 0: The signature shall not incorporate any instance of the attribute or signature field.
- 1: The signature shall incorporate exactly one instance of the attribute or signature field.
- 0 or 1: The signature shall incorporate zero or one instance of the attribute or signature field.
- ≥ 0: The signature shall incorporate zero or more instances of the attribute or signature field.
- ≥ 1: The signature shall incorporate one or more instances of the attribute or signature field.
4) Column "Additional notes and requirements": This cell contains numbers referencing notes and/or letters
referencing additional requirements on the attribute or signature field. Both notes and additional requirements
are listed below the table.
5) Column "Reference": This cell contains either the number of the clause specifying the attribute in the present
document, or a reference to the document and clause that specifies the signature field.
5.3 PAdES-E-BES Level
The requirements and the attributes within signature dictionary and SignerInfo are as defined in table 1.
For any optional unsigned attribute incorporated in the signature, DER encoding shall be used for this attribute, whilst
preserving the encoding of any other attribute field.
ETSI
13 ETSI EN 319 142-2 V1.1.1 (2016-04)
Table 1: Requirements for the main attributes in PAdES-E-BES signatures
Attribute/Field/Service Presence Cardinality Additional notes Reference
and requirements
content-type
1 a ETSI EN 319 122-1 [5],
shall be present
clause 5.1.1
message-digest
1 ETSI EN 319 122-1 [5],
shall be present
clause 5.1.2
signing-certificate reference
shall be present 1 b, c, d
signer-attributes-v2 may be present 0 or 1 ETSI EN 319 122-1 [5],
clause 5.2.6.1
content-time-stamp may be present ≥ 0 ETSI EN 319 122-1 [5],
clause 5.2.8
signature-time-stamp
may be present ≥ 0 ETSI EN 319 122-1 [5],
clause 5.3
commitment-type-indication conditioned 0 or 1 e ETSI EN 319 122-1 [5],
presence clause 5.2.3
entry with key M in the
may be present 0 or 1 f ISO 32000-1 [1],
Signature Dictionary
clause 12.8.1
entry with key Location in
may be present 0 or 1 ISO 32000-1 [1],
the Signature Dictionary
clause 12.8.1
entry with key Reason in the conditioned 0 or 1 g ISO 32000-1 [1],
Signature Dictionary
presence clause 12.8.1
h
entry with key Filter in the
1 ISO 32000-1 [1],
shall be present
Signature Dictionary
clause 12.8.1
entry with key ByteRange in i
1 ISO 32000-1 [1],
shall be present
the Signature Dictionary
clause 12.8.1
entry with key SubFilter in j
1 ISO 32000-1 [1],
shall be present
the Signature Dictionary
clause 12.8.1
entry with key Contents in k
1 ISO 32000-1 [1],
shall be present
the Signature Dictionary
clause 12.8.1
entry with key Name in the 0 or 1 ISO 32000-1 [1],
may be present
Signature Dictionary
clause 12.8.1
entry with key ContactInfo in
0 or 1 ISO 32000-1 [1],
may be present
the Signature Dictionary
clause 12.8.1
entry with key Cert in the
shall not be 0 ISO 32000-1 [1],
Signature Dictionary
present clause 12.8.1
Additional requirements:
a) The content-type attribute shall have value id-data.
b) As specified in IETF RFC 5035 [10], the ESS signing-certificate attribute shall be used if the SHA-1
hash algorithm is used.
c) As specified in IETF RFC 5035 [10], the ESS signing-certificate-v2 attribute shall be used when
another hash algorithms than SHA-1 is used.
d) The generator should migrate to the use of ESS signing-certificate-v2 in preference to ESS
signing-certificate in line with the guidance regarding limited lifetime for the use of SHA-1 given in
ETSI TS 119 312 [i.2].
e) The commitment-type-indication attribute may be incorporated in the CMS signature only if the
entry with the key Reason is not used. Otherwise the commitment-type-indication shall not be
incorporated in the CMS signature.
f) The generator should include the claimed UTC time of the signature in a format defined in ISO 32000-1 [1],
clause 7.9.4 as content of this element.
g) The entry with the key Reason shall not be used if the commitment-type-indication attribute is
present in the CMS signature.
h) A verifier may substitute a different signature handler, other than that specified in Filter, when validating the
signature, as long as it supports the specified SubFilter format.
ETSI
14 ETSI EN 319 142-2 V1.1.1 (2016-04)
i) The ByteRange shall cover the entire file, including the signature dictionary but excluding the PDF Signature
itself.
j) The signature dictionary shall contain a value of ETSI.CAdES.detached for the key SubFilter.
k) Requirements specified in ISO 32000-1 [1], clauses 12.8.3.2 (PKCS#1) and 12.8.3.3 (PKCS#7) shall not be
used.
5.4 PAdES-E-EPES Level
The requirements and the attributes within SignerInfo are as defined in table 1 to which those ones defined in
table 2 shall be added/replaced.
For any optional unsigned attribute incorporated in the signature, DER encoding shall be used for this attribute, whilst
preserving the encoding of any other attribute field.
Table 2: Requirements for the main CAdES attributes in PAdES-E-EPES level
Attribute/Field/Service Presence Cardinality Additional notes and Reference
requirements
signature-policy-identifier
shall be 1 ETSI EN 319 122-1 [5],
present clause 5.2.9
entry with key Reason in the
shall not be 0 ISO 32000-1 [1],
Signature Dictionary
present clause 12.8.1
5.5 PAdES-E-LTV Level
Signature handlers creating and/or validating PDF documents with PAdES-LTV shall support PDF documents with:
a) Document security store information as specified in clause 5.4.2 in ETSI EN 319 142-1 [4].
b) Document time-stamps as specified in clause 5.4.3 in ETSI EN 319 142-1 [4].
Signed PDF documents should contain DSS followed by a document time-stamp.
Validation data shall be carried by values within the DSS.
NOTE 1: Use of validation data in DSS referencing external sources is not supported by the current profile.
Systems shall support creation and/or validation of signatures with one or more DSS entries and document time-stamps.
NOTE 2: Object IDs should not be reused when adding new validation data, because of the possibility to "hide"
already existing validation data. A signature handler may check the existence of older validation data
having the same Object IDs to be explicitly aware of the fact that the latest objects could contain invalid
or unusable validation data.
6 Profiles for XAdES Signatures signing XML content
in PDF
6.1 Features
The profiles in this clause allow the signing of XML Data that is embedded in a PDF file. The first two profiles allow
inclusion of XAdES signatures in PDF and the augmentation of these signatures to achieve long-term validation. The
second two profiles allow signatures on XFA-forms and the augmentation of these signatures to achieve long-term
validation.
ETSI
15 ETSI EN 319 142-2 V1.1.1 (2016-04)
6.2 Profiles for XAdES signatures of signed XML documents
embedded in PDF containers
6.2.1 Overview
This clause defines a profile for usage of an arbitrary XML document signed with XAdES signatures that is embedded
within a PDF file, for providing integrity, authentication and non-repudiation services on the data objects that are signed
with the XAdES signature. This XML document can be aligned with any XML language, i.e. a signed UBL e-Invoice.
NOTE 1: The term "data object" applies to any resource that is referenced by the XMLDSig mechanisms. It does
apply to the XML document when it is signed as a whole, and also to a collection of elements of the XML
document if only these elements are signed.
This clause defines two profiles, namely: a basic profile for XAdES-E-BES, XAdES-E-EPES, and XAdES-E-T
signature levels, and a long-term profile for signature levels from XAdES-E-C to XAdES-E-A.
The scenario for usage of the first profile, specified in clause 6.2.2, is described below and shown in figure 1:
1) An XML document is created and signed with XAdES (levels XAdES-E-BES, XAdES-E-EPES, XAdES-E-T)
out of the PDF framework.
2) The aforementioned signed XML document is embedded within the PDF container and is transported within it.
aaa
…….
…… .
….
Figure 1: Scenario for profile for basic XAdES signatures of XML documents
embedded in PDF containers
The scenario for usage of the second profile, specified in clause 6.2.3, is described below and shown in figure 2:
1) The PDF container with the signed XML document is received by the verifier. The verifier extracts the
embedded file and validates the XAdES signature.
2) The verifier can augment the XAdES signature to upper levels as specified in ETSI EN 319 132-2 [7]. As the
XAdES signature is part of an embedded file, the Document Secure Store specified in ETSI EN 319 142-1 [4]
is not able to contain the validation material added during the augmentation. This augmentation will, in
consequence, be done outside the PDF container and within the XAdES signature itself.
ETSI
16 ETSI EN 319 142-2 V1.1.1 (2016-04)
NOTE 2: It is understood that augmenting the XAdES signature or augmenting the document by a Document
Secure Store could provide the verifier with the same information to validate the document in the long
run. It is important to augment the XAdES signature in order to enhance interoperability between
verifiers.
3) The signed XML document with the augmented XAdES signature is embedded again within the PDF
container.
NOTE 3: Augmenting the XAdES signature can be done by extracting the stream object containing the XAdES
signature from the containing document, augmenting the XAdES signature in that XML document and
including the augmented XML document in a new stream with the same pdf object number by an
incremental update.
aaa
extract
…… .
……………….
…… .
… .
embed augment
aaa
…… .
…… .
…
Figure 2: Scenario for profile for long-term XAdES signatures of signed XML documents
e
...
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Elektronski podpisi in infrastruktura (ESI) - Digitalni podpisi PAdES - 2. del: Dodatni profili podpisov PAdESElectronic Signatures and Infrastructures (ESI) - PAdES digital signatures - Part 2: Additional PAdES signatures profiles35.040.01Kodiranje informacij na splošnoInformation coding in generalICS:Ta slovenski standard je istoveten z:ETSI EN 319 142-2 V1.1.1 (2016-04)SIST EN 319 142-2 V1.1.1:2016en01-junij-2016SIST EN 319 142-2 V1.1.1:2016SLOVENSKI
STANDARD
EUROPEAN STANDARD SIST EN 319 142-2 V1.1.1:2016
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 2
Reference DEN/ESI-0019142-2 Keywords electronic signature, PAdES, 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 enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88
Important notice The present 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. 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 the 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: https://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 be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2016. All rights reserved.
DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit 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. SIST EN 319 142-2 V1.1.1:2016
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 3 Contents Intellectual Property Rights . 5 Foreword . 5 Modal verbs terminology . 5 Introduction . 5 1 Scope . 7 2 References . 7 2.1 Normative references . 7 2.2 Informative references . 8 3 Definitions and abbreviations . 9 3.1 Definitions . 9 3.2 Abbreviations . 9 4 Profile for CMS digital signatures in PDF . 9 4.1 Features . 9 4.2 Requirements of Profile for CMS Signatures in PDF . 10 4.2.1 Requirements on PDF signatures . 10 4.2.2 Requirements on PDF signature handlers . 10 4.2.3 Requirements on signature validation . 10 4.2.4 Requirements on Time Stamping . 11 4.2.4.1 Requirements on electronic time-stamp creation . 11 4.2.4.2 Requirements on electronic time-stamp validation . 11 4.2.5 Requirements on revocation checking . 11 4.2.6 Requirements on Seed Values . 11 4.2.7 Requirements on encryption . 11 5 Extended PAdES signature profiles . 11 5.1 Features . 11 5.2 General Requirements . 11 5.2.1 Requirements from Part 1 . 11 5.2.2 Notation of Requirements . 12 5.3 PAdES-E-BES Level . 12 5.4 PAdES-E-EPES Level . 14 5.5 PAdES-E-LTV Level . 14 6 Profiles for XAdES Signatures signing XML content in PDF . 14 6.1 Features . 14 6.2 Profiles for XAdES signatures of signed XML documents embedded in PDF containers . 15 6.2.1 Overview . 15 6.2.2 Profile for Basic XAdES signatures of XML documents embedded in PDF containers . 17 6.2.2.1 Features . 17 6.2.2.2 General syntax and requirements . 17 6.2.2.3 Requirements for applications generating signed XML document to be embedded . 17 6.2.2.4 Mandatory operations. 18 6.2.2.4.1 Protecting the signing certificate . 18 6.2.2.5 Requirements on XAdES optional properties . 18 6.2.2.6 Serial Signatures . 19 6.2.2.7 Parallel Signatures . 19 6.2.2.8 PAdES Signatures . 19 6.2.3 Profile for long-term XAdES signatures of signed XML documents embedded in PDF containers . 19 6.2.3.1 Features . 19 6.2.3.2 Augmentation mechanism . 19 6.2.3.3 Optional properties . 19 6.2.3.4 Validation Process . 19 6.3 Profiles for XAdES signatures on XFA Forms . 20 6.3.1 Overview . 20 6.3.2 Profile for Basic XAdES signatures on XFA forms . 22 SIST EN 319 142-2 V1.1.1:2016
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 4 6.3.2.1 Features . 22 6.3.2.2 General syntax and requirements . 22 6.3.2.3 Mandatory operations. 23 6.3.2.3.1 Protecting the signing certificate . 23 6.3.2.4 Requirements on XAdES optional properties . 23 6.3.2.5 Serial Signatures . 24 6.3.2.6 Parallel Signatures . 25 6.3.3 Profile for long-term validation XAdES signatures on XFA forms . 25 6.3.3.1 Overview . 25 6.3.3.2 Features . 25 6.3.3.3 General Requirements . 25 6.3.4 Extensions Dictionary . 25 Annex A (informative): General Features . 26 A.1 PDF signatures . 26 A.2 PDF Signature types . 27 A.3 PDF Signature Handlers . 27 A.4 PDF serial signatures . 27 A.5 PDF signature Validation and Time-stamping . 28 A.6 ISO 19005-1: 2005 (PDF/A-1) . 28 A.7 ISO 19005-2:2011 (PDF/A-2) . 29 A.8 Seed Values and Signature Policies . 29 History . 30
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 5 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining 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 Secretariat. 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 the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This European Standard (EN) has been produced by ETSI Technical Committee Electronic Signatures and Infrastructures (ESI). The present document is part 2 of a multi-part deliverable covering the PDF digital signatures (PAdES). Full details of the entire series can be found in part 1 [4].
National transposition dates Date of adoption of this EN: 1 April 2016 Date of latest announcement of this EN (doa): 31 July 2016 Date of latest publication of new National Standard or endorsement of this EN (dop/e):
31 January 2017 Date of withdrawal of any conflicting National Standard (dow): 31 January 2017
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 Drafting 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 Electronic commerce has emerged as a frequent way of doing business between companies across local, wide area and global networks. Trust in this way of doing business is essential for the success and continued development of electronic commerce. It is therefore important that companies using this electronic means of doing business have suitable security controls and mechanisms in place to protect their transactions and to ensure trust and confidence with their business partners. In this respect digital signatures are an important security component that can be used to protect information and provide trust in electronic business. The present document is intended to cover digital signatures supported by PKI and public key certificates. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e. repudiates; see ISO/IEC 10181-4 [i.1]) the validity of the signature. SIST EN 319 142-2 V1.1.1:2016
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 6 Thus, the present document can be used for any document encoded in a portable document format (PDF) produced by an individual and a company, and exchanged between companies, between an individual and a governmental body, etc. The present document is independent of any environment; it can be applied to any environment, e.g. smart cards, SIM cards, special programs for digital signatures, etc. The present document is part of a rationalized framework of standards (see ETSI TR 119 000 [i.8]). See ETSI TR 119 100 [i.9] for getting guidance on how to use the present document within the aforementioned framework.
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 7 1 Scope The present document defines multiple profiles for PAdES digital signatures which are digital signatures embedded within a PDF file.
The present document contains a profile for the use of PDF signatures, as described in ISO 32000-1 [1] and based on CMS digital signatures [i.6], that enables greater interoperability for PDF signatures by providing additional restrictions beyond those of ISO 32000-1 [1]. This first profile is not related to ETSI EN 319 142-1 [4]. The present document also contains a second set of profiles that extend the scope of the profile in PAdES part 1 [5], while keeping some features that enhance interoperability of PAdES signatures. These profiles define three levels of PAdES extended signatures addressing incremental requirements to maintain the validity of the signatures over the long term, in a way that a certain level always addresses all the requirements addressed at levels that are below it. These PAdES extended signatures offer a higher degree of optionality than the PAdES baseline signatures specified in ETSI EN 319 142-1 [4]. The present document also defines a third profile for usage of an arbitrary XML document signed with XAdES signatures that is embedded within a PDF file. The profiles defined in the present document provide equivalent requirements to profiles found in ETSI TS 102 778 [i.10].
Procedures for creation, augmentation, and validation of PAdES digital signatures are out of scope and specified in ETSI EN 319 102-1 [i.11]. Guidance on creation, augmentation and validation of PAdES digital signatures including the usage of the different attributes is provided in ETSI TR 119 100 [i.9]. The present document does not repeat the base requirements of the referenced standards, but instead aims to maximize interoperability of digital signatures in various business areas.
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 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 http://docbox.etsi.org/Reference. 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 necessary for the application of the present document. [1] ISO 32000-1: "Document management - Portable document format - Part 1: PDF 1.7". NOTE: Available at http://www.adobe.com/devnet/acrobat/pdfs/PDF32000_2008.pdf. [2] IETF RFC 2315: "PKCS #7: Cryptographic Message Syntax Version 1.5". [3] IETF RFC 5280: "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". [4] ETSI EN 319 142-1: "Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures". [5] ETSI EN 319 122-1: "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures". [6] ETSI EN 319 132-1: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures". SIST EN 319 142-2 V1.1.1:2016
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 8 [7] ETSI EN 319 132-2: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 2: Extended XAdES signatures". [8] Adobe ® XFA: "XML Forms Architecture (XFA) Specification" version 2.5, (June 2007), Adobe Systems Incorporated". [9] W3C Recommendation: "XML-Signature Syntax and Processing. Version 1.1". [10] IETF RFC 5035 (2007): "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility". [11] IETF RFC 3161 (2001): "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)". [12] IETF RFC 5816 (2010): "ESSCertIDv2 Update for RFC 3161". 2.2 Informative 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) 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 subject area. [i.1] ISO/IEC 10181-4: "Information technology - Open Systems Interconnection - Security frameworks for open systems: Non-repudiation framework". [i.2] ETSI TS 119 312: "Electronic Signatures and Infrastructures (ESI); Cryptographic Suites". [i.3] IETF RFC 5755: "An Internet Attribute Certificate Profile for Authorization". [i.4] W3C® Working Group Note, XML Signature Best Practices, 11 April 2013. [i.5] ISO 19005-1:2005: "Document management - Electronic document file format for long-term preservation - Part 1: Use of PDF 1.4 (PDF/A-1)". [i.6] IETF RFC 5652 (2009): "Cryptographic Message Syntax (CMS)". [i.7] ISO 19005-2 (2011): "Document management - Electronic document file format for long-term preservation - Part 2: Use of ISO 32000-1 (PDF/A-2)". [i.8] ETSI TR 119 000: "Electronic Signatures and Infrastructures (ESI); The framework for standardization of signatures: overview". [i.9] ETSI TR 119 100: "Electronic Signatures and Infrastructures (ESI); Business Driven Guidance for Signature Creation and Validation". [i.10] ETSI TS 102 778: "Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; CMS Profile based on ISO 32000-1". [i.11] ETSI EN 319 102-1: "Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation". [i.12] ETSI TR 119 001: "Electronic Signatures and Infrastructures (ESI); The framework for standardization of signatures; Definitions and abbreviations". SIST EN 319 142-2 V1.1.1:2016
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 9 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in ISO 32000-1 [1], ETSI TR 119 001 [i.12] and ETSI EN 319 142-1 [4] apply. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in ETSI TR 119 001 [i.12] and the following apply: CA Certification Authority CMS Cryptographic Message Syntax NOTE: As specified in IETF RFC 5652 [i.6]. CRL Certificate Revocation List DER Distinguished Encoding Rules ESS Enhanced Security Services MDP Modification Detection and Prevention OCSP Online Certificate Status Protocol PDF Portable Document Format SIM Subscriber Identity Module TSA Time-Stamping Authority UBL Universal Business Language UTC Coordinated Universal Time XML XML Forms Architecture XMP Extensible Metadata Platform 4 Profile for CMS digital signatures in PDF 4.1 Features The present profile specifies digital signatures that: • Are encoded in CMS as defined by PKCS #7 1.5 (see IETF RFC 2315 [2]). • Support serial signatures. • Optionally include signature time-stamps. • Optionally include revocation information. • Protect integrity of the document and authenticates the signer identity information included in the signing certificate. • Can optionally include the "reasons" for the signature. • Can optionally include a description of the location of signing. • Can optionally include contact info of the signer. A "legal content attestation" can be used to indicate to the relying party the PDF capabilities which may affect the signed document (e.g. JavaScript). SIST EN 319 142-2 V1.1.1:2016
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 10 4.2 Requirements of Profile for CMS Signatures in PDF 4.2.1 Requirements on PDF signatures While ISO 32000-1 [1], clause 12.8 clearly states the majority of the requirements necessary for conformance with this profile, this clause specifies additional requirements for conformance. a) PDF Signatures shall be as specified in ISO 32000-1 [1], clause 12.8. b) The signature information shall be embedded into the document itself and the ByteRange shall be the entire file, including the signature dictionary but excluding the PDF Signature itself. c) The PDF Signature (a DER-encoded PKCS#7 binary data object) shall be placed into the Contents entry of the signature dictionary. d) The PKCS#7 object shall conform to the PKCS#7 specification in IETF RFC 2315 [2]. At minimum, it shall include the signer's X.509 signing certificate. NOTE 1: Although ISO 32000-1 [1] also allows the value of the Contents entry of signature dictionary to be a DER-encoded PKCS#1 binary data object, that format is not supported by this profile. e) Timestamping and revocation information should be included in the PDF Signature. This revocation information and as much of the complete chain of certificates as is available should be captured and validated before completing the creation of the PDF Signature. f) If present, any revocation information shall be a signed attribute of the PDF Signature. g) IETF RFC 5755 [i.3] attribute certificates associated with the signer certificate should not be used. NOTE 2: ISO 32000-1 [1] allows the inclusion of one or more IETF RFC 5755 [i.3] attribute certificates associated with the signer certificate. However, attribute certificates are not widely supported and hence use of this attribute will reduce interoperability. h) There shall only be a single signer (i.e. one single component of "SignerInfo" type within "signerInfos" element) in any PDF Signature. 4.2.2 Requirements on PDF signature handlers a) A PDF reader may substitute a different
signature handler, other than that specified in Filter, when validating the signature, as long as it supports the specified SubFilter format.
b) Only the two values for SubFilter listed in ISO 32000-1 [1], clause 12.8.3.3.1 (i.e. adbe.pkcs7.detached and adbe.pkcs7.sha1) shall be used. NOTE: While the names of the SubFilters can imply specific algorithms, the actual list of supported algorithms can be found in ISO 32000-1 [1], clause 12.8.3.3.2, table 257. Consult ETSI TS 119 312 [i.2] for guidance on algorithm choices. The use of SHA-1 is being phased out and hence other hashing algorithms should be used. 4.2.3 Requirements on signature validation When the user opens a signed document and requests validation of the signature(s) present in the PDF, a reader shall invoke the appropriate signature handler that shall perform the following steps to validate them. a) Validate that the document digest matches that in the signature as specified in ISO 32000-1 [1], clause 12.8.1. b) Validate the path of certificates used to validate the binding between the subject distinguished name and subject public key as specified in IETF RFC 5280 [3]. The validity checks shall be carried out at the time indicated either by electronic time-stamp applied as per clause 4.2.4 or some other trusted indication of the signing time. The revocation status shall be checked as specified in clause 4.2.5. c) To achieve consistent validation results with existing signatures and existing implementations of signature handlers, that did not know this attribute, the signing certificate reference attribute itself should be ignored during validation if present. SIST EN 319 142-2 V1.1.1:2016
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 11 NOTE: Unlike any other Profile in the present document inclusion of the certificate hash (see CAdES [5], clause 5.2.2) is not required by this profile. Applications requiring the existence of certificate hash can use signatures based on PAdES baseline profiles [4] or the profile defined in clause 5.3 or the profile defined in clause 5.4. 4.2.4 Requirements on Time Stamping 4.2.4.1 Requirements on electronic time-stamp creation a) An electronic time-stamp from a trusted TSA should be applied to the digital signature as soon as possible after the signature is created so the electronic time-stamp reflects the time after the document was signed. b) If a signature handler chooses to embed an electronic time-stamp into the PDF Signature, then it shall be embedded as described in ISO 32000-1 [1], clause 12.8.3.3.1. 4.2.4.2 Requirements on electronic time-stamp validation a) A signature handler shall take the signature field of the PKCS#7 signature, encode it and compute the digest of the resulting byte stream using the algorithm indicated in the electronic time-stamp. b) A signature handler shall check if the value obtained in the first step is the same as the digest present in the electronic time-stamp. 4.2.5 Requirements on revocation checking When validating the PDF Signature, a signature handler may ignore any embedded revocation information in favour of alternative storage or referenced data as per its own policies. 4.2.6 Requirements on Seed Values Seed values that would require a signature handler to violate this profile shall not be used.
EXAMPLE: Seed values that specify the use of PKCS#1 are not permitted as the present document requires use of PKCS#7. 4.2.7 Requirements on encryption The Requirements in PAdES Part 1 [4], clause 5.5 shall apply. 5 Extended PAdES signature profiles 5.1 Features The profiles in this clause define PAdES signatures based on the building blocks defined in PAdES Part 1 [4]. These profiles define three levels of PAdES extended signatures that offer a higher degree of optionality than the PAdES baseline signatures specified in part 1 [4]. PAdES-E-BES Level allows basic digital signatures embedded within a PDF file. There is a unambiguous connection from the signature to the identity of a certificate intended to identify the signer. PAdES-E-EPES Level is built on top of the PAdES-E-BES Level and allows inclusion of signature policies. PAdES-E-LTV can build on either PAdES-E-BES Level or PAdES-E-EPES Level addressing incremental requirements to maintain the validity of the signatures over the long term. 5.2 General Requirements 5.2.1 Requirements from Part 1 The requirements given in clauses 4.1 and 6.2.1 of [4] (PAdES Part 1) shall apply to all profiles in this clause. SIST EN 319 142-2 V1.1.1:2016
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 12 5.2.2 Notation of Requirements The present clause describes the notation used for defining the requirements of the different extended PAdES signature profiles. The requirements on the attributes and certain signature fields are expressed in tables. A row in the table either specifies requirements for an attribute or a service. These tables contain five columns. 1) Column "Attribute/Field/Service": - this cell contains the name of the attribute or signature field. 2) Colum "Presence": This cell contains the specification of the presence of the attribute or signature as follows:
- "shall be present": means that the attributes or signature fields shall be present, and shall be as specified in the document referenced in column "References", further profiled with the additional requirements referenced in column "Requirements", and with the cardinality indicated in column "Cardinality". - "shall not be present": means that the attributes or signature fields shall not be present. - "may be present": means that the attributes or signature fields may be present, and shall be as specified in the document referenced in column "References", further profiled with the additional requirements referenced in column "Requirements", and with the cardinality indicated in column "Cardinality". - "conditioned presence": means that the presence of the item identified in the first column is conditioned as per the requirement(s) specified in column "Requirements" and requirements referenced by column "References" with the cardinality indicated in column "Cardinality". 3) Column "Cardinality": This cell indicates the cardinality of the attribute or signature field as follows: - 0: The signature shall not incorporate any instance of the attribute or signature field. - 1: The signature shall incorporate exactly one instance of the attribute or signature field. - 0 or 1: The signature shall incorporate zero or one instance of the attribute or signature field. - ≥ 0: The signature shall incorporate zero or more instances of the attribute or signature field. - ≥ 1: The signature shall incorporate one or more instances of the attribute or signature field. 4) Column "Additional notes and requirements": This cell contains numbers referencing notes and/or letters referencing additional requirements on the attribute or signature field. Both notes and additional requirements are listed below the table. 5) Column "Reference": This cell contains either the number of the clause specifying the attribute in the present document, or a reference to the document and clause that specifies the signature field. 5.3 PAdES-E-BES Level The requirements and the attributes within signature dictionary and SignerInfo are as defined in table 1. For any optional unsigned attribute incorporated in the signature, DER encoding shall be used for this attribute, whilst preserving the encoding of any other attribute field.
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 13 Table 1: Requirements for the main attributes in PAdES-E-BES signatures Attribute/Field/Service Presence Cardinality Additional notes and requirements Reference content-type shall be present 1 a ETSI EN 319 122-1 [5], clause 5.1.1 message-digest shall be present 1
ETSI EN 319 122-1 [5], clause 5.1.2 signing-certificate reference shall be present 1 b, c, d
signer-attributes-v2 may be present 0 or 1
ETSI EN 319 122-1 [5], clause 5.2.6.1 content-time-stamp may be present ≥ 0
ETSI EN 319 122-1 [5], clause 5.2.8 signature-time-stamp may be present ≥ 0
ETSI EN 319 122-1 [5], clause 5.3 commitment-type-indication conditioned presence 0 or 1 e ETSI EN 319 122-1 [5], clause 5.2.3 entry with key M in the Signature Dictionary may be present 0 or 1 f ISO 32000-1 [1], clause 12.8.1 entry with key Location in the Signature Dictionary may be present 0 or 1
ISO 32000-1 [1], clause 12.8.1 entry with key Reason in the Signature Dictionary
conditioned presence 0 or 1 g ISO 32000-1 [1], clause 12.8.1 entry with key Filter in the Signature Dictionary shall be present 1 h ISO 32000-1 [1], clause 12.8.1 entry with key ByteRange in the Signature Dictionary shall be present 1 i ISO 32000-1 [1], clause 12.8.1 entry with key SubFilter in the Signature Dictionary shall be present 1 j ISO 32000-1 [1], clause 12.8.1 entry with key Contents in the Signature Dictionary shall be present 1 k ISO 32000-1 [1], clause 12.8.1 entry with key Name in the Signature Dictionary may be present 0 or 1
ISO 32000-1 [1], clause 12.8.1 entry with key ContactInfo in the Signature Dictionary may be present 0 or 1
ISO 32000-1 [1], clause 12.8.1 entry with key Cert in the Signature Dictionary shall not be present 0
ISO 32000-1 [1], clause 12.8.1
Additional requirements: a) The content-type attribute shall have value id-data. b) As specified in IETF RFC 5035 [10], the ESS signing-certificate attribute shall be used if the SHA-1 hash algorithm is used. c) As specified in IETF RFC 5035 [10], the ESS signing-certificate-v2 attribute shall be used when another hash algorithms than SHA-1 is used. d) The generator should migrate to the use of ESS signing-certificate-v2 in preference to ESS signing-certificate in line with the guidance regarding limited lifetime for the use of SHA-1 given in ETSI TS 119 312 [i.2]. e) The commitment-type-indication attribute may be incorporated in the CMS signature only if
the entry with the key Reason is not used. Otherwise the commitment-type-indication shall not be incorporated in the CMS signature. f) The generator should include the claimed UTC time of the signature in a format defined in ISO 32000-1 [1], clause 7.9.4 as content of this element. g) The entry with the key Reason shall not be used if the commitment-type-indication attribute is present in the CMS signature. h) A verifier may substitute a different signature handler, other than that specified in Filter, when validating the signature, as long as it supports the specified SubFilter format. SIST EN 319 142-2 V1.1.1:2016
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 14 i) The ByteRange shall cover the entire file, including the signature dictionary but excluding the PDF Signature itself. j) The signature dictionary shall contain a value of ETSI.CAdES.detached for the key SubFilter. k) Requirements specified in ISO 32000-1 [1], clauses 12.8.3.2 (PKCS#1) and 12.8.3.3 (PKCS#7) shall not be used. 5.4 PAdES-E-EPES Level The requirements and the attributes within SignerInfo are as defined in table 1 to which those ones defined in table 2 shall be added/replaced. For any optional unsigned attribute incorporated in the signature, DER encoding shall be used for this attribute, whilst preserving the encoding of any other attribute field.
Table 2: Requirements for the main CAdES attributes in PAdES-E-EPES level Attribute/Field/Service Presence Cardinality Additional notes and requirements Reference signature-policy-identifier shall be present 1
ETSI EN 319 122-1 [5], clause 5.2.9 entry with key Reason in the Signature Dictionary shall not be present 0
ISO 32000-1 [1], clause 12.8.1
5.5 PAdES-E-LTV Level Signature handlers creating and/or validating PDF documents with PAdES-LTV shall support PDF documents with: a) Document security store information as specified in clause 5.4.2 in ETSI EN 319 142-1 [4]. b) Document time-stamps as specified in clause 5.4.3 in ETSI EN 319 142-1 [4]. Signed PDF documents should contain DSS followed by a document time-stamp. Validation data shall be carried by values within the DSS. NOTE 1: Use of validation data in DSS referencing external sources is not supported by the current profile. Systems shall support creation and/or validation of signatures with one or more DSS entries and document time-stamps. NOTE 2: Object IDs should not be reused when adding new validation data, because of the possibility to "hide" already existing validation data. A signature handler may check the existence of older validation data having the same Object IDs to be explicitly aware of the fact that the latest objects could contain invalid or unusable validation data. 6 Profiles for XAdES Signatures signing XML content in PDF 6.1 Features The profiles in this clause allow the signing of XML Data that is embedded in a PDF file. The first two profiles allow inclusion of XAdES signatures in PDF and the augmentation of these signatures to achieve long-term validation. The second two profiles allow signatures on XFA-forms and the augmentation of these signatures to achieve long-term validation.
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 15 6.2 Profiles for XAdES signatures of signed XML documents embedded in PDF containers 6.2.1 Overview This clause defines a profile for usage of an arbitrary XML document signed with XAdES signatures that is embedded within a PDF file, for providing integrity, authentication and non-repudiation services on the data objects that are signed with the XAdES signature. This XML document can be aligned with any XML language, i.e. a signed UBL e-Invoice.
NOTE 1: The term "data object" applies to any resource that is referenced by the XMLDSig mechanisms. It does apply to the XML document when it is signed as a whole, and also to a collection of elements of the XML document if only these elements are signed. This clause defines two profiles, namely: a basic profile for XAdES-E-BES, XAdES-E-EPES, and XAdES-E-T signature levels, and a long-term profile for signature levels from XAdES-E-C to XAdES-E-A. The scenario for usage of the first profile, specified in clause 6.2.2, is described below and shown in figure 1: 1) An XML document is created and signed with XAdES (levels XAdES-E-BES, XAdES-E-EPES, XAdES-E-T) out of the PDF framework.
2) The aforementioned signed XML document is embedded within the PDF container and is transported within it.
Figure 1: Scenario for profile for basic XAdES signatures of XML documents
embedded in PDF containers The scenario for usage of the second profile, specified in clause 6.2.3, is described below and shown in figure 2: 1) The PDF container with the signed XML document is received by the verifier. The verifier extracts the embedded file and validates the XAdES signature.
2) The verifier can augment the XAdES signature to upper levels as specified in ETSI EN 319 132-2 [7]. As the XAdES signature is part of an embedded file, the Document Secure Store specified in ETSI EN 319 142-1 [4] is not able to contain the validation material added during the augmentation. This augmentation will, in consequence, be done outside the PDF container and within the XAdES signature itself. aaa …….
> …… .
> ….
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 16 NOTE 2: It is understood that augmenting the XAdES signature or augmenting the document by a Document Secure Store could provide the verifier with the same information to validate the document in the long run. It is important to augment the XAdES signature in order to enhance interoperability between verifiers.
3) The signed XML document with the augmented XAdES signature is embedded again within the PDF container. NOTE 3: Augmenting the XAdES signature can be done by extracting the stream object containing the XAdES signature from the containing document, augmenting the XAdES signature in that XML document and including the augmented XML document in a new stream with the same pdf object number by an incremental update.
Figure 2: Scenario for profile for long-term XAdES signatures of signed XML documents embedded in PDF containers aaa …… .
> …… .
> … . aaa …… .
> …… .
> … extract augment embed
………………. SIST EN 319 142-2 V1.1.1:2016
ETSI ETSI EN 319 142-2 V1.1.1 (2016-04) 17 6.2.2 Profile for Basic XAdES signatures of XML documents embedded in PDF containers 6.2.2.1 Features The main features provided by this profile are listed below: a) The signed XML document (including the XAdES signatures) is created independent from the PDF container. The relative placement of XAdES signatures and the signed data objects are restricted as sp
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...