[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [egov] Re: Secure Workflow. Was: [egov] "Dry" and "Wet" signatures - A definition
I think that is where Anders began the discussion.
> -------- Original Message --------
> Subject: Re: [egov] Re: Secure Workflow. Was: [egov] "Dry" and "Wet"
> signatures - A definition
> From: Ed Chase <chase@adobe.com>
> Date: Mon, August 29, 2005 11:08 am
> To: John Messing <jmessing@law-on-line.com>
> Cc: Duane Nickull <dnickull@adobe.com>, eGov OASIS
> <egov@lists.oasis-open.org>, Anders Rundgren
> <anders.rundgren@telia.com>
>
> 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
> >
> >
> >
> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]