2.6.8 XML Digital Signatures (xmldsig)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 09-Jun-99

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@nortel.ca>

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:

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

This effort is equally and strongly dependent on XML expertise and coordination, which is in the World Wide Web Consortium (W3C), and Internet cryptographic expertise and coordination, which is in the 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.

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. At least all XML-DSig applications must be able to sign 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 with a non-standard-track document. 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:

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

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

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

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

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

- Trust engines

- Public key infrastructure

- Trust management systems

- XML schemas for certificates

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.

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

o XML Syntax 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.

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

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

o RDF: The RDF 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:

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.

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.

The working group will have a two day face to face meeting in 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.

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 Team Last Call or AC Review in the W3C) comments received in both venues must be considered and responded to. In effect, this postpones the end of the Last Call that would have ended sooner until the end of the Last Call is the other organization.

The rough equivalence between document types in the IETF and W3C is as follows:

IETF W3C Informational RFC Note Working Group Internet Draft Working Draft Working Group Informational RFC Working Draft Proposed Standard RFC Proposed Recommendation Draft Standard RFC Recommendation Full Standard RFC Recommendation

Recycling of a document in grade in either venue will cause a corresponding document classification in the other venue.

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 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 any intellectual property rights brought into this WG by following both IETF and W3C procedure; that is, at a minimum, by email to (patent-issues@w3.org) and the IETF Executive Director (iesg-secretary@ietf.org)

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.

Goals and Milestones:

Jun 99

  

Submit first Requirements draft

Jul 99

  

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

Sep 99

  

Hold two day Interim Meeting

Oct 99

  

Submit Internet-Draft of interoperability test cases

Nov 99

  

Meet during IETF in Washington DC

Nov 99

  

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

Dec 99

  

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

Dec 99

  

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

Dec 99

  

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

Jan 00

  

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

Jan 00

  

Close down WG

Internet-Drafts:

No Request For Comments

Current Meeting Report

[1]XML Digital Signatures WG Meeting 99/07/12-13

All the slides presented by any presenter are available from the WG's website - only relevant discussion is noted here.

Resulting Action Items:

_________________________________________________________________
Date: July 12 1999

Notes Author: Peter Lipp (tweaked and HTMLized by Reagle)

1. AGENDA BASHING (5M)

No discussion.

2. JOINT WORKING GROUP STATUS (10M)

This was the first meeting of the first joint W3C/IETF WG. Joseph Reagle (JR) and Don Eastlake (DE) presented the "history" of this WG. From the process point of view, regular conference calls are planned besides meetings at the IETF's and someplace in September.

Paul Hoffman (PH): are those Conference and Meetings calls design or process meetings?

DE: Conf.Calls for status and ad-hoc technical discussions, face to face for substantial work. But WG can decide.

3. REQUIREMENTS (45M)

Joseph presents requirements document.

Mary-Ellen Zurko: what is meant by validity of a signature: valid now or court-validity.

David Solo (DS): this is external to the draft.

Semantics: only simple meaning - no trust semantics. Extensibility.

Bob Blakeley: is concerned about the semantics extension mechanism. Those have to be protected too.

JR: reason to push semantics out of scope: let other people define semantics.

Paul Lambert (PL): concurs, push semantics off even further, concentrate on crypto-validity and make sure we do this all the way correctly.

No specification of serialization or canonicalization:

DE: necessary for interoperability. Need not too many of them, but not exactly one at least. Extensibility necessary and useful.

Eric Rescorla (ER): options confuse security semantics.

DE: canonicalizers can also remove information. NULL-canonicalizer will also be useful.

DS: 2 places for canonicalization: canonicalization of the structure we create, canonicalization of the resources. Different.

Canonicalization ensures:
(a) given valid XML-document - produce single strong-representation
(b) defer unique string-encoding for semantic value represenation.

Bob Blakeley: Canonicalization algorithm must not be able to manipulate content. NULL is fine, others might not be. Constraints required - guidelines.

ER: Canonicalization algorithm must be included into the signature.

XLink: JR: XPointer provides for alot of ambiguity.

PH: be explicit about if the thing some XLink points to is included within the signature or not. Ambiguity!

ER: Iffy proposition to allow different Canonicalization-Algorithms with different security properties. Users don't see the difference - see key-symbol in Netscape for SSL. Programmers make mistakes like that too.

DS: suggest to profile XML for use in browser to restricted choices but not generically. Application problem.

