W3C Architecture DomainTechnology and Society

XML-DSig'99: The W3C Signed-XML Workshop

Chair Summary

My comments on the workshop are below. The purpose of this document is to summarize the salient aspects and results of the workshop as a supplement to the notes. They are my personal comments/thoughts and do not represent an exposition of policy for future work. However, at times I do make representations of perceived consensus that could have an impact on future work. I try to represent those -- and all -- issues as objectively as possible, comments (to the list c/o me) are certainly welcome if you feel I have not captured those issues accurately.

reagle@w3.org 19990425


It is very clear that there are numerous issues of potential dependency with other XML activities -- I counted 8. I suspect the task at hand will be to identify those dependencies in both communities and negotiate their resolution. It is not necessary that signed-XML wait for every single one of those activities. Rather expectations need to be set and shared, and we may -- for instance -- come up with our own simple "package" format prior to the real thing. In this instance a decision was made because of expediency (acceptable), not because of ignorance (unacceptable).

Additionally, deviations from pre-existing crypto/signature practices should be avoided, and we should ensure we have the proper involvement and review from those who have experience/working-knowledge. This rigor should be further enforced by charter requirements that any feature requires two independent interoperable implementations. For instance, I'm quite willing to buy warnings against sender based optional policies based on CMS experience. (dsig:eval might fall into this category too?)

Consequently, there seems to be a clear consensus that this should be a child of the W3C and IETF, but I strongly second Solo's argument that let's not involve the worst of both institutions in this one group. Schiller's proposed  joint working group should have a default process, and the joint nature of this activity argues for an explicit and rigorous charter.


We achieved fuzzy consensus on a couple of issues, but it also raised a couple of new ones, which is understandable. Its hard to come to consensus when you are first thrashing through the issue and I suspect I wouldn't be satisfied until I see some alternative proposals and a chance to sit around a table or in front of a white board. The three quickie issues I came to the workshop with are:

  1. Data model: people said yes.
  2. Syntax for expressing data model: a fair amount of RDF converts, but people want to see more discussion/work.
  3. Signature semantics: KISS. (Do one thing and do it well. Muddying the water never helps you see to the bottom of the issue any faster.)

The more complex ones are ...

Content semantics

signed-XML applications are ignorant of any content semantics outside of the manifest, including XML. Entities are not expanded, links are not chased. (I think even if we wanted to get into this, not doing it now doesn't hurt anything.)
My own opinion of what this means is that:

  1. To Use Richard's terminology, the value of any thing on the end of a locator in the manifest (or value in a package) is opaque to signed XML.
  2. To use RDF terminology, everything in a manifest is a literal. signed-XML will use a data model (and maybe even some RDF syntax) so its semantics will be expressed, but signed-XML will make no RDF inferences itself -- though people are certainly welcome to do this in their applications. So the requirement is that signed-XML syntax express data model semantics, but that we do not require applications to make inferences.

    On this note, it's useful to think of a couple of things over which one specifies (and people get confused)

  1. Syntax - strings/bits
  2. Semantics - meaning
  3. Syntax/Semantic defense - requirements to ignore or repulse intrusion on your own syntax/semantic.
  4. State machine (of a protocol.)
  5. APIs
  6. Default values (protocol suites)
  7. Application behavior, requirements, or constraints.


  1. This is not a heavy I18N group and no one was of a super strong opinion.
  2. In general, doing the character code canonicalization at that level (e+accent) could be very expensive, particularly on smart cards.
  3. However, the requirement we would like to impose on XML/Unicode is that applications NOT arbitrarily change the information. I guess you can do this by arguing that (1) all applications canonicalize on the character code issue (which seems heavy) or that applications not be permitted to translate from one to the other as they encounter a document and pass it on. (Seems similar to those HTML editors that will fix your code, leave your code alone, or break it while they make it pretty. Just one consistent behavior is best!)

So to my mind that says, whichever way one gets "invariance" just do it consistently, and pursue the light-weight most easily enforceable path.

Also, the three depth levels of mandatory canonicalization for conformant signed-XML applications seem to be:

  1. None (byte stream).
  2. Character encoding in XML. (Getting it right at the UTF-* level, and the issue above (I think we were slightly confused at this level, I was)
  3. XML syntactical level (Dealing with white-space, caps, etc. level type issues.) I expect 2 should be a part of 3, but sounds as if it may not be.

Any semantics above that would be optional/extensible and normalization of those semantics should be done by the application that owns them before passing it on to signed-XML apps.

Requirements Document and Example Applications

Many people have voiced a need for a requirements document (including rat-holes to avoid). As I specified in the proposed charter, I'd still like to have a test application or two in mind to help us focus. After we have a draft that meets the basic requirements (I would like to have a requirements document) that is synched with CMS and has a data model, it'd be nice if people started (end of summer) coding on those test applications.


The "hollow/phyric" consensus is that signed-XML should be able to support multiple ways of representing crypto semantics, including PKCS blobs. However, there is still a fair amount of confusion -- which I would like to see addressed with some alternative example proposals. Two outstanding issues that we still have to get a grip on are:

  1. There is a question as to whether we are discussing a XML signature syntax for signing arbitrary content/resources, or if we are talking about ways of signing XML, which need not be XML! Now, we have consensus that we don't just want to use S/MIME because we want the content data to continue to be available to non-signature-XML applications. We even want some of the signature semantics to be available to XML applications, but  will people implement crypto applications on top of XML or use existing infrastructure? There seems to be two schools of thought, which I hope can be remedied when we look at the architectural model of how people plan to implement this. (The name of the workshop should not be used to argue one way or the other, I just moved the sig before XML so as not to conflict with the XML-Special-Interest-Group!)
  2. If signed-XML expresses crypto information that is redundant with information that is in a blob, which is normative, what if they conflict?

Also, I hope that we use the XML-namespace facility to its fullest extend. While Richard's general <algorithm ...> <parameter ...> * </algorithm ...> </parameter ...> is nice and permits extensibility, I wonder if that extensibility could be addressed through name-spaces (to at least define "crypto suites.")

Handwritten Signatures

This issue continues to be contentious on the list. Obviously I don't think we need to spend time specifying how to do this, but I do think it is an interesting test case of generality. I'd like to see an example proposal of how to express such a signature as a variant of Richard's draft, and then see argument on that example.


The interesting result is a requirement that a signed form, still be recognizable as a form by XML-form applications. That XML signatures should not supercede the type of thing it signs.

Action Items

  1. CMS people and Richard go through the draft and synch up with CMS.
  2. RDF people and Richard, come up with an explicit data model.
  3. Reagle and Eastlake, come up with a joint charter proposal.