W3C Technology and Society Domain

Workshop Report
W3C Workshop on Next Steps for XML Signature and XML Encryption

25/26 September 2007 -- Mountain View, California
hosted by VeriSign

Workshop Goals and Scope

Audience

This Workshop included implementors and users of the XML Canonicalization, XML Signature and XML Encryption suites of specifications. The participants included implementers and specification writers that have built their work on top of these specifications. Participants in the workshop had to submit a position paper.

The workshop had 25 participants from over 15 organizations.

Workshop Goals

The aim of this workshop was to gather information and experiences with these specifications, to start to build community consensus, and to make initial recommendations to the W3C about possible next steps for the XML Security specifications.

Workshop Materials

Slides and position papers related to workshop sessions are linked from the Workshop Agenda. Workshop minutes are available:

Summary slides created during the final sessions of both workshop days are available.

Executive Summary

Workshop participants discussed topics of possible future work on the XML Signature specification, and companion specifications such as Canonical XML.

Topics of interest, and the levels of interest, are summarized in the following table. A more detailed summary of the individual areas of interest can be found in the next section.

Topic Description Interest level
Create Basic Profile of XML Signature Defining a constrained and simpler profle of XML Signature to enhance security, performance and ability to create implementations High
Update Referencing Model Work out issues related to referencing material to be signed, using xml:id and other mechanisms High
Update Cryptographic Algorithms Integrate additional algorithms with XML Signature, possible changes to Recommended or Required algorithms. Review approach to adding algorithms in future. High
Revisit overall approach toward XML canonicalization Reconsider XML canonicalization, considering application, security and implementation requirements. High
Transform Model Clarify whether output of transforms is document (in XML case); whether and how to constrain transforms; pipelining and subsetting approaches Medium toward High
Profiling - deterministic time of processing Designing a profile that scales deterministically with size of input Medium
Implementation guidance Provide security guidance and suggestions for which API hooks might be required Medium
Key Management - known spec issues Clarify dsig:RetrievalMethod and other known issues with XML Signature key management Medium
Key Management - XKMS Put XKMS in sync with updated XML Signature, add support for symmetric keys, but not perform a re-write Medium
Encapsulating XML How to incorporate one XML document in another and enable signing Medium
XML 1.1 and EXI Consider relationship with XML 1.1 and EXI Broad topic for additional consideration
Refactoring/Backward compatibility Determining how much backward compatibility is required, how to layer and factor the process Broad topic for additional consideration
Interact with other groups and organizations Get security considerations and other input from other communities, such as OASIS SAML, Liberty Alliance, Web Services Security, etc This is a general aspect of chartered activities

One outcome of the workshop is the indication that there is strong interest in additional work on XML Security and also interest in participating in a possible Working Group. Another outcome is the list of specific topic areas of interest.

Next Steps

The XML Security Specifications Maintenance Working Group is chartered to produce a draft charter for follow-up work. This Workshop report will serve as input to that deliverable.

To enable discussion among Workshop attendees, Working Group members, and the broader community, a new mailing list public-xmlsec-discuss@w3.org (public archive) has been created. Participation in that mailing list is open to all interested parties.

Summary of Discussions

This section gives a more detailed summary of the areas of interest discussed at the workshop, and tries to summarize common themes identified during discussions.

Profiles

Profiling the use of the XML Signature specification by constraining optional aspects of the specification and the use of certain features of the specification was identified as being a promising area of future work for a number of applications. A basic profile for the specification could identify an easier to implement, but still flexible subset of the specification useful for many use cases, whlie improving interoperability and performance of implementations. By reducing certain optional features (e.g., XSLT transforms), such a profile could contribute to reducing the attack surface that implementations of XML Signature expose to attackers that are able to craft input documents.

Processing with favorable scaling behavior (e.g., linear in the length of documents) might be enabled by limiting the use of the <Transform> element and related features; such a profile might also contribute to limiting the attack surface against denial of service attacks. Similarly, such constraints might contribute to a use of XML Signature in which signature verification can be performed significantly more efficiently than signature creation. A related use case that was mentioned repeatedly during discussion concerns the incremental verification of signatures on streaming data.

In some use cases, only limited XML processing is needed as part of the signing process. A bulk signing profile could enable simple, interoperable implementations tailored to such use cases; such a profile might enable use of XML signature in cases in which non-XML-centric signing mechanisms appear favorable today. (See Cantor, Hodges.)

Workshop participants also discussed run-time profiling approaches, which might enable the communication of constraints as part of service descriptions and policies, and as part of signatures. Work in this area could usefully interact with specifications such as WS-Policy and WS-SecurityPolicy.

Referencing Model

XML Signature currently uses a referencing model based on XPointers. While participants found this referencing model to work well in terms of achieving interoperability of signatures, the security properties actually achieved using XML Signature were at times found surprising (Gajek et al, Lockhart).

On the one hand, ID attribute based referencing approaches suffer from a number of known issues:

Participants identified communicating the ID-ness of attributes as part of signature metadata as a promising approach toward tackling at least the first of these issues.

On the other hand, structure-based approaches have been found to suffer from ambiguities in protocol message contexts. (Lockhart)

An ideal referencing model would be fully semantic, layer-friendly, and would conform to all the requirements listed. Workshop participants acknowledged that such an approach might not be achievable in practice. Yet, working out the tension between the various requirements and taking a fresh look at reconciling ID-based referencing mechanisms was identified as an important area for future work.

