Re: DateTime (DT) attribute in Reference

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:05:30 UTC