RE: DateTime (DT) attribute in Reference

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:24:58 UTC