W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

RE: Scenarios/FAQ

From: John Boyer <jboyer@uwi.com>
Date: Tue, 18 Jan 2000 09:34:35 -0800
To: "Andreas Schmidt" <aschmidt@darmstadt.gmd.de>
Cc: "DSig Group" <w3c-ietf-xmldsig@w3.org>
Firstly, these are rough answers.  The intent at this stage was to find out
if anyone totally disagreed with the direction of the answers themselves, so
comments about "such and such must be clearly stated" are obvious and I
won't talk about those suggestions further.

Secondly, on combining questions 2 and 5: Yes, they have a lot in common,
but at the time at least I felt they were two different questions from the
non-expert point of view.  Our goal here is not to create the absolute
minimum number of questions (though we don't want an explosion of them

Thirdly, regarding the idea that enveloped signatures should automatically
exclude bits of themselves, I agree that it is pointless to force the
signature to contain a transform to omit pieces that MUST be omitted for the
signature to ever validate.  Evidence of the fact that I agree includes the
fact that this is currently how signature filters work in XFDL.  We don't
encumber the XFDL author with the obvious.  However, when last I spoke to
Joseph about this topic, the response was that the WG didn't want to
encumber the core processing rules.

Perhaps I will bring this up at the FTF, but it will likely get resolved in
favor of those who write the code to support XMLDSig rather than those who
must use the code that supports XMLDSig.  Too bad, but I guess it's not the
end of the world.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Andreas Schmidt
Sent: Tuesday, January 18, 2000 2:20 AM
To: John Boyer
Cc: DSig Group
Subject: Re: Scenarios/FAQ

John Boyer wrote:

> Joseph asked for this to be posted for consideration before the FTF.
> This is a first draft of (some of) the questions that will end up in the
> scenarios/FAQ document.  In addition, rough notes on what the answers will
> be are given.
> Please feel free to comment on these answers.  Also, certainly there are
> additional useful questions/answers.

I want to briefly comment on FAQs 2) and 5) cited below

> 2) I have a whole XML document.  How do I sign it?
> A1: If the XML document is addressable by a URL, then you could create a
> detached signature. The SignedInfo Reference would include a URI to the
> document.
> A2: If you have a copy of the XML document in some temporary file or
> buffer, you can put the data in an enveloping signature.  It is likely
> you will have to base-64 encode the XML document since an entire XML
> document cannot appear as element content.  Alternately, character
> forbidden from content by XML can be escaped using the XML escaping
> mechanism.
> A3: You could create an enveloped signature inside the XML document. The
> SignedInfo Reference would refer to the document’s root element.  The
> signature would have to use transforms to excluded itself from the message
> digested in the Reference’s DigestValue.


> 5) I have an XML document.  How do I combine that document with a
> such that, in the resulting document, the signature signs the original
> document?
> A1: Create an enveloping signature around the root element of the
> A2: Create an enveloped signature.  The signature is placed inside the
> document, and its SignedInfo Reference contains transforms that omit the
> signature from the document.

First it seems to me, that these two could be combined into a single
question (maybe with subpoints). Two suggestions, that I think would help
the issues:

1. In answers 2) A3 and 5) A2 the _minimum_ content to be omitted by the
transformations (DigestValue and SignatureValue), and that it MUST be
for the signature to validate
should be clearly stated (since I think FAQs are for the non-expert).
The URI="" addressing method should be spelled out and a reference to the
defining portion of the spec
should be given.

2. In [1] I made the suggestion that URI="" should automatically omit the
leading to self-referentiality, which was objected in [2,3]. I would suggest
that the design choice
taken for core syntax behaviour is explained at this point (I think
such stuff in a FAQ
helps clarifying and is therefore generally a good thing). Text proposal:

  "This two step procedure, using URI="" and transformations, has been
prescribed in spite of
    its apparent redundancy for the following reasons: ..."

The reasons given in [2,3] are to be filled in for ...


Received on Tuesday, 18 January 2000 12:38:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:33 UTC