Re: [dss] FW: EPM postmark

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

Some comments on Trevor's answers

>>
>>- how is DSS different than existing published standards in this area, 
>>most notably ETSI 101-733/903 ?
>
>Is 101-733 the same as RFC 3126, and 101-903 the same as XAdES that was 
>submitted to w3c?

In summary: ETSI TS 101 733 specifies different electronic signature forms in
ASN.1 RFC 3126 is an informatonal RFC taken from TS 101 733 and defining
the same structures. TS 101 903 (XAdES)  specifies different electronic
signature forms
in XML. These structures allow to add XMLDSIG additional "attributes" to cover
those features identified in TS 101 733 (with some additions as allowed by
XML and not allowed by ASN.1). W3C note was produced from TS 101 903...
This is the whole picture.

>
>If so, the difference is that they are signature formats, whereas DSS is a 
>request/response protocol for producing and verifying signatures that may 
>be in these, or any other, format.
>
>DSS will tackle the mechanics of sending data to sign/verify, and 
>retrieving the response (and the mechanics are plenty complicated, since we 
>want to support an octopoid format like XML-DSIG that lets you sign 
>multiple things with different transforms in a single signature, and 
>include the signature in the document in different ways).
>
>So DSS will be a fairly generic, low-level protocol, that can be profiled 
>in terms of which signature profiles it supports, what bindings the 
>protocol is transported over, what application context it's used in, etc..
>

I fully agree with Trevor's description


>For more detail, see 3.10 in the requirements doc, where it talks about us 
>producing 2 documents, the first consisting of the request/response 
>protocol and some "core" XML elements (like Requestor Identity, and 
>time-stamps), that will be useful as signature contents in conjunction with 
>this protocol.
>

>The second document will consist of an initial set of bindings and 
>profiles, to get the ball rolling.  But I think right now our attention is 
>mostly on the first document, and that's what most of the requirements 
>pertain to.
>
I also agree with Trevor
>>
>>- is non-repudiation within the scope of DSS ?
>
>I think non-repudiation is a higher-level concept that doesn't pertain to 
>the DSS request/response protocol.  The protocol will just let a client 
>send some data to be signed and get back a signature.  Higher-level 
>profiles, and legal and operational contexts, will determine what that 
>signature means.
>
I agree again. Higher-level profiles should consider these issues....

Juan Carlos.
>Though when we discuss the Requestor Identity element, we could mention the 
>non-repudiation issues surrounding it as a "Security Consideration".
>
>
>>- is there any binding assumptions about the signatures produced by a DSS 
>>service ?
>
>I'm not sure what "binding assumptions" are.
>
>>
>>- how does DSS propose to extend value to the Web Service subscriber 
>>community ?
>
>I'm not sure what the "Web Service subscriber community" is.
>
>Trevor
>
>[1] http://lists.oasis-open.org/archives/dss/200306/msg00032.html
>[2] http://lists.oasis-open.org/archives/dss/200306/msg00077.html
>[3] http://lists.oasis-open.org/archives/dss/200306/msg00089.html
>[4] http://lists.oasis-open.org/archives/dss/200306/msg00090.html 
>
>
>You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
>