XML-Signature

Irvine Notes [text]

Editor: Joseph Reagle reagle@w3.org
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.

• Boyer 1990902.

Attendance

Monday, August 30

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

• Enveloped Internal Content
  • Signature element is the root element. Doesn't need to be supported directly, more elegant ways to do things.
• Direct Envelopment
  • Everyone's syntax does this, no worries mate.
• Unenveloped Indirect Signature
  • Application element is the root element.
  • Encrypted hash is over the actual application element. (Want it for symmetry in the enveloped case.) We need exclusion in the Indirect since the signature is a child of the root element.
  • Conversation on when you exclude the signature, how you worry about signing signatures.
• Unenveloped Direct Signature
  • Not a lot of support, but people think having the encoded version is not hard. Don't need it just to avoid another level of hashing. We do need to sign the original content, but what about the original content plus other stuff?
• Signing External Resources (Detached Signatures)
  • Signing Partial XML Documents

    Boyer shows and argues that July XPointers (or more specifically XPath) seemingly offers the filter/select/exclude/extract capabilities we need. When asked how many people would expect to implement XPointers shortly, only one person raised their hand. However, people do seem comfortable in using a subset of Xpointer. Or can we just use URIs to do what we need to do?  URI's aren't sufficient for selection in the manifest, but perhaps they are in the core signature. (Also, the WG seems happy with calling "exclude" "extract" instead. (see Boyer 1990902:2)

    Norman: can we do this in a simpler way, with a dsig:exclude attribute? Which requirements does Xptr meet that can not be met through an easier method? Group: The insertion of dsig:exclude is problematic when you have multiple signatures, how does which signature know which dsig:exclude belongs to it. Boyer also asserts this adds security problems in that it requires modifications to the signed document. (see Boyer 1990902:6)

    Boyer raises a point that if the canonicalizer strips out the DTDs, you won't know which attributes are IDs anymore.

    Norman: how do I seen pieces of documents that were not structured with many names? With a dsig:target element one can add to other documents to point out what it is you are signing for poorly structured documents. But the removal of these things happen before or after dsig (this affects the nesting) -- just like in dsig:exclude. Reagle suggests you could use XPtr as described, or take the document apply XSLT to effect the transformation and sign both of them. (still  open)

    dsig one-pass-processing: get feedback to people on implementation side as to whether this is useful. (not clear that there is additional utility.)

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

• Keyinfo compromise is to put the keyinfo at the top level outside the scope of the signatures, and then put some added key information in the signature for binding. This is not necessarily a duplication of the keyinfo, since the application may wish to bind different information into the signature.
• Putting keyinfo outside the scope of the signature was the predominant application requirement. 97.44% of the cases according to David Solo.
• Hayes -- felt that there are many cases where keyinfo should be signed. We need to make it clear and explicit that key information is allowed within the scope of the signature when the application needs to put it there.

Third Slide -- General Structure.

• All "sigs" have been changed to "signature".

Fourth Slide -- signedinfo

• What are signedattributes? Could be signing time, key information discussed above,
• Where does the signedobjectdata refer to an object that has been already signed.
• Anderson wants signedattributes in order to simplify creation of the signature element by security tokens in such a way that the signedattributes are inserted automatically by the token device. That way they have the security associated with the security and tamper resistance of the token device, and don't depend on the host systems security or on the integrity of the signer herself.  [Milt wasn't there for the second day, where we moved to removing special attribute blocks, so Milt should weigh in on David's latest proposal -- Reagle.]

Fifth Slide -- signedobjectdata

• Boyer: does this support enveloped? Response: signedobjectdata always refers to an object, but the object may be within the scope of the signature element. There is always indirection.
• References to signed objects can be to an object within signature, to an object within the same document, or to an object in another document.
• Transformations include c14n and encoding. It may also include compression.
• Change signedobjectdata to signedobjectreference?
• May use a default c14n and hashing algorithm or inherit the ones from the computation over signedinfo.

Sixth Slide -- algorithms

• Currently there is no definition of the Identity c14n. This is not c14n plus fixing up CRLF and charset.
• Null and Identity c14n are specific to digsig and are for the point to point application. The case of unique production of a canonicalized output of the DOM is in the "more extensive" c14n algorithm, as is the Syntax WG's proposal based on InfoSet.
• Question about whether hash and signature algorithm should be combined and whether the dual signature should be combined in a single type. The parties would need to have the combined hash/sig algorithms and the combination of signing capabilities. When a combination of signatures is used, then the signaturevalue is sent to the appropriate combined algorithm. It simplifies processing to not have the discrete combinations of algorithms visible at the core syntax level.

Seventh Slide -- keyinfo types

• Hayes: multiple keys are required for multiple signatures. Then we have multiple instances of certs in keyinfo.

Eighth Slide -- Eye test and example

Ninth Slide -- Open Issues

• Do we always go forward with signedobjectdata being a reference? Advantage is that signature can always be calculated over signedinfo and doesn't matter whether the object is inline or outside. Canonicalization of singed info may have to take into account that the reference may be a URI or an ID depending on whether the referenced object is external or internal.
• Is there only one or more than one instance of signedobjectdata in signedinfo?
• attributedata and keyinfodata are candidates for promotion to the next level and the corresponding wrappers might be eliminated.?
• Long discussion regarding whether it was necessary for the signature core to chase down and verify the hash of the object referenced?
• Is it possible to have a manifest where the URIs are not signed, therefore allowing to move the referenced objects.

[Reagle's addition summary of this discussion.]

• solo: the benefit of the indirection is: 
  1. switching: could refer (depending on how you reference it) an object that is external or internal, and signature wouldn't break. reagle: I dispute this, if they have different URIs they are different things, unless there is a statement of identity.
  2. transformations: keeping it external means one can have one single c14n over the signedinfo, that are indistinct of the content transformations (no nesting/multiple-c14n)
• Fox: will XML content be too small sometimes (particularly if signature is also over siginfo, pretty static information) in order to permit a dictionary attack, do we need padding and salt? Solo: jokes XML is never small. Should investigate.

[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

• Peter Lipp's object location proposal on the list is accepted.

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/>
  <man-attributes/>
</dsig:manifest>

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)

• Requirements (Reagle). CP
• Core Syntax (Fox, Solo, Brown). CP, ST
• Manifest & Package Application Defn. (Vincent). ST to be integrated into other docs.
• Algorithm Definitions. (Bartel) CP, ST
• Scenarios (Boyer) to be integrated into other docs.
• Implementation (Simon) CP. will start playing with implementations as soon as feasible, might propose how to do interop.

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.