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

[Trevor Perrin <trevp@trevp.net>]

Responses to some requirements proposed by UPU/EPM:

At 06:10 PM 6/27/2003 +0200, Gray Steve wrote:

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

Section 3.3 in the requirements doc covers "Generic Request Requirements", 
i.e. requirements that apply to both the Signing and Verifying protocols' 
Request messages.

If the client was allowed to optionally attach an opaque identifier with 
each Request message to identify the "business transaction" the request is 
a part of, would that be sufficient?


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

As I understand this, the service holds a document, the recipient receives 
a notice "come pick up your document", and then the recipient is required 
to sign a request before being handed the document, thus achieving 
non-repudiation of receipt.

I agree with Nick that this is out out scope[1].  EPM could build off DSS 
by using DSS's Sign and Verify operations, and adding its own operations 
for Retrieve and other things, so I'm not saying there's anything wrong 
with this feature or that EPM shouldn't do it, if EPM aims for a complete 
suite of "non-repudiation" services.  But I don't think this falls within 
DSS's narrower scope of creating and verifying signatures.



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

As I understand this, certain parties are allowed to log "events" with the 
service under particular Lifecycles/TransactionKeys.  Like above, I think 
this is out of scope for DSS.

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

If the DSS service doesn't allow documents to be transferred through it, 
like my second comment above, then I don't think this applies.



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

See below.



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

As I understand it, Alice will request a Signature Verification, with an 
option to receive a "receipt" that the signature was valid at that 
time.  EPM implements this receipt as an RFC 3161 Timestamp on the signature.

We have a few ways this or similar things could be done in our 
protocol.  Which shows that we need to think about this some more.  But to 
recap the alternatives:
  - client could request the "Verify" operation with the "Return 
Information used in Verification" option, to procure the CRLs or OCSP 
responses the server used.  Which is similar to a receipt, in that it would 
help a relying party verify the signature.
  - we recently discussed the ability to request a signed verification 
response from the server.  I was going to add that into the next document.
  - the client could request a signature or timestamp on a signature, and 
the service could verify the first signature as a prelude to 
counter-signing or time-stamping it.
  - the Verify operation with the "Return Information used in Verification" 
option could verify the signature and then return it time-stamped, or 
counter-signed.  I was suggesting this but now I'm not so sure, cause the 
server isn't really returning information used in verifying, but creating 
new information.

So this is confusing, I don't know what to do here.

[Question about EPM: it seems like the "ApplyPostmark" option requests the 
service to add a postmark to the signature, and the "IssueReceipt" option 
requests the service to return the postmarked signature.  Is that correct?]



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

I lost sight of this, could you send a reference or explain again?


Anyways, it seems that a few EPM requirements are out of scope for DSS, and 
thus that EPM should probably be a "superset" of DSS - that is, EPM could 
use DSS for signing and verifying, but would have its own, additional 
operations for things like Non-repudiable Delivery and Logging of 
Events.  Does that make sense?

[1] http://lists.oasis-open.org/archives/dss/200306/msg00090.html

Trevor