RE: [dss] FW: [dss-comment] Public Comment

["Edward Shallow" <ed.shallow@rogers.com>]

Well said Trevor ... I concur.

As an adjunct to Trevor's response, the PostMark in the EPM Profile
encapsulates both, and even allows for an optional RFC 3161 binary token
alongside the dss:Timestamp inside the PostMarkReceipt for backward
compatibility with existing TSA's. This notion could be adopted by the core
fairly easily as Trevor points out.

Ed    

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: January 18, 2006 3:20 AM
To: Nick Pope
Cc: OASIS DSS TC; Trevor Perrin
Subject: Re: [dss] FW: [dss-comment] Public Comment


Nick,

I'm sure more discussion can be found in archives (e.g. [1]).  From what I
remember:

  - The <TstInfo> is similar to RFC 3161 but was adapted to XML, XML-DSIG,
and DSS in various ways.

  - The nonce is optional in RFC 3161.  Its use allows the client to prevent
replay attacks.  DSS, unlike RFC 3161, is designed to be used over some
security binding which prevents replay attacks (as well as protecting
optional inputs/outputs, return values, etc.).  So we don't need to put
extra fields inside the returned signature to secure the protocol.

  - The messageImprint is not placed inside the <TstInfo>, instead the
<TstInfo> is signed along with whatever else the signature covers, which
fits better with XML-DSIG.

  - Defining a new version can be done with a new namespace.

  - The <dss:Timestamp> element is extensible if you'd like to wrap a
different underlying type of timestamp.  If you just want to put other
signed or unsigned stuff in the same <ds:Signature> alongside the
<dss:TstInfo> you can do that already.  So there's no need for additional
extensibility within the <dss:TstInfo>.


Trevor


[1] http://lists.oasis-open.org/archives/dss/200308/msg00015.html


Nick Pope wrote:
> Can anyone (Trevor?) recall for the reason for excluding of certain 
> elements of RFC 3161 TSTInfo in the DSS XML timestamp.
> 
> I think Nonce was not necessary because DSS protocol provides elements 
> to relate request and response.  Not sure why no extensability or 
> version number.
> 
> Nick
> 
> -----Original Message-----
> From: comment-form@oasis-open.org [mailto:comment-form@oasis-open.org]
> Sent: 12 January 2006 12:22
> To: dss-comment@lists.oasis-open.org
> Subject: [dss-comment] Public Comment
> 
> 
> Comment from: inma@dif.um.es
> 
> Name: Inma Marín
> 
> Title: IT Consultant
> 
> Organization: University of Murcia
> 
> Regarding Specification: DSS Core Committee Draft 3 (DSS Core 
> Elements)
> 
> 
> 
> As far as <dss:TstInfo> element is concerned (within <dss:Timestamp> 
> element which contains an XML Timestamp Token) and, after comparing it 
> with TSTInfo element in RFC 3161, I noticed that <dss:TstInfo> does 
> not include some elements that are contained in RFC 3161 TSTInfo, such 
> as, "nonce" and "extensions". I wonder why these differences exist 
> regarding RFC 3161. Could you be so kind as to tell me why the 
> structure of a <dss:TstInfo> is different from RFC3161 TSTInfo, please?
> 
> 
> 
> Is it a mistake or an oversight? I can not understand why they are not 
> incoporated to <dss:TstInfo>. Thank you very much in advance.
> 
> 
> 
> Inma.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dss-comment-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dss-comment-help@lists.oasis-open.org
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php