W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2001

Re: DateTime (DT) attribute in Reference

From: merlin <merlin@baltimore.ie>
Date: Thu, 05 Jul 2001 13:02:50 +0100
To: Amir Herzberg <AMIR@newgenpay.com>
Cc: "Dsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
Message-Id: <20010705120250.7AFB044037@yog-sothoth.ie.baltimore.com>

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

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

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.

Merlin

r/AMIR@newgenpay.com/2001.07.05/13:39:47
>Hi, 
>
>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='
>2001-07-04T17:49:04T'>
>
>(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.  
>http://www.newgenpay.com/Amir/Herzberg.htm
>SMS (urgent only!): _subject_ of email to aherzberg@walla.co.il
>


-----------------------------------------------------------------------------
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.
   http://www.baltimore.com
Received on Thursday, 5 July 2001 08:03:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:36 UTC