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:
The more complex ones are ...
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:
On this note, it's useful to think of a couple of things over which one specifies (and people get confused)
- Syntax - strings/bits
- Semantics - meaning
- Syntax/Semantic defense - requirements to ignore or repulse intrusion on your own syntax/semantic.
- State machine (of a protocol.)
- APIs
- Default values (protocol suites)
- Application behavior, requirements, or constraints.
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:
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.
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:
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.")
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.