2.5.12 XML Digital Signatures (xmldsig)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00

Chair(s):

J. Reagle <reagle@w3.org>
Donald Eastlake 3rd <dee3@torque.pothole.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:w3c-ietf-xmldsig@w3.org
To Subscribe: w3c-ietf-xmldsig-request@w3.org
In Body: Nothing. Enter (un)subscribe in SUBJECT line
Archive: http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig

Description of Working Group:

INTRODUCTION:

Digital signatures provide integrity, signature assurance and non-repudiatability over Web data. Such features are especially important for documents that represent commitments such as contracts, price lists, and manifests. In view of recent Web technology developments, the proposed work will address the digital signing of documents (any Web resource addressable by a URI) using XML syntax. This capability is critical for a variety of electronic commerce applications, including payment tools.

MISSION STATEMENT:

The mission of this working group is to develop an XML compliant syntax used for representing the signature of Web resources and portions of protocol messages (anything referencable by a URI) and procedures for computing and verifying such signatures. Such signatures may be able to provide data integrity, authentication, and/or non-repudiatability. The meaning of the signature may be extensible by a set of semantics specified separately.

JOINT IETF / W3C COORDINATION:

This effort is equally and strongly dependent on XML expertise and coordination, which is in the W3C, and Internet cryptographic expertise and coordination, which is in the Internet Engineering Task Force (IETF). Therefore, the working group will be a joint body operating simultaneously as an IETF WG and a W3C WG. Procedures may differ from the norm for either organization (IETF RFCs 2026 / 2418 & World Wide Web Consortium Process Document). Details are give in the sections below.

SCOPE:

The core scope of this activity will be in specifying the necessary data model, syntax, and processing to bind a cryptographic signature to a resource in XML. The working group will focus on:

1. Creating a data model that permits XML-DSig to be an integral part of developing metadata and object model technologies.

2. Creating a extensible canonicalization framework. In addition, specify application requirements over canonicalization. All XML-DSig applications must be able to sign - at least - the binary byte stream. The group may also require applications to support XML syntax or Unicode canonicalization if those mechanisms are widely understood and necessary. This group will coordinate its requirements with activities delivering XML, RDF, or DOM canonicalization mechanisms.

3. Syntax and processing for XML signatures.

4. Document the WG's position on signature semantics. At the Chair's discretion the WG may develop a (small) set of signature semantics. Such a proposal would define common semantics relevant to signed assertions about Web resources and their relationships in a schema definition (XML/RDF) or link type definition (XLink).

5. Defining the charter for subsequent work once (1-4) has been achieved.

REQUIREMENTS:

The following requirements must be met by the WG:

1. Define a simple signature XML syntax that is highly extensible. We wish to create a simple digital signature syntax that can be used with other application semantics (through XML-namespaces) so as to create arbitrarily sophisticated assertion capabilities.

2. Ensuring that applications can create and process composite/compound documents consisting of XML and non-XML data as well as for processing detached or external signature blocks and assertions.

3. XML-DSig must be coordinated with and use the work product of other mature XML technologies.

4. XML-DSig syntax expresses data model semantics; we do not require applications to make inferences on that data model.

5. Mandatory portions of the specification must be implemented in at least two independent implementations before being advanced to Proposed Standard.

CONTRAINTS:

The working group will not address the following issues:

1. Trust engines

2. Public key infrastructure

3. Trust management systems

4. XML schemas for certificates

DEMONSTRATION APPLICATIONS:

It is hoped that the following applications being developed by members of the WG will provide a useful test of the completeness:

1. Internet Open Trading Protocol v2.0

2. [some document / web-page application TBD]

3. Financial Services Mark Up Language v2.0

DELIVERABLES:

This working group will deliver the following:

- - Informational RFC (W3C NOTE) further specifying the requirements and dependencies for the remaining deliverables.

- - Proposed Standard RFC (W3C Recommendation) that defines a highly extensible XML syntax and processing used for associating a signature with XML data without semantic specification but having provisions for the inclusion of such specification.

- - Optional Informational RFC (W3C NOTE) on signature semantics labeling and, if appropriate, an additional (small) set of signature semantics in a schema definition (XML/RDF) or link type definition (XLink).

- - Informational RFC (W3C NOTE) documenting a set of test cases for interoperability testing and a report on interoperability results.

- - If appropriate, charters for further work.

COORDINATION WITH OTHER W3C GROUPS:

