Re: Verification Response Proposal: Toolkits ought to return bytes of verified data to the application

Hi Ari,

--On Mittwoch, 9. Januar 2002 14:12 -0500 Ari Kermaier <arik@phaos.com> 
wrote:

> Correct me if I'm misunderstanding, but I think Ed was interested in the
> dereferenced data obtained specifically *during* the reference validation
> process. If the call to getSignedContentItem(i) is made either before or
> after the call to verifyReferences(), then there's no guarantee (from the
> calling code's perspective) that the external data object was not
> retrieved twice and possibly modified in between. It may be that the
> Apache implementation actually caches the content retrieved during
> reference validation, but that would be an implementation detail that
> calling code can't really rely on.

I don't know what you mean with *during* reference validation? You have an 
input to the first Transform which can be either a NodeSet or an 
OctetStream and you have an output of the last Transform which MUST be an 
OctetStream which is used as input for the digest method. So what's 
*during*?

If I look at Ed's example which he provided in [1], if you use the Apache 
impl. ang you'll get either

<Body ID="MoneyTransferBody">
	<From>Bank of Nirvana</From>
	<To>Ed Simon</To>
	<Amount Currency="USD">
123.45
</Amount>
</Body>

or

<Object ID="MyDog">My dog has fleas</Object>

by calling the sig.getSignedInfo().getSignedContentItem(0) method because 
these are the octets which have been input for the digest value 
calculation. The implementation simply caches these bytes for each 
Reference and due to the fact that a Reference doesn't know whether it was 
used in a signing or verifying application, you can use it for both, "what 
did I actually sign" and "what did I actually verify", so the bank simply 
has to call sig.getSignedInfo().getSignedContentItem(0), reparse these 
octets and execute the underlying transaction.

Regards,
Christian

[1] 
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0013.html

Received on Wednesday, 9 January 2002 17:27:09 UTC