Re: DateTime (DT) attribute in Reference

Such information can be readily captured using the
existing signature property framework. There are
many possible implementations; for example:

    <Reference ID="foo" ...>
    <DateTime Target="#foo" Value="..." />

I can't see the strong argument for modifying the
current dsig versus using this type of mechanism.

I suspect you might also be able to define a DT
attribute in an external namespace and add it to
references without changing the existing model.


>I know this is late to propose any additions. However, while working on
>protocol for secure transport of XML messages, I came upon the requirement
>to refer from one message to another - specifying the time. Thinking more
>about it I realized that many references to external data may need to
>identify the specific time of the  reference. The reference currently
>identifies the data by URI, but URIs specifically do _not_ identify the time
>- they refer to a resource which may change over time. But when we hash and
>sign a resource, of course we must identify the exact version of it, and
>time is one of the best ways to do so.
>My prefered solution is to add to Reference an optional element to contain
>the time at which the reference was made, e.g. <Reference URI=`uri` DT='
>(I like to call it DT, for Date & Time, simply because it's the convention
>of IFX and OFX; but of course any other approriate attribute name e.g. Time
>is fine by me)
>Notice this is different from the time of computing the signature itself, as
>a signature may often contain references to resources using their values at
>previous time. I know that the issue of indicating the time of computing the
>signature was addressed in the recommendation, and an application `... may
>include such information in a SignatureProperties element within an Object
>element.`. But this is the time of computing the (entire) signature, not the
>time at which the contents of the Reference were `frozen` (and later hashed
>to DigestValue). 
>Best regards, 
>Amir Herzberg
>CTO, NewGenPay Inc.  
>SMS (urgent only!): _subject_ of email to

Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

Received on Thursday, 5 July 2001 08:03:41 UTC