[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
It is fine with me if the discussion leads to a new TC, but I doubt if that
is the best solution. I did not have many feedback on the planned FtF
meeting in London. This discussion could very well be a good topic on the
agenda. If we then have the idea that we have to work on the issue we could
organise a subcommittee or do a proposal for a TC.
Harm Jan
-----Oorspronkelijk bericht-----
Van: Peter F Brown [mailto:peter@justbrown.net]
Verzonden: dinsdag 30 augustus 2005 10:19
Aan: 'Anders Rundgren'; 'Ed Chase'
CC: 'eGov OASIS'
Onderwerp: RE: [egov] Re: Secure Workflow. Was: [egov] "Dry" and "Wet"
signatures - A definition
I disagree that the central concern is the server-end of the pipeline: the
sender should be the focus: it is "their" data that is at question in most
cases, and they should have better control of the process, for example
seeing the mechanism for provision of user data as mirroring a classic SOA
(see attached outline - please note IPR declaration)
But I digress: I echo Duane's question: are we looking to spin-off a new TC?
Best regards,
-Peter
-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren@telia.com]
Sent: 29 August 2005 23:43
To: Ed Chase
Cc: eGov OASIS
Subject: Re: [egov] Re: Secure Workflow. Was: [egov] "Dry" and "Wet"
signatures - A definition
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
<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>
<mailto:dnickull@adobe.com>
Date: Mon, August 29, 2005 8:02 am
To: Anders Rundgren <anders.rundgren@telia.com>
<mailto:anders.rundgren@telia.com>
Cc: eGov OASIS <egov@lists.oasis-open.org>
<mailto: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> <mailto:dnickull@adobe.com> >
Cc: "eGov OASIS" <egov@lists.oasis-open.org
<mailto: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]