RE: [egov] Re: Secure Workflow. Was: [egov] "Dry" and "Wet" signatures - A definition

["Peter F Brown" <peter@justbrown.net>]

John:
You state,
"ebXML repository technology may prove to be very useful in this context" 
Could you be a bit more explicit? This is interesting

Many thanks,

Peter
-------------
Peter F Brown
---
Chair, CEN eGovernment Focus Group
---
Senior Expert
ICT-Strategy Unit
Austrian Federal Chancellery
---
Co-Editor, OASIS SOA Reference Model
---

No trees were destroyed in the production of this message. Many electrons
were however severely disrupted and uprooted.


-----Original Message-----
From: John Messing [mailto:jmessing@law-on-line.com] 
Sent: 29 August 2005 17:20
To: Duane Nickull
Cc: eGov OASIS; Anders Rundgren
Subject: RE: [egov] Re: Secure Workflow. Was: [egov] "Dry" and "Wet"
signatures - A definition

A secure audit trail can be accomplished with tamper-evident technologies
and may have value even when a logical association with a human or legal
entity as a signer in a conventional sense is not necessary or desired
(e.g., to document log events securely). Where such logical association with
signers is required for purposes of legal enforceability, then it can be
considered as a subset of the secured workflow generally. Componentizing
documents into strings and metadata can overcome many of the archival issues
that have been alluded to but rarely confronted directly. Tamper-evident
technologies need not include PKI, or even traditional digital signatures,
but should take into account recent Chinese contributions to hashing
technologies and their weaknesses. ebXML repository technology may prove to
be very useful in this context. Whether retention of copies of original
documents in original format will be required remains to be seen.

The American Bar Association adopted guidelines in August 2005 for Court
Automation that incorporate many of these notions.

John Messing
American Bar Association Science and Technology Law Representative to OASIS
and LegalXML-OASIS.