A central characteristic of this activity is its dependencies on other XML working groups. The WG chair will likely be a member of the W3C XML Coordination Group. During W3C Last Call, the Chair will procure reviews from the following W3C WGs before the specification will be advanced further:

1. XML Syntax/Core WG: Canonicalizing XML which involves finding a single or "canonical" version of every possible form of the same document by reducing white space, mapping quote marks to a standard form, etc. etc.) with a view to using that standard form for the purpose of applying digital signature technology.

2. XML Linking WG: The objective of the XML Linking Working Group is to design advanced, scalable, and maintainable hyperlinking and addressing functionality for XML

3. XML Schema WG: The XML Schema Working Group is addressing means for defining the structure, content and semantics of XML documents.

4. Metadata CG: The RDF Model and Syntax provides a uniform and interoperable means to exchange the metadata between programs and across the Web. Furthermore, RDF provides a means for publishing both a human-readable and a machine-understandable definition of the property set itself.

COMMUNICATIONS MECHANISMS:

Working group members are expected to participate in an electronic mailing list, periodic teleconferences, and face-to-face meetings. The sole WG consensus venue is the mailing list.

Group Home Page:

In order to maintain shared context of the group and to provide access to the proceedings of the group, the Chair maintains a web page at http://www.w3.org/Signature.

Active participants are expected to have ready access to this page and be familiar with its contents.

Mailing List:

Participants must subscribe to and particiapte in the w3c-ietf-xmldsig@w3.org mailing list. The archive is http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig.

Teleconferences:

There are expected to be teleconferences held every few weeks at a time set by the Chair. The exact frequency of calls will be determined by working group consensus.

The Chair is responsible for producing an agenda at least 24 hours in advance of each call, posting it along with the call details to the mailing list, and causing minutes of the call to be posted promptly after the call.

Face to Face Meetings:

The working group will have a two day face to face meeting in or near September 1999 and meet at the July and November 1999 IETF meetings and may have additional physical meetings by consensus of the WG. Meeting notice, advance agenda, and posting of minutes shall follow W3C timing rules.

Communication with the Public:

This working group is public.

IETF / W3C PROCESS SYNCHRONIZATION:

WG documents will be dual published in both the IETF as Internet-Drafts or RFCs and in the W3C, via the web. Differing delays in the processes may cause skew in the appearance of a document in the two locations.

When a document is subject to a Last Call in both organizations (Working Group or IETF Last Call in the IETF, W3C Last Call or AC Review in the W3C) comments received in both venues must be considered and responded to. In effect, the Last Call period will be longer of the times allowed in the IETF and W3C.

The rough equivalence between document types in the IETF and W3C (and minimum length of time in that state) is as follows:

IETF -- W3C

Working Group Internet Draft -- Working Draft

Informational RFC -- Note

Last Call (4w) -- Last Call (4w)

Proposed Standard RFC(6m) -- Candidate Recomendation(4w), Proposed Recommendation(6w)

Draft Standard RFC(4m) -- Recommendation

Full Standard RFC -- Recommendation

If a document is substantively changed such that it recycles to a lower status in either venue, the corresponding document classification in the other venue should also change.

IETF Last Calls for joint WG documents which are on the IETF standards track will be 4 weeks per the Variance section of RFC 2026.

DECISON PROCEDURES AND APPEALS:

The working group itself will operate by consensus as provided in the IETF rules.

Appeals from decisions by the working group chair may be taken using either the W3C or the IETF appeals mechanisms. It is expected that these mechanisms will coordinate and differences are not anticipated. Nevertheless, if and when the appeal mechanisms of the W3C and IETF come to irreconcilable decisions, the group will thereby cease to be a working group of either the W3C or the IETF and may not take further official action under the procedures of either organization without explicit rechartering.

Should either the W3C or the IETF unilaterally terminate the Working Group status so far as that organization is concerned, the WG will continue to be a working group of the other organization.

IPR DISCLOSURE:

Working group members must disclose intellectual properties "that are reasonably and personally known" to be relevant to this WG in accordance with IETF (RFC2026) and W3C procedure; including notice and disclosure of such information to the WG, and the IETF Executive Director.

PARTICIPANTS:

Participation in the working group is open. Participation is expected to take a minimum of 15% of the participants time. The XML-DSig WG will be co-chaired by Donald Eastlake III (Motorola) and Jospeh Reagle (W3C). Each co-chair is expected to devote 20% of his time to this activity.

