- From: John Boyer <jboyer@uwi.com>
- Date: Thu, 29 Jul 1999 12:29:54 -0700
- To: "Mark Bartel" <mbartel@thistle.ca>, <w3c-ietf-xmldsig@w3.org>
John, My basic point is that the capabilities that you ask for (except for omitting subelements) can be built on top of the current specification. The ordering issue isn't a security hole, it is something we have chosen not to address in this layer. Since most applications won't care about verifying order, I think this is an entirely appropriate choice. <John> It seems preposterous to say that most applications will not care about the order of the elements in a conversation about digital signatures. For starters, it is wrong on a theoretical level. Like it or not, the XML 1.0 spec does not forbid extensions languages from deriving meaning based on the order in which the elements appear. If you want that, use RDF. Second, it is wrong on a technical level. Even if you deal solely with Third, it's wrong on a practical level, namely that you have not </John> I must admit that I had misunderstood what you meant by omitting elements. You are suggesting that we provide some method of saying "sign this element, except for these subelements". It seems to me that this significantly confuses the meaning of "this element is signed", violates the basic web philosophy of modularity (2.8 in the requirements), and considerably complicates processing of signatures. But perhaps that's just because in my experience (forms, workflow, and pki applications) I don't see a need for it. <John> You mention experience with forms, but what we're talking about is signing forms. Do you have experience with that? Firstly, the ability to omit subelements is essential to such simple tasks as supporting multiple signatures. Secondly, we already support omission indirectly by allowing the manifest to use # fragment identifiers (whether or not particular persons see a need for it). What I'm suggesting is to modify the syntax to allow the direct expression of omission so that we can accomplish 'document closure'. We need to say things like "This signature signs the whole document except for the second signature". In this way, a second signer can add a signature without breaking the first, but both signers can be assured that the only thing that can be added is the signature of the second signer. </John> Interesting that you mention workflow... as a workflow engine developer, I don't agree with your assessment of the difficulties. If the user does anything too esoteric with their document format, they might have to add some special processing logic (a capability we've supported since version 1) but in most cases I expect we'll be able to do standard processing. <John> Who is 'we'? Is yours the only workflow product in the world? Does it digitally sign documents? Has it been doing so since version 1.0? When did version 1.0 come out? Shouldn't it be possible to validate a digital signature without needing custom code (read "a new hack") for each new document type that comes out? Let me rephrase that. It is possible to create a signature syntax that allows the validation of XML digital signatures without needing custom code for each document type. The question is whether we will create such a syntax. </John> Finally, I thought there was consensus that we were leaving the issue of verifying resource content to the application? I believe this is the proper course, for the reasons Don outlines in http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0071.html. <John> Firstly, there are people both on the "document" side and the "protocol message" side of signing XML that don't agree with the extra level of indirection given by this manifest idea. Don has some good points about protocol messages, but others state that the extra level of indirection makes things too slow. There has also been no refutation of my basic point that if the message I sign 'is' the same document type, then I can take the signed message itself and send it to be rendered. What you see (sense) is what you sign. Secondly, the email you cited discusses the importance of dealing with the fact that URL content is not so stable as many would have us believe. Heck, even the URL to the XML spec stopped working! Fortunately, the Brown draft permits packaging. However, if you think about the classes of people who have to deal with a document, you discover that there are users, there are programs, and there are those who write the template documents to be used by the former two. It would be helpful, even if it is not part of the core *behavior*, to at least allow a standard syntactic notation that tells applications that they need to go get the resource and package it up. We could just leave such notation up to everyone's imagination (it's not a big point, after all), but I still don't agree with Don's reasoning to the contrary. If the template document author indicates that something must be obtained for packaging prior to signing, and the URI says something zany like <greendreamssleepfuriously:foobar#987654321>, then why is it so darned hard for people to envision the possibility that the user might be presented with a dratted error message??? Thirdly, how did this follow from our discussion? John Boyer Software Development Manager UWI.Com -- The Internet Forms Company </John> -Mark Bartel -----Original Message----- From: John Boyer To: Mark Bartel; w3c-ietf-xmldsig@w3.org Sent: 7/28/99 3:29 PM Subject: RE: verifying order of resources in a document Hi Mark, <John> For starters, please see http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999AprJun/0032.htm l Replies within... </John> There has been an issue raised about a security hole related to the order of resources in a document. It is true that the order of resources is not guaranteed by the specification, but I'm confused as to why this is an issue. This is my understanding of the possibilities for asserting an order... please comment if I'm missing something here. <John>It is an issue because none of the suggestions you have below are addressed in the proposals currently under consideration. The change I'm proposing is not large, but the problem is insofar as any security hole is a problem.</John> 1. Have a DTD (of some sort) that orders the elements, and include it in the manifest. <John>If you are requiring that the DTD be applied to validate the document before committing to doing a signature, then you are proposing one of a number of variations on the types of solutions I'm claiming are needed. This is no different from requiring that the order of the resources listed in the manifest is the same order that the elements appear in the document.</John> 2. Arrange the document so that one is signing an ancestor of the elements for which the order matters. Obviously you can't do this if you don't have control of the document format. However, if you don't have control of the document format, how can you add a signature? Documents formats have to be designed with signatures in mind. You can't tack a signature onto a document if the DTD doesn't allow it or the application doesn't expect it. <John>This is close to what we do in XFDL, but this requires the ability to say 'omit' some of the subelements of the given element. Currently a manifest lists what we should 'keep'. There is no way to say, "Sign everything in this element except for ...."</John> 3. Add a resource to the manifest that refers to the statement "These resources were in this order". Note that in the general case the resource does not have to be a part of the document containing the signature. This is almost the same as #1. This approach could also be taken for asserting what is omitted from the document. <John>Another interesting solution. Could you elaborate on how you see this doing omission?</John> 4. Add a resource to the manifest that refers to the assertion "the resources in the signature were in the same order as in the manifest". <John>Yes, this is what I said above.</John> In addition, I believe that for some applications the assertion in #4 could be an implicit assumption of the document format. <John>I think this would be pretty rare.</John> It is the application's responsibility to verify the resources in the manifest against the actual resources, so verifying the order against the order in the manifest may just be an additional part of that process for some applications. <John> Part of what I'm getting at is that, at the very least, that order of non-continuous portions of a resource needs to be dealt with at some level. The other part is that I really don't think we can pass off so much of the actual signature verification to 'the application.' Pass the buck, and set up a "somebody else's problem" field around it. No. It should matter to us that we can create an XML signature that verifies as correct yet we can change the document in very meaningful and possibly harmful ways. By pushing this off to 'the application' we create this scenario where it is impossible to produce document processing software like workflow engines that use XML signatures unless those engines are aware of the pecularities of every XML document type created by every Tom, Dick and Harry. Further, that software would need to be upgraded every single time somebody puts out a new document type for their own data structure. My highest preference would be that the hash value itself capture as much information as possible. What I really want is to create a message to be signed from the manifest. Some things are external and some things are marked 'internal'. Many 'internal' resource elements may point to portions of the same Web resource. The portions of that web resource should be obtained from the resource in the order they appear in the web resource regardless of the order of listing in the manifest. The message constructed in this way is what should be signed. Naturally, this is not counter to but rather a proper superset of what is currently proposed for canonicalizing the manifest in the Brown draft. </John> In the general case, one cannot assert an order for the resources in the manifest because they will quite likely be pointing at different documents. <John> I'm not concerned about what happens in different documents. I didn't ever say that was a problem. My problem is with the order of portions of the same document. The order of listing in an XML document implicitly conveys meaning, as does element depth and attributes of all ancestors, and tag names of all ancestors. We need to be capturing all of those pieces of information in the ancestor chain that convey meaning upon a given element. I just read the c14n spec, and it simply does not account for this. I posted a prior email discussing this in greater detail. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999AprJun/0032.htm l John Boyer Software Development Manager UWI.Com -- The Internet Forms Company </John> -Mark Bartel
Received on Thursday, 29 July 1999 15:29:53 UTC