Re: [dss] FW: EPM postmark

[Trevor Perrin <trevp@trevp.net>]

Steve, Ed,

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

>
>-----Original Message-----
>From: Ed Shallow [mailto:edwardshallow@yahoo.ca]
>Sent: Thursday, July 03, 2003 6:08 PM
>To: Trevor Perrin; Edward Shallow; 'Gray Steve'; dss@lists.oasis-open.org
>Cc: roger.mccune@canadapost.ca
>Subject: RE: EPM postmark
>
>Thanks for focusing the question for me.
>
>Please post to the list on my behalf ...
>
>Here goes ...
>
>The comment you quoted in the WSDL referred to the "old" "VerifyPostMark" 
>SOAP verb which was replaced with a cleaner "Verify" verb with the newly 
>introduced "ApplyPostMark" option. This was just an evolution of the WSDL 
>SOAP EPM protocol to something more flexible and straighforward.
>
>That is all that the comment was highlighting. Both old and new verbs 
>produce a totally standard RFC3161-compliant timestamp token.

Right, that's what I learned from that comment - that an EPM postmark was 
just an RFC 3161 TST.

>
>Now about the added meaning ...
>
>Having said that, an EPM (or DSS) implementation can state whatever it 
>wants to with respect to the contractual binding of signer identity to 
>data to time to terms and conditions. This is accomplished through the use 
>of a SignaturePolicy document (ref ETSI 101 733/903 and RFC3126). This 
>SignaturePolicy document can express whatever the service provider deems 
>is appropriate for their service. Again I invite you to consult the OASIS 
>references to the ETSI work in this area. Please follow link below to both 
>the XAdES standards as well as the newer XML-based SigaturePolicy standards.
>
><http://xml.coverpages.org/ni2002-04-24-a.html>http://xml.coverpages.org/ni2002-04-24-a.html 
>
>

So I assume that an EPM Postmark consists of an RFC 3161 TST with an RFC 
3126 SignaturePolicyIdentifier (or similar) as a signed attribute of the 
TST's signature?  It seems unorthodox to me to use an RFC 3161 TST for 
communicating something besides just "this data existed at this time".

But that's fine.  The DSS request/response protocol will not be a specific 
protocol, but more a framework that can be profiled to create specific 
protocols, and I think we could profile DSS to do what EPM is doing, by 
having the client request the "Verify" operation with the "Return 
Verification Info" option, in which case the service would verify the 
signature and then return the signature with an EPM-style TST as 
"Verification Info".

My comment was that I think it would be more consistent with RFC 3126 and 
XAdES and ETSI 101 733 to add Verification Info in the form of CRLs or OCSP 
responses, and then timestamp, or vice versa, whichever those standards 
require, I can't recall, but that's out of scope for this dicussion, so 
I'll stop advocating it.  After this email:)


>The CommitmentRules within the SignaturePolicy document whose hash, also, 
>and ID is placed into a conforming signature can express all sorts of 
>rules which both parties agree to abide by.
>
>In the Postal case, we just decided to have the ApplyPostMark on a Verify 
>represent attestation of successfull verification. An implementor can do 
>whatever they want under the SignaturePolicy model.
>
>Nothing is non-standard about that.

Well, I didn't know that you could use SignaturePolicies in TSTs to mean 
things beyond timestamping, but I'm not enough of a standards guru to know 
if that's really kosher or not.

>
>Again, what is DSS proposing to address that is not already addressed by 
>the existing body of standards in the digital (electronic) signature space ?

Protocols for creating and verifying digital signatures.  See Nick's use 
case document for some specific examples such as corporate seal, identified 
requestor, eNotarization.

>
>On another note, where I see DSS departing from mainstream, I would like 
>to draw your attention to the hotly contested topic of "delegated 
>signing". The stringent requirements surrounding the "signing ceremony" in 
>a non-repudiation setting immediately preclude any delegation if one is 
>attempting any sort of binding comitment. I believe the scope and intent 
>of "delegated signing" to a DSS Web Service has to be revised or at least 
>clarified in terms of scope, objectives, and intent. In non-repudiation 
>circles, this is taboo. One cannot achieve things: like 2-factor 
>authentication, what-you-see-is-what-you-sign, mutually accepted time, and 
>signing intent (i.e. context) in the delegated model. The ability to 
>repudiate a signature created without the signator's active involvement 
>would be simple, and therefore non-binding.

Good points.  In some contexts, "delegated signing", or "identified 
requestor" signatures, may not need to be legally binding.  In some legal 
regimes, they may be adequate - the US E-Sign and California laws are, as I 
understand it, basically just "non-discrimination" laws for electronic 
signatures, and don't mandate specific technologies.  I signed my tax 
returns with a PIN, for example, and it worked insofar as they took my 
money.  Though I'd love to try repudiating that.

So I think these signatures are useful even if they don't satisfy *some* 
current laws.  And while this is the type of opinion I probably should keep 
to myself, I have my doubts about the wisdom of the more proscriptive laws, 
insofar as they kinda "jump the gun" by mandating technologies that aren't 
widely deployed.

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

The Identified Requestor use case in Nick's document mentions some 
reasons.  I think eliminating the need for client-side PKI 
(procuring/managing/securing/transporting certs and keypairs) is a pretty 
good reason, and I once wrote a paper arguing for this approach in more (in 
fact, far too much) detail:
http://trevp.net/delegatedCrypto/delegatedCrypto.html
http://trevp.net/delegatedCrypto/delegatedCrypto.pdf


>Certianly not in a non-repudiation setting. Is non-repudiation in or out 
>of DSS's scope ?

I would say the DSS request/response protocol should be agnostic to 
it.  But specific profiles of DSS could consider it or not.

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

My response was to ask for use cases so us DSS people could understand in 
depth what these requirements are, and how to fit them in.  This is an 
excellent use case, thanks.

We don't have the benefit of knowing the context these requirements arose 
in, which is why I'm asking lots of questions in an effort to digest 
them.  I hope that doesn't seem pushy or resistant, I think we're making 
progress, and I'll respond in more detail to your remaining questions, but 
right now I'm running out of laptop battery..  Thanks for your forebearance,

Trevor