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

["Nick Pope" <pope@secstan.com>]

See some further thoughts on a couple of points discussed below (marked
<NP>):

Nick

> -----Original Message-----
> From: Gray Steve [mailto:steve.gray@upu.int]
> Sent: 27 June 2003 17:10
> To: dss@lists.oasis-open.org
> Subject: FW: [dss] Comments to draft 6 Use Case requirements
>
>
> 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>
>
<NP>
This is a common requirement to have some identifier for relating a sequence
of signing operations to some application related "activity" identifier.  I
would suggest that this is not not necessarily bound to use of a specific
crytographic key, since the same key may be used across several activities.
<NP>

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

<NP>
Getting DSS into such data handling applications is opening up to a whole
new area of issues.  I suggest the scope of DSS is limited to signing, not
data handling.  It should not preclude the use of digital signatures to
provide non-repudiation services (e.g. non repudiation of message
submission, receipt etc) as part of an application service.
<NP>

>
> >.       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
>
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php