W3C Team

The XML-DSig Staff Contact will be Joseph Reagle and his staff contact duties are expected to take 40% of his time. The staff contact is partly responsible to coordinating dependencies and requirements from the W3C Director and other activities. Further details on the Staff Contact and Chair roles can be found in the W3C Guidebook for Working Group Chairs.

TIME TABLE:

Once established, the Working Group can decide to parallelize more tasks by forming subgroups. The Working Group can also decide to reschedule tasks that do not have to meet deadlines imposed by other groups. However, the schedule must fit into the total timeframe given below.

Also, document dates may not be rescheduled without notifying the W3C Domain leaders, the W3C director, and the IETF Area Director. Note that delay of deliverables can be a reason for the Working Group to be terminated.

The working group charter was updated in March 2000 as follows: (1) The duration of the working group has been extended by four months.

(2) The Signature Semantics document will not likey be produced -- its production was optional and at the discretion of the Chairs.

Goals and Milestones:

Jun 99

  

Submit first Requirements draft

Done

  

Meet in Oslo Norway at IETF

Jul 99

  

Submit first Syntax and Processing Draft

Aug 99

  

Requirements document to Last Call for Informational RFC / W3C Final Working Draft

Done

  

Meet during IETF in Washington DC

Nov 99

  

XML Signature Syntax and Processing document to Last Call as Proposed Standard / W3C Proposed Recommendation

Done

  

WG recharters if appropriate

Jan 00

  

Submit Internet-Draft of interoperability test cases

Jan 00

  

Requirements document approved as Informational RFC

Feb 00

  

Signature Semantics document to Last Call as Proposed Standard / W3C Proposed Recommendation

Mar 00

  

Interoperability Test Cases and Results document to Last Call as Informational RFC / W3C NOTE

Mar 00

  

Meet during IETF in Adelaide

Apr 00

  

Submit Signature Syntax and Processing document to IESG for consideration as a Draft Standard RFC / W3C Candidate Recommendation

May 00

  

Signature Syntax and Processing specification to W3C Propose Recommendation

Jul 00

  

Signature Syntax and Processing specification to W3C Recommendation

Jul 00

  

WG recharters if appropriate

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2807

 

XML-Signature Requirements

Current Meeting Report

IETF 48 XMLDSIG Minutes

These minutes cover the XMLDSIG Working Group meeting held on August 3, 2000, at 15:30 hours in Pittsburgh, PA, USA at the 48th IETF. They include comments from the briefing presenters.

Author: Walter Houser <houser@cpcug.org>
Tweaks: Joseph Reagle <reagle@w3.org> & Donald Eastlake 3rd
<Donald.Eastlake@motorola.com>

Working Group home page: http://www.w3.org/Signature/

Agenda [slides1] Donald Eastlake (DE) <<xmldsigAgenda.ppt>>

Agenda Bashing - Donald Eastlake said that a later time in the week was requested for the working group meeting so some interoperability testing could be done earlier in the week. John Boyer stated he would cover enveloped signatures during his presentation on canonicalization.

Documents' Status [slides2] Joseph Reagle (JR) <<xmldsig2.ppt>>

Joseph Reagle (JR) - We have two documents in process and one completely through the process. IESG and W3C have resolved their copyright language questions and the Requirements document, whose text was final long ago, is now out as RFC 2807. On the main Syntax and Processing document, IESG had changes on format and copyright. W3C asked for internationalization and canonicalization. We see these two as doable in the short term.

Canonicalization - John Boyer (JB) @[link]

The process of canonicalization requires that XML be consistent. For example, we chose to use double quote marks instead of single quote marks.

The most serious issue that remains is how to handle the xml:base tag.
The xml:base tag defines a base uri. Canonicalization requires the replacement of a URI with the content of the base document. Most XML parsers do not distinguish the resulting document content by it source - internal or external. There are also subtle changes that can occur with the incorporation of URI content in the document. It is likely that this will cause problems as signatures do not typically require further processing. I see two options: Do nothing or embed the xml:base attribute.

JR - Do you have a preferred solution?

JB - Each has its problems. Perhaps we should wait.

JR - My bias is to do nothing so we can move the document forward. What is the preference of the WG. If you don't know the issue or don't care, do not raise your hand. Twelve supported the Do Nothing option. None supported the embedding of attributes. JR noted for the record that the WG was not happy with either.

