FW: [dss] Comments to draft 6 Use Case requirements

[Gray Steve <steve.gray@upu.int>]

I am not sure if this set of responses to trevor's questions made it to the
list.

See answers below marked <ed>

Regards


Steve Gray


-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: Wednesday, June 25, 2003 11:56 PM
To: Gray Steve; dss@lists.oasis-open.org
Subject: RE: [dss] Comments to draft 6 Use Case requirements



At 05:57 PM 6/17/2003 +0200, Gray Steve wrote:


>I thought I would submit the following requirements which are specific 
>to the UPU's Electronic PostMark. I only received these yesterday from 
>one of my technical colleagues. They may be useful for the Use case 
>requirements document.

Hi Steve,

you brought these requirements up a while ago.  There's some interesting
things here we should try to include in the DSS requirements, but I'm still
trying to understand some of them.  I'll bring this up on the concall, but
mostly some examples would be helpful.  And some of these may apply to EPM,
but not DSS.



>.       Ability to tie multiple "business transaction" lifecycle events
>together under a common identifier or key. This will allow the 
>complying service to tie together several significant events in the 
>non-repudiation lifecycle.

Could you give an example?

<ed>
Many everyday business transactions are much more complicated than the
simple origin document sign and recipient document verify. Very often the
chain of events involved cannot be captured entirely on the back of a single
document (although XMLDSIG strives to support subset and even overlapping
references). By supporting a simple "chaining mechanism" all events deemed
significant (and their associated documents) can be tied together with the
conscious participation of all implicated parties. See TransactionKey and
StartLifecycle's "ParticipatingParty" and "AccessScope" elements. This is
not intended to replace simple document countersigning. However when
significant changes to a document or form go through numerous iterations
involving differing document authoring tools, non-XML file formats,
extractions, and saved copies over longer periods of time, the single
document model quickly deteriorates. One can easily see how related
Lifecycle events can irrefutably re-create much more complex business
transactions. The bulk of such an implementation might reside with a
workflow product, but the digital signature service must be able to support
it. Hence the lifecycle key.    
</ed>


>.       Ability to "store signed content" which would be awaiting pickup by
>an intended recipient. Additionally the ability to specify that the 
>request to retrieve this content needs to be "signed" by the intended 
>recipient (i.e. a "sign for pickup" facility)

The service can function as a document transport mechanism?  I assume this
wouldn't apply to DSS, but I'm still a little curious when/why would this be
useful?  What EPM operations are called to implement this on the Sender and
Receiver sides?

<ed>
When a DSS is verifiying signature objects very often the entire SignedInfo
is presented to the service. For non-repudiation purposes the entire request
as well as the verification results are stored in the NR DB. As such the
service has the content. Now if the sender requires confirmation of receipt,
it is a fairly simple matter to direct the recipient to the service using
the TransactionKey and have them "pickup" the signed document. Furthermore,
the originator can request that the recipient sign for this pick-up thus
implementing yet another pillar of non-repudiation "non-repudiation of
receipt". This can take place without any more transport than normally
occurs in the originator signs, originator sends via eMail, recipient
verifies scenario. If subscribers prefer to utilize transport agents of
their own, the DSS is involved more passively at each end. Remember,
non-repudiation must support a complete story, and has no arbitrary
boundaries. As such we scoped in the interface to a transport agent through
the "vouching" mechanism described below. The conclusion of this dialog will
fall out of the scoping decision. Does OASIS intend to address
non-repudiation with this protocol submission. Again, I contend that if they
don't, the overlap with existing standards will simply confuse.
</ed>


>.       Ability to allow other trusted service providers to "vouch for
>events" in a given lifecycle. The example we most often use is the 
>"Mail Transport Agent" vouching for the sender that he indeed submitted 
>a document. Additionally the "Mail Transport Agent" can vouch to the 
>EPM Service that it indeed transported the particular document. This 
>can be accomplished by a "Vouched Event" operation. Chain of trust must 
>be established between "vouching" and "vouched for" parties.
>
>.       Ability to allow a signator (acting as a sender) to request a
signed
>delivery and  receipt confirmation from the recipient.

How does this work when Sender and Recipient are using different EPM
services?

<ed>
This is not easy but is an implementation question. The LogEvent operation
is free-form and as such the "vouching" and "vouched for" systems can agree
on an approach. Scenario, Microsoft agree to provide and support the
non-repudiation of submission and non-repudiation of transport events for
the EPM. There must be a hand-off at origin between the EPM and for example
Outlook/Exchange. The MTA would submit a signed LogEvent operation to the
EPM attesting or vouching for the successful submission. Amount of detail
must support the minimum required to withstand scrutiny.
</ed>


>.       Ability to add a timestamp to an existing signature presented by
the
>subscriber.

Why not use a normal Time-stamp Protocol (like RFC 3161)?

<ed>
Yes, in fact it a higher-level encapsulated version of that specific RFC but
hiding the detailed complexities from the caller. See TimeStamp in the WSDL.
</ed>


>.       Ability to retrieve signature verification results, if authorized
to
>do so.

When would this be useful?  Why would Alice want to retrieve Bob's signature
verification results?

<ed>
If Alice is the lawyer and Bob is the origin signator over a legal document,
Alice would need evidence of the signature validity. This Alice would do by
requesting an "IssueReceipt" option on the verification request from the
Trusted Service Provider (EPM operator).
</ed>


>.       Ability to have "passed in" content checked by the service against
>the content (SignedInfo) of a previously created signature over that
>content. Essentially a check on the sameness of content previously signed.

When this would be useful?

<ed>
See previous response I submitted discussing the role of CheckIntegrity in a
Web form-signing context.
</ed>

Trevor