Re: DateTime (DT) attribute in Reference

Hi Donald, It seems to me that the time at which a given data object
was obtained is as much a property of the signature as the time at which
the digital signature was computed. Reference digesting is a core part
of our defined signature generation process. Further, our definition of
reference validation only says "may rely on the [URI] and Transforms". Use
of a signature property is not disallowed by this. Sure, using temporally
and spatially perfect URIs might be ideal, but sometimes that is just
not possible, and a particular application may need to do something else.

Merlin

r/dee3@torque.pothole.com/2001.07.05/09:04:30
>
>While there isn't anything to stop someone from doing this, it seems
>to me it violates the idea that a SignatureProperty is supposed to be
>something about the signature/digest process itself, not about the
>data.  Seems to me that your verifier wants to be able to hand just
>the URI (usually obtained from the attribute but sometimes from the
>application context) and give this URI to a data retrieval service
>without having to worry about something off in a a SignatureProperties
>element. If we had a DataProperties element near the URI, that would be
>a fine place for this, but we don't.
>
>Thanks,
>Donald
>
>PS: Another kind of data property you might want to give is language.
>Systems should just be desiged so this can all be encoded into the URI
>one way or the other.
>
>From:  merlin <merlin@baltimore.ie>
>To:  Amir Herzberg <AMIR@newgenpay.com>
>Cc:  "Dsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
>In-reply-to:  <078EE8822DCFD411AAA1000629D56ADC0B7D37@IMP01> 
>Date:  Thu, 05 Jul 2001 13:02:50 +0100
>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 09:36:32 UTC