Re: DateTime (DT) attribute in Reference

Hi Merlin,

Sure, if you just want to record the time data was actually retrieved
when the signature was generated, that's fine as a SignatureProperty.
But that isn't what Amir said. He said that one message wanted to
refer to another message based on the message date.  That is to say,
this date and time were data labeling information and didn't have
anything to do with when the data was actually retrieved or the
signature actually generated. In his case, using SignatureProperties
does not conform to their intent. If this D&T are being used by some
retrieval method, then it should be possible to encapsulate that
retrieval method into a URI scheme and all of the retrieval parameters
into a URI.  (While that is the right way to do it, practical
considerations may make it a lot easier to stick the info elsewhere in
some circumstances.)

Thanks,
Donald

From:  merlin <merlin@baltimore.ie>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc:  "Dsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
In-reply-to:  <200107051304.JAA0000009651@torque.pothole.com> 
Date:  Thu, 05 Jul 2001 14:35:51 +0100
Message-Id:  <20010705133552.0476744037@yog-sothoth.ie.baltimore.com>

>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 Friday, 6 July 2001 09:18:56 UTC