[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [egov] Secure Workflow. Was: [egov] "Dry" and "Wet" signatures - A definition
Chris,
The proposed workflow and signature scheme does
indeed preserve privacy but I would express this in a different
way.
That is, privacy in step 2 (versus your
own organization) is hopefully not an issue as a major point with
purchasing systems is to track, control and monitor all purchasing
activities.
But since purchase orders are (in this
scheme), signature-wise (and often in other ways as well)
disconnected from the actual authorizer's signature, external
parties do not receive this potentially privacy-depriving
information. Due to this, purchase orders may be submitted also by persons
that in some way must be "sheltered". Bill Gates can thus order a
Mac without it becoming an "open secret". :-)
In case an external party has any complaints or
questions regarding a received purchase order, it will first have to contact the
entity (individual) referred to in the purchase order ("our reference") which in
turn can go back to the original submitter if needed. The
latter would though never involve sending the signed requisition to the
external party (unless there is a crime behind which
effectively removes privacy concerns). External parties
would typically not even be able to verify such signatures
as they typically belong to internal PKIs.
Anders
----- Original Message -----
From: Lowe Chris
To: Anders Rundgren ; Duane Nickull
Cc: eGov OASIS
Sent: Saturday, August 27, 2005 16:37
Subject: RE: [egov] Secure Workflow. Was: [egov] "Dry" and "Wet"
signatures - A definition Anders-
I strikes me that part of your step two, the
phrase "possible future references", could raise some privacy
concerns. Perhaps it should be more explicit about reusing
a hash of the signature, not the signature itself?
Chris
From: Anders Rundgren [mailto:anders.rundgren@telia.com] Sent: Saturday, August 27, 2005 6:55 AM To: Duane Nickull Cc: eGov OASIS Subject: [egov] Secure Workflow. Was: [egov] "Dry" and "Wet" signatures - A definition 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> Cc: "eGov OASIS" <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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]