RE: 9991216 Minutes

Hi Rich,

Actually, if you look a little lower in the text of part 3, the RESULT was
no change.  An XPath transform of child::text() is still needed (it
automatically provides text rendering of text node).  The RESULT of our
discussion was that most seemed to feel that moving the data from within the
document to outside was sufficiently application-specific that if you wanted
to do it, then the spec covers it by using a manifest as I've described
earlier.

Since Joseph asked for the example I gave you previously, it will be posted
separately.

Basically, the core signature verifies.  If your app took the signature
apart, then presumably it can put it back together again before trying to
verify it with core behavior.  Or, your app could support manifest
validation.

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

<Signature>
<SignedInfo>
<ObjectReference ValidateMe="yes" IDREF="M">
<Transforms DiscourseId="T_1">
<Transform Algorithm="&xpath;">
descendant::node()
[
	not(self::Location and parent::ObjectReference) and
	not(self::IDREF and parent::ObjectReference) and
	not(self::Transform[@Algorithm="&base64;"]) and
	not(self::Transform[@Algorithm="&xpath;" and text()="string(text())"])
]
</Transform>
...
</ObjectReference>
...
</SignedInfo>
...
</Signature>

<Manifest Id="M">
<ObjectReference ValidateMe="yes" IDREF="X">
<Transforms DiscourseId="T_2">
<Transform Algorithm="&xpath;">string(text())</Transform>
<Transform Algorithm="&base64;"/>
</Transforms>
<DigestMethod>&sha1;</DigestMethod>
<DigestValue>blahblahblahblahblahblahbla=</DigestValue>
</ObjectReference>
</Manifest>

<Document Id="X">
Iambase64encodingofaPDFdocument=
</Document>

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of
rhimes@nmcourt.fed.us
Sent: Thursday, December 16, 1999 1:47 PM
To: w3c-ietf-xmldsig@w3.org
Subject: Re:9991216 Minutes



>    3. When Object is used for data (as specified in the Type attribute),
>       do not include start/end tages in hash and auto-decode per any
>       Encoding attribute.

Great!

<snip/>
>       Reagle: If our concern is referring to manifests, just use an ID
>       in the Manifest element and refer to that! Concerns about moving
>       an encoded object from within an object to elsewhere would be more
>       tricky. Boyer: wrote an email to Himes on how to do this, will
>       send to list.
>       RESULT: no change, but clarify text that references can ref to
>       Manifest directly.

Sorry, I'm having trouble keeping track of our current state (how we are
keeping
track of what is dereferenced, etc.)  If we are allowing location to be
changed
for core behavior (are we?), and we are decoding (base64) content for the
hash,
why is it tricky?  I believe John's solution involves retrieving the
external
document, reconstructing the internal configuration, then starting the
signature
process.  Not as clean as signing the unencoded data and allowing location
(e.g.
IDREF or URL) to float.

>    6. Pull SignatureProperties up to the level of Object.
>       Eastlake: removes extra level of nesting.
>       Reagle: likes to keep an Object as the bucket to place non-core
>       syntax and semantics.
>       Fox: wants a strong reason for us to make a change.

Better design should be a strong enough reason for any changes we make at
this
point.  I understand that we need to start finalizing things, and I
understand
that there has probably been code investment, but I don't think we should
freeze
it too early at the cost of capability, simplicity, or lucidity for the rest
of
the world.

Thanks,
Rich

Received on Thursday, 16 December 1999 21:11:27 UTC