[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
Please see
http://lists.oasis-open.org/archives/legalxml-courtfiling/200508/msg00029.html
> -------- Original Message --------
> Subject: RE: [egov] Re: Secure Workflow. Was: [egov] "Dry" and "Wet"
> signatures - A definition
> From: "Lowe Chris" <lowe_chris@bah.com>
> Date: Mon, August 29, 2005 8:55 am
> To: "John Messing" <jmessing@law-on-line.com>
>
> John--
> Are these standards publicly available?
>
> Chris
>
>
> =======================
> Christopher Lowe, CISSP
> Associate, Booz Allen Hamilton
> 703-377-4011
> lowe_christopher@bah.com
> -----Original Message-----
> From: John Messing [mailto:jmessing@law-on-line.com]
> Sent: Monday, August 29, 2005 11:20 AM
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]