Donald Eastlake (DE) - Currently canonicalization makes start tags longer. What about adding a new line before the close angle bracket at the end of start tags to make the lines shorter and the canonicalized output more human readable.

JB - this may mess up indenting. It does not change meaning.

JR - We have been through last call; won't the implementers have a concern with a change?

Brian LaMacchia (BL) of Microsoft - I am against this change to the
draft. Canonicalized output is not viewer friendly. We have had
implementation problems with white space preservation under other
circumstances.

DE - My interest in this is not that strong.

JR - Let's leave this unchanged. Are there any other concerns?

JB - The enveloped transform is messed up. The inside transform is an xpath. The processing model calls for octets to be returning a node in the wrong node set. It isn't necessary to express __ . When the document comes with a signature element, the hash is created and then placed in the signature element, breaking the enveloped signature. A fragmentary URI [one ending with a # fragment specifier] would have a different transform model. We could push the problem off as a reference URI rather than do a down path transform. But when the URI is a fragment, how do we get from a location set to an octet stream?

JR - Where is the location set defined?

JB - XPointer. It's definition is similar to a node set but also includes points and/or ranges. When a range node includes portions of other nodes, we should throw an error as we are only interested in full nodes. Or we could change xml:path to xml:pointer.

JR - I can check on that [the reference is ambiguous]

JB - Those implementers that have already done the xml:path transform may see the xml:pointer transform as extra work.

JR - In the spec we discourage the use of fragment identifiers within the Reference URI and limit it to "" or "#fragment" (XPtr bare name). Are we arguing otherwise now?

JB we are indicating people should specify Reference URI="#xpointer(...)". The bare name XPointer indicates the signature property but not ___________ .

JR - So you believe we are being ambiguous and should specify this. What do the implementers say?

BL - After our powwow, we are concerned that we are pointing at a node stream when we don't know how we can canonicalize it. We rather that it be that whenever you reference something, you are ALWAYS returned a octet stream.

JB - Perfect. If we write the enveloped signature XPointer/Xpath expression and call the canonicalization method. We should assume that the URI process always returns back a byte stream. So the following would be required:

BL - Should we continue special processing when the referenced document may or may not have be previously canonicalized?

JR - That's a question for the XPointer people.

JB - We should put the canonical transform into the signature transform. But how do we know if the URI is capable of canonicalization?

BL - We need a _____ step.

Phil Hallam-Baker (PHB) - What if the XML is not well formed?

JB - Good point. We should assume that a reference URI returns an octet stream. But we do not assume that the stream is not itself canonicalized. To have interoperable signatures, a canonical transform should be added. For example, see section 2.2 Extended Example Object Signature Properties. It will now have to look like:

<Reference URI="#AMadeUpTimeStamp"
Type="http://www.w3.org/2000/07/xmldsig#SignatureProperty">
<Transforms>
<Transform
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/07/xmldsig#sha1"/>
<DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>

The fragmentary URI is typically a location set. It may be well formed. It may not. Different XPath engines may yield different results.

JR - We should include this in the definition of Enveloped Signature. Are we going to assume every step is an octet stream?

JB - If we have two successive transforms, we can treat it as if it were one. The enveloped signature will rewrite a reference URI and we will add a transform for canonicalization.

Interoperability

DE - The next topic is interoperability testing.

BL - We held interoperability tests this past week.

