W3C is pleased to receive the XAdES Submission from Cisco Systems.
XAdES extends the XML Signature Specification with additional syntax and processing necessary to satisfy the European Commission Directive on a Community Framework for Electronic Signatures as well as other use-cases requiring long-term validity. XAdES itself contains several modules that permit varying levels of security such as non-repudiation with time-stamps, certification data and certification archives.
W3C Team members have commented on the ETSI specifications, attended meetings of ETSI-ESI and continue to maintain an informal liaison. The following issues were part of these discussions that might be of interest for a larger community.
During the elaboration of XAdES Denis Pinkas argued that the persistence of DNS and the domain will be crucial for the security of the Signatures. If the domain could be re-attributed or if the underlying schema could be changed, the URI indicating the meaning of the elements could change. Thus the semantics described would change and the signed document or information would change meaning: the signature could be compromised.
In this context it is worthwhile to note that ETSI has adopted a policy with respect to persistence of the URIs for XML Namespaces also affecting those used in XAdES, which was a major step. The policy is similar to the persistence policy of the W3C. This allowed the XAdES specification to keep the initial ETSI-namespace used while being conformant to W3C's expectations about persistence. It means that the issue has been resolved satisfactorily and might give some hints for others using namespaces in security-related XML applications.
In section 5.1.2 (The ObjectIdentifierType data type) the identifier can be specified using URIs or OIDs. XAdES requires the OIDs to be represented in the form URN-OID as specified by RFC 3061, which provides an namespace for OIDs and allows them to be expressed in a format conforming to RFC 2396 [URI]. This helps bridge the gap between the ASN.1 and XML worlds.
It might be confusing that the terms SignedProperties and
UnSignedProperties are used to qualify XAdES information that
apply to a particular ds:Signature, and do not actually indicate
whether the information has or has not been signed by some other signature. A
different name for these elements might have helped to avoid
misunderstandings.
XML Signature specifies that the ds:SignatureProperties can
only include information about the ds:Signature. But XAdES
includes other information such as time-stamps, countersignatures, and
certificates that are not exclusively about the signature. Consequently,
XAdES encapsulates all of its information (even that information about the
signature) in XML-Signature's ds:Object element. However, this
rationale is not stated in the specification and readers might find this
choice confusing otherwise.
DataObjectFormat elementThe DataObjectFormat element provides information that
describes the format of the signed data object as it is rendered to the user.
This element, which is intended to describe how the document being signed is
to be rendered to the signing user, seems misguided and dangerous. First, the
information being provided (e.g., Encoding) may differ or
disagree with information found elsewhere in the processing (e.g., the
transport protocol). Second, it is not clear what this information applies to
within the signature processing pipe-line. For example, does this describe
the data before or after a signature transform, such as canonicalization?
Third, who is to say that the textual description actually corresponds to
what is being signed by a user? It does not appear that the XAdES
specification is defining application behavior with respect to this element
so we have no expectation about how the correspondence between this
description and the actual rendering can be drawn or enforced.
Furthermore, explicit specification of rendering conditions can be counter to W3C's efforts to make the Web device independent, accessible to all users, and to permit multiple modes of interaction. Constraints on the validity of a signature because of the media device or rendering may prevent the users of devices such as mobile phones, voice browsers, and screen readers from participating fully.
XAdES uses and extends the XML-Signature Recommendation. It
specifies how to add qualifying information to an XML-Signature such that it satisfies
the requirements of long-term validity and the Advanced Electronic
Signature according to the "Directive
1999/93/EC of the European Parliament and of the Council of 13 December 1999
on a Community framework for electronic signatures" (hereafter named Directive). Ultimately,
a signature according to XAdES incorporates a commitment that has been
explicitly endorsed under a signature policy, at a given time, by a signer
under an identifier, e.g. a name or a pseudonym, and optionally a
role
.
The Directive provides a legal framework for the recognition of digital/electronic signatures. It distinguishes between normal electronic signatures and advanced electronic signatures. It is worth noting that the Directive does not distinguish between other levels of security. In fact, Article 5.2 rules that Member States shall ensure that an electronic signature is not denied legal effectiveness and admissibility as evidence in legal proceedings solely on the grounds that it is:
Advanced Signatures have the following requirements stated by Article 2.2
of the Directive:
advanced electronic signature" means an electronic signature which meets the following requirements:
(a) it is uniquely linked to the signatory;
(b) it is capable of identifying the signatory;
(c) it is created using means that the signatory can maintain under his sole control; and (d) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable;
Article 5.1 gives the incentive for advanced electronic signatures:
Member States shall ensure that advanced electronic signatures [...]
(a) satisfy the legal requirements of a signature in relation to data in electronic form in the same manner as a handwritten signature satisfies those requirements in relation to paper-based data; and
(b) are admissible as evidence in legal proceedings.
The technical work of standardization of electronic signatures was supported by the European Commission and mandated to the Information and Communication Technologies Standards Board (ICTSB), a round table of most European IT standards bodies and some international standards bodies such as the W3C.
For the purpose of standardizing electronic signatures, ICTSB created the EESSI Steering Group under the auspecies of ICTSB. The EESSI Steering Group delegated the development of appropriate document formats for electronic signatures that fulfill the requirements of the Directive to the ETSI ESI Activity. (This submission is a specification delivered by ETSI in the framework of the ESI Activity.)
The original format for Advanced Electronic Signatures was specified in ETSI TS 101 733 as a ASN.1 representation. XAdES is based on the contents of the ETSI Technical Specification TS 101 903: "XML Advanced Electronic Signatures (XAdES)". Given the importance of electronic signatures for commerce and the growing importance of XML within that context, (e.g., ebXML), the EESSI Steering Group invited the W3C to help enable advanced electronic signatures for XML applications. Funding from EESSI and the European Commission and the informal liaison with the W3C contributed to the development of XAdES under the auspices of the ETSI STF 178 task force. Some of the European Commission supported experts from this XAdES task force were also participating actively in W3C's XML-Signature Working Group. The result of this collaboration was a preference for a translation of ETSI TS 101 733 that uses the full benefit of XML instead of a narrow transliteration of the ASN.1 format. In ETSI, the XAdES-Specification carries the number TS 101 903.
XAdES provides additional syntax and semantics to XML-Signature for such things as non-repudiation and long term validity. To be able to address the requirements of advanced electronic signatures in the sense of the Directive there are also additional measures needed such as the use of secure signature creation devices. These additional specifications are provided on the EESSI Web site.
The specifications aiming to fulfill the requirements of the Directive will need approval from the so called Article 9 Committee. The committee has not yet made a decision and consequently these specifications have not yet been published in the European Official Journal. However, the chair of ETSI ESI has reported that the negotiations with the Article 9 Committee on the original (ASN.1) ETSI TS 101 733 specification has not yielded major changes in syntax or semantics. Consequently, while XAdES will be updated to track any adjustments in ETSI TS 101 733, few changes are expected.
The submission will be brought to the attention of the XML Signature Activity's mailing-list w3c-ietf-xmldsig@w3.org. The work on XML Signature closed on 31 December 2002. The Activity Statement of the XML Signature still encourages the use of w3c-ietf-xmldsig@w3.org for the discussion of future work. XAdES is intended as a contribution to future work in this area and might be taken up by future Working Groups developing further features in the area of XML Signature.
XAdES will also be brought to the attention of Web Services Architecture Group and the XML Protocol Working Group. As ebXML may rely on Web Services, as ebXML has chosen XML Protocol/Soap as it's underlying Protocol, the securing of such commercial exchanges -especially those carrying high value- can make use of XML Signature. The developers of XAdES believe that it can provide the necessary formats to enable certain exchanges to meet various levels of legal certainty specified by the European Commission Directive on Electronic Signatures.
Rigo Wenning
Privacy Activity Lead
with contributions from
Joseph Reagle XML Signature Co-Chair