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

Re: DateTime (DT) attribute in Reference

From: Tom Gindin <tgindin@us.ibm.com>
Date: Fri, 6 Jul 2001 18:55:31 -0400
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc: merlin <merlin@baltimore.ie>, "Dsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
Message-ID: <OFF3D39FE3.117423FF-ON85256A81.0073BD76@pok.ibm.com>

     Actually, IMHO, the main reason this doesn't work as a
SignatureProperty is that the time is typically different for each external
Reference element.  If one wanted to construct an Object with this function
it would have to have both a time and the ID of the Reference (thus
requiring that the Reference have an ID).
     However, is putting the date and time in the URI any cleaner than
putting it into the ID with a delimiter?  The ID doesn't have any standard
internal structure, but there is no really standard way of adding
non-retrieval-related information to a URI without affecting its retrieval
characteristics either.

          Tom Gindin

"Donald E. Eastlake 3rd" <dee3@torque.pothole.com>@w3.org on 07/06/2001
09:17:49 AM

Sent by:  w3c-ietf-xmldsig-request@w3.org

To:   merlin <merlin@baltimore.ie>
cc:   "Dsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
Subject:  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.)


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.
>>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.
>>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.
>>>>I know this is late to propose any additions. However, while working on
>>>>protocol for secure transport of XML messages, I came upon the
>>>>to refer from one message to another - specifying the time. Thinking
>>>>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
>>>>- they refer to a resource which may change over time. But when we hash
>>>>sign a resource, of course we must identify the exact version of it,
>>>>time is one of the best ways to do so.
>>>>My prefered solution is to add to Reference an optional element to
>>>>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
>>>>of IFX and OFX; but of course any other approriate attribute name e.g.
>>>>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 `...
>>>>include such information in a SignatureProperties element within an
>>>>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
>>>>to DigestValue).
>>>>Best regards,
>>>>Amir Herzberg
>>>>CTO, NewGenPay Inc.
>>>>SMS (urgent only!): _subject_ of email to aherzberg@walla.co.il

>>>Baltimore Technologies plc will not be liable for direct,  special,
>>>or consequential  damages  arising  from  alteration of  the contents of
>>>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
>>>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 18:56:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:06 UTC