PH: profile XLink/XPointer is fine, XPointer itself too generic Implementation Philosophy

JR: do you want OID's? DS: unambiguous way to say what we mean (either URN or OID)

Ryan Boats ATT (sp?): Michael Meally, NSI has done some work on URN's for OID's

Crypto: Specify a few mandatory algorithms for interoperability

PL: why have key exchanges and push of encryption? Controversial requirements

Richard Brown (RB): no redefinition of these schemes. If people use DH-credentials they shall be able to use it (also for other symmetric stuff)

PL: different properties for different algorithms. This is a slippery slope, maybe better move into separate documents.

DE: gets nervous by hearing "management" or "negotiation". Just by allowing secret keys - maybe call it something else than a signature.

RB: we need to provide people with a solution, like UOTP has symmetric stuff in the first proposal.

PL: the diversion of validity and trust is not clear yet. Be careful! Discussion about inconsistencies of info within a BLOB (such as CMS) within an XML-signature and info within the XML-structure deferred until a better understanding is aquired.

Christopher Smithies: points out importance of packaging all necessary info (intention, time, id, signature) which is what products by Penop do. Worth while replicating some of that info in the outside structure. Coordination PH points out the importance of internationalization issues and coordination with the internationalization WG

4. SIGNATURE SYNTAX (45M)

JR: Brown-Draft not a product of the WG, but possible to get there. RB presents his proposal.

Bob Smart: is there an option to put in the public key or only a reference to it using the DN?

RB: Not bound to that. Originator info might offer different ways. One common way needed.

Denis Pinkas: can attribute certificates be included?

RB: could be accomodated within the credentials within the originator information section.

Denis Pinkas: no provision to support non-repudiation (e.g. include timestamp)

RB: not part of spec because not necessarily part of signature process.

JR: we don't support non-repudiation

DS: we neither support nor not support it.

Stefek Zaba: incorporation by reference - what if hash of resource does not verify?

RB: application level problem, signature verifier verifies only manifest signature

SZ: this needs to go into the draft Presentation of an evolutionary, non-counter-proposal by DS (co-edited with Barb Fox) No attributes within that proposal.

DE: how to stop people from putting attributes within the resources?

DS: we don't want to stop them. An attribute is just a resource - uniform syntax.

[Reagle: later, we may wish to create restrictions as to the type of "invasive" semantics people can introduce using namespaces.]

ER: what would you specify from the hash standpoint?

DE: calculation of the hash of the manifest. Calc of hash of resource is resource-dependent. Signature validator logic never verifies that

PL: we need to touch on semantics. Multiple signatures could be interpreted in different ways. Must be described well to know what it means.

5. FIRST CONSIDERATION OF CONFERENCE CALLS AND SEPTEMBER FACE TO FACE MEETING (5M)

DS: potential partitioning of the problem-space might influence that decision.

DE: suggest a meeting on the west coast for geographic diversity.

Meeting adjourned.
_________________________________________________________________

Date: July 13th 1999

Notes Author: Peter Lipp (tweaked and HTMLized by Reagle)

Syntax

DS presents a slide sketching a more formal version of an alternative syntax proposal. Open problems are


Proposal will be summarized and sent to the list.

Q: David Burdette: should there be defaults like a default hash or canonicalizer for all ressources to avoid repetition?

ER: saving a few bytes not worth it

Chr. Smithies: how to make clear what was within the original document and what has been added during the signature process

DE: Semantics could go into the attributes

JR: no, semantics of signatures are statements and should go into the resources.

[Reagle hindsight clarification: properties of the signature of the signature itself can be considered properties, but the manifest attributes are a resource themself.]

Michael Myers: should the keyinfo be a subsection of the document or separate document(s)

DS: not sorted out yet

ER: is one-pass processing planned? Would be a nice feature

DS: not sorted out yet RB points out that removing attributes from this proposal we would end up with something quite similar to the current specification

DE: open question if users should be able to insert arbitrary attributes

Don Smith: reminds us of things we went through in PKIX; lets have something where people can put in things otherwise those will come up later anyway. Poll: no oponents.

Canonicalization

Joseph presents draft of W3C-XML group (not publicly available at this time).

Comments to the list.

Logistics

Roughly 16 people would come to a September meeting. Offers available from Micrsoft and UC-Irvine. Suggestion Aug 30/31.

Conference Calls every other week, starting in week 30.
RB points out that there is a separate comment document, input on this sought.

References

Slides

Agenda
XML-DSIG’99