I think an SC might be the way forward for these discussions.
Carl
----- Original Message -----
Sent: Tuesday, August 30, 2005 6:12
AM
Subject: RE: [egov] Re: Secure Workflow.
Was: [egov] "Dry" and "Wet" signatures - A definition
Peter,
Please - NATC (Not Another TC!).
I believe that the Registry TC is already working in this area on SAML /
XSAML and certificate stores with single sign-on capability. A SC there
could definately make more sense?
Also - the BCM / EPR SC work on eFolders using IHE/XDS version of ebXML
Registry is providing the ground work for the workflow and information
management aspects of this.
The EPR team has talked about creating a full TC - but again the SC is
doing good work right now without the additional burden of running a fullup
TC.
Perhaps a joint initiative between eGov / Registry / BCM would be a
stronger way to proceed with the aim of publishing a best-practices guideline
to the eGov TC?
DW
--------
Original Message -------- Subject: RE: [egov] Re: Secure Workflow. Was:
[egov] "Dry" and "Wet" signatures - A definition From: "Peter F Brown"
<peter@justbrown.net> Date: Tue, August 30, 2005 4:18 am To:
"'Anders Rundgren'" <anders.rundgren@telia.com>, "'Ed
Chase'" <chase@adobe.com> Cc: "'eGov OASIS'"
<egov@lists.oasis-open.org>
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
--------------------------------------------------------------------- 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
|