RE: Scenarios/FAQ

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
either).

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
new
> 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
XML
> document.
>
> A2: If you have a copy of the XML document in some temporary file or
memory
> buffer, you can put the data in an enveloping signature.  It is likely
that
> you will have to base-64 encode the XML document since an entire XML
> document cannot appear as element content.  Alternately, character
sequences
> 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
signature
> such that, in the resulting document, the signature signs the original
> document?
>
> A1: Create an enveloping signature around the root element of the
document.
> 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
clarifying
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
omitted
for the signature to validate
should be clearly stated (since I think FAQs are for the non-expert).
Editorial:
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
stuff
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
including
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 ...

[1]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0004.html
[2]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0005.html
[3]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0006.html

Andreas

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