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

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

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 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:

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

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.

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.

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:

identifying the ID-ness of attributes requires additional information
that is often not present in documents; implementations may need to
resort to evaluating schemas to dereference IDs

when several implementations touch the same XML document (e.g., in the
case of protocols that are built on top of XML Signature), generating
unique ID values might turn out to be a challenge

in some use cases, mutable IDs might be desirable

if parts of XML content are addressed by ID attribute, they can be
moved to arbitrary positions in the overall document tree, possibly
changing document semantics in unexpected manners

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.

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:

layering several canonicalization steps as needed, some of which might
be application specific (Simon)

redesigning canonicalization algorithms from scratch, possibly giving
up on the requirement that canonicalization output XML (Thompson)

leveraging work done in the Efficient XML Interchange Working Group (Williams)

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.

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.

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.

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.

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.

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.

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.