IETF W3C   XML-Signature

Irvine Notes [text]

Editor: Joseph Reagle
Authors: Milt Anderson, Daniel Woycke,  Joseph Reagle

August 30-31 1999 Face to Face Meeting

The following minutes capture points of discussion, consideration, and action items resulting from the face-to-face meetings. Participants should send the editor corrections; others on the mailing list should suggest alternatives or document opposition to views/consensus achieved in this meeting by 990910. Those issues in bold are ones that should still be investigated.

The following emails from WG members express comments/corrections on the meeting minutes that have been reflected in these minutes.


Name Company
Joseph Reagle W3C
John Boyer UWI
Mark Bartel JetForm
Don Eastlake IBM
Milton Anderson FSTC
Shinsuke Honjo Hitachi
Ed Simon Entrust
Terry Hayes Netscape
Todd Vincent GSU
David Solo Citigroup
Barb Fox Microsoft
Rohit Khare UCI
Peter Norman FactPoint
Stephen Keung CIS, SC
Roberta D'Amico CSELT
Daniel W. Woycke MITRE

Monday, August 30

0900-1030 Scenarios , John Boyer (Notes: Reagle)

1015-1030 Data Model, Joseph Reagle (Notes: Daniel Woycke)

Benefit of Data Model is to view how the assertions, elements and structures fit together

Manifest is a series of assertions about the existence and "trust" of information referenced by manifest

Package asserts all references are to the same information whether coded into a URI or inline, etc.

Is verification of all assertions necessary? This is not part of the working groups area

By looking at the data model once can view the relationships and bound the problem…

The WG is to deal with the signature and its relation to its elements and objects and reference

The data model needs to be updated to match the current spec.

[Reagle summary:]

Reviews his proposed data model, explains:

  1. The goal is to make as much of the relationships between the elements in our signature as explicit as possible, such that other non-dsig applications could still derive interesting information out of a signature, even if they don't care about signature validity.

1030-1200 Syntax and Processing Model (Notes: Milt Anderson and Reagle)

C14n will be dealt with this afternoon.

Notes for David Solo ---

Don plus discussion -- Distinguish between three levels.

  1. Core signature syntax -- the syntax for creating a signature over a set of bytes within the scope of the signature
  2. Signed objects syntax -- how you sign referred to and signed objects.
  3. Application -- trust is in the application layer.

First Slide -- XML Syntax and Processing


Second Slide -- General Issues

Third Slide -- General Structure.

Fourth Slide -- signedinfo

Fifth Slide -- signedobjectdata

Sixth Slide -- algorithms

Seventh Slide -- keyinfo types

Eighth Slide -- Eye test and example

Ninth Slide -- Open Issues