Cryptographic Algorithms

Several workshop participants presented proposals related to markup support for additional cryptographic algorithms in XML Signature:

Possible changes to the current set of mandatory to implement algorithms (including, at this point, SHA-1) were briefly discussed, and identified as an important area for near-term future work.

One possible chartering consideration related to algorithm incorporation might be the intellectual property (IPR) status.

Patterns for specifying algorithms or algorithm suites were proposed and discussed (Hallam-Baker).

Canonicalization

Mandatory to implement canonical XML and the derived and more commonly used exclusive canonicalization were found to be not satisfactory, and a significant source of empirically observed performance issues (Zhang). A number of approaches toward canonicalization were discussed:

Discussion covered various topics including whether canonicalization should conceptually be considered part of the hashing performed, or as a pre-processing step before data are seen by a processing implementation, and what the "what you see is what you sign" principle actually means for the design of canonicalization algorithms.

Revisiting canonicalization algorithms (including the current choice of mandatory to implement inclusive canonicalization) was identified as an area of major interest for future work.

Transform Model

The XML transform model today specifies a chain of tranformations that can work on either node-sets based on the XPath 1.0 data model or octet streams. The full transform model is found to preclude streaming processing of transforms (Datta ), and to be an obstacle to one-pass implementation approaches (Mullan). Constraining certain aspects of the transformations that can be specified as part of signature data could lead to significant gains of performance, and enable streaming processing. Implementers present reported that actual implementations typically include optimized processing models for transform chains. It is not know what a common, interoperable subset of these transform models would look like.

Participants identified XProc as a possible alternative to the current model for specifying transforms which should be further considered.

Implementation Guidance

Workshop participants identified a number of concerns around current implementations of XML Signature: Handling of XML Signature in scripting language contexts (e.g., JavaScript, PHP) was found to be a major concern for deployment of the specification in Web application related use cases.

Guidance on the order of operations when verifying signatures (and the use of certain optional features during signature verification) might contribute significantly to reducing the attack surface of signature verification, by enabling implementers to partition the attack surface into a small anonymous and a larger non-anonymous part. (See Hill.) Work on such guidance relates closely to the proposal around a basic profile for XML Signature.

As a contributory factor, common XML Signature APIs today do not enable early trust decisions by signature consumers, leading to a single, broad attack surface of signature verifiers. Additional guidance could note addiitional APIs to provide applications visibility into the security process, as needed.

Documenting known countermeasures to wrapping attacks (see Gajek et al) and generally improving the specification's security considerations (Gajek et al, Hill) were identified as additional steps that might be taken to improve implementation quality of XML Signature.

Key material and management

The <KeyInfo> element and related issues were identified as an area of the XML Signature spec that was historically left more open than other parts of the specification, and may be in need of further work. It appears unclear to what extent this part of the specification is actually used.

Specification clarity -- in particular concerning the RetrievalMethod and X509Data elements -- was identified as a major issue in this space.

As a side effect of revisiting this area of the specification, minimal changes to XKMS and other specifications that re-use the key material parts of XML Signature were suggested as a useful work item. It was noted that adding support for symmetric cryptographic algirthms to XKMS would also be useful during any revision of XKMS.

Outlook: XML 1.1 and EXI

The current suite of XML security specifications is specified in terms of the XPath 1.0 data model, and therefore not specified for XML 1.1. Also, the work of the Efficient XML Interchange Working Group creates new requirements for the XML security specifications (Williams). Both areas need further consideration.

Backwards Compatibility

There was significant discussion among participants about backwards compatibility models for future work. While some participants (Lockhart) suggested that future work should not be constrained to be backwards-compatible with the existing specification, others said during discussion that future work should be as backwards-compatible as possible.

Compatibility for such work could be achieved by using existing extension points, or by keeping the semantics of the existing specification as a subset of a new specification.

Not deprecating the current version of XML Signature (in particular as the meaning of existing signatures is concerned) was identified as a possibly important chartering requirement for future work.

Additional factors that enter into compatibility considerations for a future charter include the effect on dependent specifications (WS-Security, XKMS, SAML, and others), and the impact that inevitable cryptographic algorithm changes will have on deployments.

Interactions with other groups

Participants observed that future work would need to take work done on the XML Processing Model and Efficient XML Interchange into account. Reference model related issues seem likely to require consideration of a broader picture, including the effect of the xml:id specification and other work in the core XML Community.

Concern was expressed on the ability of other groups to re-use portions of the XML Security specifications. As an example, a revision of XML Signature might define schema elements globally to enable re-use. Thus any revision may need to include re-usability as a requirement.

Existing work on long-term archival and notary services in various fora is based on XML Signature; these communities were identified as relevant stakeholders in future work. Additional "customers" of the XML Signature and related specifications include the SAML community, WS-I, the WS-Security community, Liberty alliance, and a number of other related groups.

The work of the ETSI XADES technical committee was brought to the attention of workshop participants (Cruellas et al). It was suggested that features for which a satisfying specification has been developed in the course of this work not be duplicated in eventual future W3C work.


Frederick Hirsch, Thomas Roessler
$Id: report.html,v 1.8 2007/10/23 15:38:44 roessler Exp $