Petteri Stenius (PS) - The test results have been good, despite some minor ambiguities. Our implementation does interoperate [with IBM's] on all current features except Xpath transforms and its new features. Those features are coming up. We have enveloped signatures per the current specification, which is the most important.

BL - We have tested with three implementations using three different XML parsers and two and a half different crypto systems. I have enveloping signatures working. We are using both RSA and DSA key values. White space is inside the tags is currently being removed by my XML parser, breaking most signatures, but this will be fixed shortly.

JR - Thank you. We appreciate this work.

?Baache - Was the parser with the white space bug shipped?

JR - They fixed it first. We need the working group's ideas about auto responders? Next is Ed Simon (ES) from Entrust to talk about earlier interoperability test findings.

ES - Here are the results from the May-June interoperability tests for REMTEC [now Done Information, Inc.] and IBM. This testing is important as the IETF requires two interoperable implementations before an RFC becomes a ["Draft" or higher level] standard. Note the sample code to build a simple auto responder. I also want you to see the Multimedia's report of their interoperability tests for their SMIL player. The first is a table of test results for XML schema by vendor. The second table shows results for test cases by vendor. It appears that vendors can enter their own test results. We should consider a similar set of tables.

JR - No comments? Thanks Ed. We have nearly closed our last call save for a few small issues I would like to cover today. First, Ed Simon asked that we require style sheet root nodes. Within a namespace, one could pick any element. But we want people to pick the root elements only. We should change the text to read _______

Syntax Issues from the list [slides3] Joseph Reagle (JR) <<xmldsig-issues.ppt>>

ES - Hard wiring the schema will enable validation.

JB - Previously we decided to use named parameters in our namespace. We should keep XSLT wrapped by a dsig parameter tag.

JR - My recollection was that this was a placeholder.

JB - I am happy with your proposed prose. But I want the XSLT wrapper around the style sheet reference.

Decision: Retain XSLT element type in DSig name space.

JR - Comments? Hearing none, the next question is whether the X.509 keyinfo element types should be removed? Brian Lamacchia (BL) has noted we are not doing this very well. It is not in our charter and should be worked out by other working groups. I see two options: clean up these specifications or drop them.

BL - If you want multiple certificates, you can use the X509 data clause. We propose the use of multiple certificate clauses, like the PK bag of certificates.

Russ Housely (RH) - Are we allowing attributes in the bag?

BL - That would require different decoding code. Would the PKIX WG want to add yet another type? This sort of creeping complexity is part of the reason why I raised this issue in the first place. For any decision we make here, there will be questions as we aren't PKIX.

PHB - Let's focus on what's out there. There is a lot of PKIX and X509 deployed, but attribute certificates and TSP tokens are not common.

RH - CMS [Cryptographic Message Syntax, RFC 2630] allows both certificate types with separate tags.

BL - This is an issue for the list.

Steve Farrell - Just use Public Key certificates.

DE - I will draft the language for the list to comment and decide.

Decision: Donald Eastlake will propose text that is sufficiently general so as not to be ambiguous, otherwise we still have the option of removing this section.

JR - We should be more specific about our definition of XML signature type for the purpose of conformance requirements. For example, Gregor said the term signature properties should be singular as the plural form was confusing to non-native English speakers.

JB - If we change that, we should review the entire document for similar instances.

JR - The term has no real significance.

DE - The signature properties does not have to be inside an Object. If we make this change, then <signature property> could be used outside of an Object. As you know, that's something I wanted to do anyway.

JR - Given the maturity/status of the document, we should keep it in unless there's consensus to change. Are there any other comments?

Decision: Retain SignatureProperties element type in DSig name space.

JR - OK. The next comment was that the DTD example was not realistic. The example, was a generic illustration and would need modification before application.

JR - The final comment was one I had. I am concerned that a style sheet could be changed to hide content while not invalidating the signature.

JB - Should we change the language from SHOULD to MUST with respect to style sheets? Signing the XML and the style sheet should be enough. We do not need to sign the rendering.

ES - The scenario is valid. We should mention the possibility of it happening. But other equally plausible scenarios suggest that a requirement would not be appropriate.

Dave Solo - I echo Ed Simon. MUST would mandate behavior that is unimplementable.

JR - Fine, let's take a straw vote. If you don't know the issue or don't care, do not raise your hand. How many in the WG say we should put this in lower case? [Eleven raised their hands]. [None indicated the specification should stay the same]. [One asked for a stronger position].

Decision: convert directive in Section 8 to lower case as they don't relate to the conformance of the syntax or signature application.

DE - Other topics?

BL We are planning an informal discussion of XML encryption at Crypto 2000, Thursday, August 124 at 1:30 in the Anacapa Formal Lounge. The conference is at UC Santa Barbara. Barbara Fox is coordinating the event. For more on Crypto 2000 see http://www-cse.ucsd.edu/users/mihir/crypto2k.html

DE - Given the nearness to completion, I suggest we hold two or three weekly teleconferences to nail down the final details. We've held them on Thursdays at 1:30 pm Eastern time which seems to be the best time for overall convenience. The issues will be X509 and canonicalization.

JR - Signature is waiting for Canonicalization. If we can finish canonicalization within a 2-3 weeks, I'd estimate 2-4 weeks of process before it reaches Candidate Recommendation in the W3C. We can have the Signature specification cued up right behind that. Canonicalization is to be issued as an Informational RFC in the IETF.

Slides

Agenda
Syntax Issues from the List
Document Status