[Reagle's addition summary of this discussion.]

[Reagle summary of Open Issues from Syntax:]

[The resolution to many of these issues will be reflected in the next draft Solo will send since we went back and forth on some of this stuff quite a lot.]

  1. signature attributes: if we have signature semantics and include it in <signature-attributes> they must be relevant to the cryptographic signature, nothing about the signed object itself. Semantics about the object should be in maninest attributes (or reagle argues in a new signed object see tomorrow's discussion where both types of attributes are removed.)
  2. signed object ref (data), should we limit it to one? Go with one with caveats that it must make sense in a DLG (can someone else sign your signature attributes?).
  3. algorithms (crypto/hash): mandatory, recommended, optional
  4. c14n, syntax WG, null and simple/minimal c14n
  5. exclusion/xptr. the dsig:exclude declaration, which signature does it belong to?
    1. <X dsig:exclude> ...</X> everything is hashed and signed, now someone adds a
    2. <Y dsig:exclude> ...</Y> it will get rendered differently, but not break the signature because other applications won't know the dsig:exclude semantic.

    John, in XFDL had something that did it differently, but not any easier. consensus that we should bite the bullet and use XPtr in a limited way as possible. Need to check if XPtr returns the whole resource and a view, or a different resource (check the DOM that is returned.) Are we better off use XML with XPtr to select or XML with XSLT? Boyer: they are supposed to be converging with XSLT -> XPtr -> XPath as ordered in terms of complexity.

    Consensus. The reference from SignedInfo will just be a URI (without fragmentID see Boyer 1990902:1.) This can then point to a manifest or package which can use Xlink/Xptr/Xpath as appropriate. This means you don't have to worry about Xptr in the core signature syntax.

    Question: Are things like c14n, encoding, XSLT, etc., ordered or non-ordered? <transformations> is an ordered list.

  6. Which crypto algorithms do we choose and mandatory to implements and defaults? Also need to include security requirement such as avoiding Phillip's downgrade attack mentioned on the list.

    Need to references specs, define algorithm, take from Brown.

    hash: SHA-1 (mandatory), MD5 (recommended) AES-H (keep an eye out)

    MAC: HMAC-SHA1 (recommended), HMAC-MD5 (optional)

    PK Signature: DSS=DSA with SHA-1 (mandatory); RSA with SHA-1 (recommended); RSA with MD-5 (optional); ECDSA (coming along)

    Key Agreement: DH (optional) as defined/specified in the keyinfo block.

  7. Do you do combined signature types, or have two different signatures? reagle: if they are two different signatures, can make statements about each. Solo: could do it either way. Discussion: why you might choose one or the other. Solo: it'll be clearer when we go to implement.
  8. Definition: encoding is arbitrary ways to represent a set of characters; c14n is one particular representation of multiple permissible representations.
    1. Null (mandatory)
    2. Minimal (mandatory) CR/LF, encoding, UTFF-8,
    3. Minimal':  white space handling?
    4. DOM (optional)
    5. SyntaxC14N (optional)

    Boyer: we use the "<?" at the beginning of the document to determine the encoding, but what if we only have a part of an XML document? Reagle: good question!

    Action item: Ed Simon, find someone to do minimal c14n.  Milt will propose whitespace handling.

    Action item: Don poke on a specification of DOM-c14n (right now it is wrapped in DOM-HASH. (Boyer, would DOM-c14n do attribute sorts and white space handling?)

Tuesday, August 31

Regrets: Barb Fox, Milt Anderson,

900-1015 Wrap Up of Syntax

1030-11 Requirements

  1. add security requirements.
  2. Don and ? has a few comments will send to list.

1100-1200 Signature Semantics (Notes: Reagle)

Rohit: point of clarity: a signature on a manifest may very well validate, while the manifest  (assertions) do not -- these are distinct things.

Manifest is a collection of things, you need not validate.

Package is a collection of things, plus assertion of identity between them.

Manifest and Package. Do we define attributes given a reference stating the references should be fetched and validated? Or is it part of the definition?

Reagle: argues against permitting external semantics to be introduced into our definition through ambiguous manifest-attributes (Whether those references are confirmed is up to the application.) Others can define their own threshold XML application <someoneelse:threshold>...</threshold> or make a statement about the dsig:manifest using something like RDF.

First, a non-dsig application isn't going to know what the relationship between manifest and man-attributes is, have to read the spec.

<dsig:manifest id="1">
  <signed objectref/>
  <signed object/>

However, if man-attributes is merely a signed-object with defined policy assertions that reference "1", relationships are much more exlplicit.

Second, lets avoid things like:

<dsig:attribute type="CDATA" and value="CDATA"/>

Make people introduce a new qualified namespace element with clearly defined semantics, or make a statement about an existing resource.

Solo and consensus.: reconsideration on signedattributes, signedattributes are merely a signedobject, referenced by the signedobject reference. the signedobjectreference has a t ype describing if its a manifest, package, signedattributes. Same with manifest attributes but at a lower level.

Todd: we need a good way of binding the XML, style sheets, schemas, and DTDs. Group members may work on a paper addressing the legal issues of this and potential package requirements but not critical path.

1030-1100 Scheduling and Allocating future documents and con calls

Calls now on Thursday on Noon.

CP (critical path), ST (standards track)

1300-1400 Marketing and Promotion

Once we have something we are comfortable with, we need to get on XML sites and get people talking on XML-dev. Might have a marketing plan.