6.1 Signature levels
Clause 6 defines four levels of XAdES baseline signatures, intended to facilitate interoperability and to encompass the
life cycle of XAdES signature, namely:
B-B level provides requirements for the incorporation of signed and some unsigned qualifying properties when
the signature is generated.
B-T level provides requirements for the generation and inclusion, for an existing signature, of a trusted token
proving that the signature itself actually existed at a certain date and time.
B-LT level provides requirements for the incorporation of all the material required for validating the signature
in the signature document.
4.4 Electronic signature forms The current clause specifies four forms of XML advanced
electronic signatures, namely the Basic Electronic Signature (XAdES-BES), the Explicit Policy
based Electronic Signature (XAdES-EPES), and the Electronic Signature with Validation Data
(XAdES-T and XAdES-C).
4.5 Validation process The Validation Process validates an electronic signature, the output
status of the validation process can be: - invalid; - incomplete validation; - valid.
4.4 Electronic signature forms The current clause specifies four forms of XML advanced
electronic signatures, namely the Basic Electronic Signature (XAdES-BES), the Explicit Policy
based Electronic Signature (XAdES-EPES), and the Electronic Signature with Validation Data
(XAdES-T and XAdES-C). Conformance to the present document mandates the signer to create one
of these formats. The informative annex B defines extended forms of XAdES. Conformance to the
present document does not mandate the signer to create any of the forms defined in annex B.
4.5 Validation process The Validation Process validates an electronic signature, the output
status of the validation process can be: - invalid; - incomplete validation; - valid. An
Invalid response indicates that either the signature format is incorrect or that the digital
signature value fails verification (e.g. the integrity check on the digital signature value
fails or any of the certificates on which the digital signature verification depends is known
to be invalid or revoked). An Incomplete Validation response indicates that the format and
digital signature verifications have not failed but there is insufficient information to
determine if the electronic signature is valid. For example; all the required certificates
are not available or the grace period is not completed. In the case of Incomplete Validation,
the electronic signature may be checked again at some later time when additional validation
information becomes available. Also, in the case of incomplete validation, additional
information may be made available to the application or user, thus allowing the application
or user to decide what to do with partially correct electronic signatures. A Valid response
indicates that the signature has passed verification and it complies with the signature
validation policy. Informative annex G gives details on technical rules that verifiers should
follow for verifying XAdES signatures.
4.6 Arbitration In case of arbitration, a XAdES-C form provides reliable evidence for a valid
electronic signature, provided that: - the arbitrator knows where to retrieve the signer's
certificate (if not already present), all the required certificates and CRLs, ACRLs or OCSP
responses referenced in the XAdES-C; - when time-stamping in the XAdES-T is being used, the
certificate from the TSU that has issued the time-stamp token in the XAdES-T format is still
within its validity period; - when time-stamping in the XAdES-T is being used, the
certificate from the TSU that has issued the time-stamp token in the XAdES-T format is not
revoked at the time of arbitration; - when time-marking in the XAdES-T is being used, a
reliable audit trail from the Time-Marking Authority is available for examination regarding
the time; - none of the private keys corresponding to the certificates used to verify the
signature chain have ever been compromised; - the cryptography used at the time the XAdES-C
was built has not been broken at the time the arbitration is performed. If the signature
policy can be explicitly or implicitly identified then an arbitrator is able to determine the
rules required to validate the electronic signature.
Annex B (informative): Extended electronic signature forms The XAdES forms specified in
clause 4.4 can be extended by addition of certain unsigned properties that are defined in the
present document. These properties are applicable for very long term verification, and for
preventing some disaster situations which have been identified in the normative part of the
present document. The clauses below give an overview of the various forms of extended
signature formats in the present document.
6.1 Signature levels
Clause 6 defines four levels of XAdES baseline signatures, intended to facilitate interoperability and to encompass the
life cycle of XAdES signature, namely:
B-B level provides requirements for the incorporation of signed and some unsigned qualifying properties when
the signature is generated.
B-T level provides requirements for the generation and inclusion, for an existing signature, of a trusted token
proving that the signature itself actually existed at a certain date and time.
B-LT level provides requirements for the incorporation of all the material required for validating the signature
in the signature document. This level aims to tackle the long term availability of the validation material.
B-LTA level provides requirements for the incorporation of electronic time-stamps that allow validation of the
signature long time after its generation. This level aims to tackle the long term availability and integrity of the
validation material.
Returns the enum constant of this type with the specified name.
The string must match exactly an identifier used to declare an
enum constant in this type. (Extraneous whitespace characters are
not permitted.)
Parameters:
name - the name of the enum constant to be returned.