- From: Andreas Schmidt <aschmidt@darmstadt.gmd.de>
- Date: Tue, 07 Dec 1999 10:24:44 +0100
- To: Daniel LaLiberte <liberte@w3.org>
- CC: XMLDSig WG mailing list <w3c-ietf-xmldsig@w3.org>
Daniel LaLiberte wrote: > The requirements of the verifier (of which there may be many, with > different requirements) are what I had in mind in motivating the signer > to sign something. But although I can see now that the signer might > also have some requirements, I'm not sure that the best way to support > this is by imposing requirements on the verifier by way of the > signature. > > But these requirements are slightly different, I think, from saying that > the meaning of the signature and content are (or might be) determined by > the verifier. In other words, the verifier might require that the > signer sign something with the semantics *as declared by the signer* > which are in agreement with what the verifier requires. I think, it would be useful to clearly differentiaate between signature and application both on syntactic and semantic level. The requirements posed by XML-Signature should be the same for signer and verifier on both levels and be defined in the spec. Application semantics on the other hand, is outside the spec (as it should be): > I think the general rule here is that the signer should be able to > declare any semantics it wants to, while the verifier can try to use any > semantics it can get away with, and may require certain things in order > to proceed. If the signer wants to require something of the verifier, > perhaps it should get the verifier to sign something as well. Agreed. That's part of application semantics. See below. > Just so it is clear, I am not suggesting that the XMLdsig group should > formalize specific semantics beyond the core semantics of verification. > But it does appear to be necessary to specify a standard way in which > those higher-level semantics MAY be declared, if required by an > application. Yes, but I would not go so far as to define _one_ standard way by which application semantics has to be spelled out. Maybe it would suffice to RECOMMEND that applications should define the meaning of the signed document (at least if it is XML and not just a BLOB) explicitly, e.g., <Offer> <Contract ID="1">...</Contract> <dsig:Signature> ... <dsig:ObjectReference IDREF="1">...</dsig:ObjectReference> </dsig:Signature> </Offer> where the _application_ semantics would specify that the recipient of this message is invited to endorse this with her own signature (and wrap it in something like <Accept> ... </Accept>). I see that there are some nontrivial issues concerning the (tight) binding of application semantics to signature semantics. For example, <Offer>...</Offer> implies a statement about {<Contract> & <Signature>} - so I made it contain both - but should itself be signed by the one who makes the offer. Perhaps in this simple, self-referential case, the signature should refer to the set {<Offer> ... </Offer>} - {content of <SignatureValue>} ... Andreas
Received on Tuesday, 7 December 1999 04:24:07 UTC