> -------- Original Message --------
> Subject: [egov] Re: Secure Workflow. Was: [egov] "Dry" and "Wet"
> signatures - A definition
> From: Duane Nickull <dnickull@adobe.com>
> Date: Mon, August 29, 2005 8:02 am
> To: Anders Rundgren <anders.rundgren@telia.com>
> Cc: eGov OASIS <egov@lists.oasis-open.org>
> 
> Anders:
> 
> I understand your intent better after this email.  My points are:
> 
> 1.Steps 2 and 3 of your secure workflow below are the only methodology 
> that should be employed.  One should not presume that any "document"
> will never be modified and always perform some type of checksum() 
> operation before validating a signature.  The signed content should 
> always be auditable.
> 
> 2. There is no need to stop at the document level, DSig methodologies 
> are significantly complex today, even allowing signing of a partial 
> sub-set of a document.  Therfore, documents can contain both mutable 
> and immutable content.  Logically, if you only look at a "document" 
> and some part of it is mutable, you always have to declare the entire 
> document mutable.  I would advocate migrating from "document" to 
> "content" or components that make up a document in the thinking.
> 
> 3. An archive, checksum() implementation that provides a view of any 
> changes is also preferrable since not all changes to previously signed 
> content may be deemed to invalidate a signature.  This concept of 
> legality and material vs. immaterial changes to a contract exists in 
> many legal jurisdictions.  For example, if you sign a contract then 
> later change your postal code, that is probably insufficient to 
> invalidate the entire contract.
> 
> Duane
> 
> Anders Rundgren wrote:
> 
> > Duane,
> > I may have been unclear but my intention was not alluding that there 
> > any major security issues hidden here.
> >  
> > For a universal signature/document system like Adobe's, these terms 
> > may indeed be flawed (or not apply) as you say.  A web-only 
> > signature scheme may though be differently architected and in such 
> > schemes the terms Dry and Wet terms are not entirely wrong.
> >
> > My personal preference is that a possible standards effort should 
> > only target Dry signatures as these (in a web environment NB), are 
> > more flexible due to the separation of "user views" (static 
> > documents in arbitrary formats), signatures, and possible associated
transaction data.
> >
> > *Secure Workflow*
> >  
> > A further complexity is that few organizations including the US 
> > federal agencies have yet begun to look on how secure messaging is 
> > to be accomplished on a wider scale except by using e-mail.
> >  
> > However, e-mail has huge limitations for sophisticated (automated 
> > and
> > interactive) workflow compared to web based systems where the 
> > "transaction" and the "view", are typically not using a common 
> > representation.  The latter of course has a major impact on how 
> > signatures can be utilized.
> >  
> > I have personally "toyed" with a number of use cases in order to 
> > clear the picture for myself (to begin with...).  One simple but 
> > still pretty universal such use-case is the e-purchasing process 
> > where one or more employees are running an internal workflow system 
> > where a purchase request is, after proper authorization, converted 
> > into a purchase order and sent to a supplier.
> >  
> > My own take on the aforementioned e-purchasing process and using the 
> > web is as follows:
> >  
> > 1. The user is (when he considers him as ready), presented a 
> > completed requisition proposal in for example HTML or PDF, which he is
requested
> > to sign and submit.   In the background the actual data is usually 
> > held by the web server session in a "computer-friendly" format.
> >  
> > 2. After signature validation etc by the workflow system. the 
> > requisition is archived together with the user's signature for 
> > possible /future references/
> >  
> > 3. Assuming the user is the final authorizer, a purchase order is 
> > now created in a B2B-network specific format (like UBL or EDI), 
> > based on the requisition data (kept in the web session).
> >  
> > 4.  The completed purchase order is then archived in a table linked 
> > to the signed requisition for possible /future references/.
> >  
> > 5.  Finally, the purchase order is secured[*] and sent away for 
> > fulfillment in a B2B-network defined way
> >  
> > Steps 2-5 are automatically performed by the workflow system 
> > (server).  Except for user signatures,/ the scheme above is the 
> > de-facto standard way of performing B2B operations/.
> >  
> > regards
> > Anders Rundgren
> > Working for a major US computer security company but here acting as 
> > an individual
> >  
> > *]  This part is unfortunately a major problem for many people 
> > working with PKI as /it is really the workflow system that creates, 
> > secures, and sends purchase orders to external suppliers/.  Due to 
> > this, existing [/and widely used/] B2B schemes are almost 
> > exclusively non-secured or are using shared secrets as such schemes 
> > (/in spite of being completely inferior/) seem to pass without major 
> > consideration, while "signing PKI-servers", immediately brings in 
> > the legal department ("a machine has no will or legal power"), the 
> > security experts ("this is violating end-to-end security"), and 
> > forces most such efforts into a dead halt.  A maybe vane hope, is 
> > that these very interesting issues will be properly "aired" when/if 
> > a web signature standards process is launched.
> >
> > ----- Original Message -----
> > From: "Duane Nickull" <dnickull@adobe.com 
> > <mailto:dnickull@adobe.com>>
> > Cc: "eGov OASIS" <egov@lists.oasis-open.org 
> > <mailto:egov@lists.oasis-open.org>>
> > Sent: Thursday, August 25, 2005 19:41
> > Subject: Re: [egov] "Dry" and "Wet" signatures - A definition
> >
> >
> > Anders et al:
> >
> > I will suggest you may want to think about this differently.  Many 
> > signature mechanisms work in a way that mitigate the problem you are 
> > hinting at without having to make this distinction.  Attempting to 
> > make two classes of signature for mutable vs. immutable content is 
> > flawed IMO since you would have to fully understand every possible 
> > way a document or content *might* be modified.  This is simply 
> > beyond the grasp of any group of people since there are so many 
> > variables (metadata changes, versions, file names etc.) plus you are 
> > relying on third party vendor statements to be 100% accurate.
> >
> > A better methodology is to stipulate that at the time of signing, a 
> > hash is made of the exact content using state of the art algorithms 
> > and if the content later changes, the signature block is flagged to 
> > indicate that there have been changes since it was signed and let 
> > the actor decide how they want to proceed.  Adobe Acrobat's 
> > signature method works this way.  If for any reason, any of it 
> > changes, the signature presentation is flagged to indicate such.  
> > This method was perfected by Adobe, RSA, Entrust, VeriSign, 
> > GeoTrust, and ActivCard.  There is a lot of information available on
this from our website:
> > http://www.adobe.com/security/digsig.html
> >
> > The attached file was signed, then changed to demonstrate this.  If 
> > you go to the signature field, you can click on the triangle symbol 
> > by the green check mark.  It will open a dialog window that tells 
> > you the document is still the same, but the values themselves have 
> > been altered since (this is important to distinguish between).  If 
> > you select "signature properties", you get even more information.
> >
> > Under the summary, the window will note any changes.  If you select 
> > the "document" tab, a modification details window appears.  There is 
> > a button that allows you to generate a change log to compute 
> > modifications subsequent to signing the document.  You can also 
> > select 'View Signed Version' to see the version that was signed and
compare the two documents.
> >
> > I agree that mutability detection algorithms are complex.  Our 
> > mechanism was the result of numerous companies collaborating with 
> > customers to ensure all legal and technical problems were solved.  
> > This was a somewhat lengthly process.
> >
> > Best wishes.
> >
> > Duane
> >
> > Anders Rundgren wrote:
> >
> > > Dear list,
> > > In a previous posting where I referred to some discussions 
> > > concerning a possible Web Sign standards effort within OASIS, "Dry"
and "Wet"
> > > signatures were mentioned.  Several off-list messages indicate 
> > > that these terms need a proper explanation.
> > >
> > > This comes to no big surprise as these terms have actually been 
> > > coined by myself in the absence of an established terminology in 
> > > this actually rather virgin field.
> > >
> > > *"Wet" web-signatures
> > > *An editable document, be it an MS Word document or an HTML form 
> > > with edit fields, radio buttons etc. is filled-in and signed by 
> > > the user and then sent to the service provider.
> > >
> > > *"Dry" web-signatures*
> > > The user is (after an arbitrary interactive process with a service 
> > > provider), presented, a static (read-only) document and is 
> > > requested to sign it in order to indicate "acceptance".  Since the 
> > > document actually comes from the service provider, the result sent 
> > > to the service provider is typically only a detached signature of 
> > > the shown document.
> > > 
> > > *Further comments*
> > > These schemes represent two different schools, one which tries to 
> > > mimic the existing paper form world, while the other scheme is 
> > > more aligned with how the web is currently used.
> > > 
> > > *Implications*
> > > Superficially these schemes may appear similar, but that is indeed 
> > > not the case; there is probably a 10-to-1 difference in complexity 
> > > unless you restrict "Wet" signatures to only support a single 
> > > document format.  The reason for this increase in complexity is 
> > > that each document format has its own native signature format (or 
> > > has no defined signature format at all), as well as its own input 
> > > data validation scheme.  Using "Dry" detached signatures, you can 
> > > achieve the same thing as S/MIME does, namely document format 
> > > independence with respect to the signature process (except for some
trivial canonicalizations).
> > > Possible input data validation is assumed to have been carried out 
> > > in earlier phases of a web session, using standard web methodology.
> > > There are numerous other implications as well concerning the use 
> > > of "Wet" and "Dry" signatures, but these are far outside the range 
> > > of an e-mail posting.
> > > 
> > > Anders Rundgren
> > > Working for a major US computer security company but here acting 
> > > as an individual
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > ------------
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe from this mail list, you must leave the OASIS TC 
> > that generates this mail.  You may a link to this group and all your 
> > TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p
> > hp
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php