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

[John Messing <jmessing@law-on-line.com>]

And there are long-term archival issues that still remain unresolved.


> -------- Original Message --------
> Subject: Re: [egov] Re: Secure Workflow. Was: [egov] "Dry" and "Wet"
> signatures - A definition
> From: Duane Nickull <dnickull@adobe.com>
> Date: Mon, August 29, 2005 2:57 pm
> To: Anders Rundgren <anders.rundgren@telia.com>
> Cc: Ed Chase <chase@adobe.com>, eGov OASIS <egov@lists.oasis-open.org>
> 
> Anders:
> 
> LOL ;-)  You are preaching to the converted.  Adobe has actually 
> released a complete workflow engine as a core part of its liveCycle.
> 
> It seems from this thread that there is a lot of interest in this 
> topic.  Is your intention to set up a separate TC and list serve for 
> this effort?  I would be interested in continuing.
> 
> best wishes (from Stockholm West)
> 
> Duane
> 
> Anders Rundgren wrote:
> 
> > Ed,
> > In your description of the purchasing process, you left out the 
> > information (workflow) system.  In my opinion, information systems 
> > today constitute the core of IT, and should due to this influence how 
> > you structure and control, not only data, but processes, roles etc.
> >  
> > By using client-based PKI security, you can indeed extend 
> > authentication beyond your own systems as your rightfully claim.   The 
> > dark side of this superficially very tempting perspective, is major 
> > inflexibility, high costs, limited scalability, privacy issues, and a 
> > multitude of "very promising PKI pilots". 
> >  
> > If we again take the US federal agencies (who have toiled with FPKI 
> > for more than a decade), they for some reasons, AFAIK, to date do 
> > not publish certificates, in spite of being a prerequisite for 
> > handling encryption the way you describe.  SSL/TLS has due to this 
> > become the de-facto way of encrypting transactions between 
> > organizations, at least for POs.
> >  
> > Apparently even some US public sector entities have recently begun to 
> > realize that the end-to-end PKI paradigm is not delivering, which can 
> > be seen in the following document: 
> > http://middleware.internet2.edu/pki05/proceedings/kailar-phinms.ppt which, 
> > somewhat ironically, was initially shown in NIST's facilities, the 
> > very home of FPKI.
> >  
> > My proposed charter for a WebSign standardization effort is therefore 
> > targeting a world "controlled" by information systems.  Furthermore, I 
> > would favor a scheme that addresses the volume market which is signing 
> > off day-to-day tasks like on-line bank payments, PO attestations, 
> > income tax declarations, and doctor appointments.  It does in no 
> > way have to stop there, but this is where it should start.
> >  
> > regards
> > Anders Rundgren
> > Working for a major US computer security company but here acting as an 
> > individual
> >  
> > ----- Original Message -----
> > *From:* Ed Chase <mailto:chase@adobe.com>
> > *To:* John Messing <mailto:jmessing@law-on-line.com>
> > *Cc:* Duane Nickull <mailto:dnickull@adobe.com> ; eGov OASIS 
> > <mailto:egov@lists.oasis-open.org> ; Anders Rundgren 
> > <mailto:anders.rundgren@telia.com>
> > *Sent:* Monday, August 29, 2005 20:08
> > *Subject:* Re: [egov] Re: Secure Workflow. Was: [egov] "Dry" and "Wet" 
> > signatures - A definition
> >
> > John -
> >
> > It seems that you're suggesting that you can establish authenticity 
> > without identity. I would disagree. At some point you have to 
> > establish trust with a system, individual, or organization through 
> > some means - whether this is internal authentication or PKI digital ID 
> > it's the same concept. Trust has to be established either explicitly 
> > or implicitly. PKI signatures just offer the opportunity to extend 
> > authentication beyond your own systems. While an ebXML registry could 
> > certainly categorize the information in the messages, it doesn't 
> > really address any issues of trust between the parties.
> >
> >
> > With regard to secure transactions & PKI -
> >
> > For transactions like the purchase order example that start internal 
> > and later become external, why not use PKI from the start and employ 
> > policy mapping between organizations or a bridge? Certificate policy 
> > mapping (for limited sized communities) or a PKI bridge would give the 
> > trading partners interoperability on both the authenticity and 
> > security fronts. How about something like this:
> >
> > 1) Include PKI policy-mapping with business partner agreements and/or 
> > take advantage of a PKI bridge.
> > 2) Create a your forms in PDF or an XHTML document variant that's 
> > based on your industry standard for exchange - UBL or whatever.
> > 3) Users complete the form or application and sign both presentation 
> > and data with their digital identity. If it's a PDF, the signature is 
> > embedded within the document, and you can also embed the revocation 
> > status of your credential at sign-time for long-term validation.
> > 4) Encrypt the document for the recipient's specific digital ID if 
> > required and send the document
> > 5) The document is protected regardless of transport. Having a PKI 
> > relationship with your trading partner allows your signatures to be 
> > validated by the recipient.
> >
> > The majority of this can be automated. Signing and validation can be 
> > server-centric if required. Everything you need for auditable long 
> > term validity is self contained within the document and possessed by 
> > both parties. The PKI layer is also self-contained and well removed 
> > from the process. You don't have to worry about transport or 
> > individual authentication requirements for different trading partners.
> >
> > Ed
> > -- 
> > <http://www.adobe.com>Ed Chase
> > Worldwide Standards
> > Adobe Systems, Inc.
> > chase@adobe.com
> > 703.883.2830
> >
> > John Messing wrote:
> >
> >>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.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
> >>>    
> >>>
> >>
> >>
> >>---------------------------------------------------------------------
> >>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