Re: DateTime (DT) attribute in Reference

<Object><ReferenceProperty ...><DateTime ... /></ReferenceProperty></Object>

Summary: Adding the information doesn't need a change to dsig.

r/gregor.karlinger@iaik.at/2001.07.05/16:21:06
>Hi all,
>
>I agree with Donald. The semantics of a SignatureProperty is a qualification
>of the Signature, and not of a data object that is covered by the signature.
>
>As Armir has described his problem, he wants to use the DateTime to make a
>statement on the version of a data object, and I would not consider this as
>a property of the signature.
>
>Regards, Gregor
>
>> -----Original Message-----
>> From: w3c-ietf-xmldsig-request@w3.org
>> [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of merlin
>> Sent: Thursday, July 05, 2001 3:36 PM
>> To: Donald E. Eastlake 3rd
>> Cc: Dsig (E-mail)
>> Subject: 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 10:39:47 UTC