RE: 991118 Telecon Minutes

Right, this is what I said at the end of that last message.  The base-64
decode can't be outside of the SignedInfo because it must occur after the
XPath of child::text().

In general, arbitrary transforms should not be omitted from (or allowed
outside of) SignedInfo.  Mark Bartel has a fine email that runs through an
example of why this is so.

This is, of course, why omissions from SignedInfo should be specified in
exacting detail using an XPath (provided that the XPath filter on SignedInfo
is not allowed to omit itself from SignedInfo-- the bottom turtle!).

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
rhimes@nmcourt.fed.us
Sent: Monday, November 22, 1999 11:40 AM
To: w3c-ietf-xmldsig@w3.org
Subject: Re:991118 Telecon Minutes



>From the telecon:

>   Boyer: Orthogonal quick question before the call ends: If you use a
>   IDREF, does it include the element within which the ID sets, or only
>   the element's content. Call: IDREF probably returns the element.
>   Boyer: in Richard Himes' scenario, he only wants the content (because
>   that is what is fed into the Base64 decoder if an encoded document is
>   embedded in XML).

>   Call: suspect if you want only the content, you will have to use a
>   simple XPath like child::text().

Sorry I couldn't make it, I was on a plane.  Just wanted to note that if it
is a
good idea to specify base64-decode outside SignedInfo (I think it is), the
suggested transform should also be allowed outside SignedInfo.

Thanks,
Rich

Received on Monday, 22 November 1999 15:12:26 UTC