Re: [dss] FW: EPM postmark

[Trevor Perrin <trevp@trevp.net>]

To finish responding to Ed -

At 07:28 PM 7/3/2003 +0200, Gray Steve wrote:

>
>-----Original Message-----
>From: Ed Shallow [mailto:edwardshallow@yahoo.ca]
>[...]
>What is the ultimate objective of "delegated signing". If it is solely to 
>eliminate the need for client-side certificates, this is not an objective. 
>Certianly not in a non-repudiation setting. Is non-repudiation in or out 
>of DSS's scope ?
>
>The EPM can address this requirement very simply with its Lifecycle 
>support. Consider this scenario which utilizes nothing special.
>
>1) As the first event in a new EPM Lifecycle with a specific 
>TransactionKey or Identifier, Alice of sound mind signs a "Power of 
>Attorney" allowing Bob to sign on her behalf. The Sign of this document is 
>"Verified" by the EPM and optionally PostMarked and logged as the first 
>event in this Lifecycle.
>
>2) Given that Alice and Bob have clearly participated in the above, Alice 
>invites Bob to pickup the signed "Power of Attorney" and countersign it. 
>Bob does that using the same TransactionKey that Alice used. This 
>represents the 2nd event in this lifecycle.
>
>3) With the first 2 events out of the way, Bob commences electronic 
>activities involving the use of Alice's "Power of Attorney" and clearly 
>states his intent as that "Power of Attorney" using the "intent phrase" 
>and/or SignaturePolicy facilites within the EPM.
>
>4) Bob closes out this particular lifecycle thus concluding this clearly 
>"contexted" sequence of delegated signing events. All this is peformed 
>with starightforward Sign and Verify actions that have been tied together 
>under the auspices of an EPM Transaction Lifecycle.
>
>We asked that things like Lifecycle be considered in the DSS requirements 
>document. We have not heard back as yet.

I see that you proposed some requirements[1], I asked some questions about 
them[2], you responded[3], and I didn't write back, though Nick did 
[4].  I'll review your responses and respond to them, and hopefully we can 
get consensus on changes for the next draft.

>
>I must now ask you to help me, because I am getting confused with DSS's 
>intent, objectives, and scope in the following areas:
>
>- 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?

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..

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.

>
>- 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.

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