[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 appreciate David's concern of "not another TC", but John is right: it
depends on scope and focus.
The mandate of the eGov TC (about more later, when I finally get around to
loading up the notes from the July informal meeting in Oxford) does
explicitly allow for work to be "handed off" to other TCs or new TC's to be
"spun off" when appropriate.
Surely the next step, as with all new pieces of work, would be for Anders et
al to put together a draft problem and scoping statement (to which I would
certainly have input from my experiences here in Austria) with some clearly
defined goals and deliverables. Only then would we be in a position to
determine whether this TC, alone or with others, or another new TC, is the
best way forward.
What is becoming clear to me,however, is that this TC and list is the right
forum to get that process started...
-Peter
-------------
Peter F Brown
---
Chair, CEN eGovernment Focus Group
---
Senior Expert
ICT-Strategy Unit
Austrian Federal Chancellery
---
Co-Editor, OASIS SOA Reference Model
---
No trees were destroyed in the production of this message. Many electrons
were however severely agitated.
-----Original Message-----
From: John Messing [mailto:jmessing@law-on-line.com]
Sent: 30 August 2005 14:29
To: peter@justbrown.net
Cc: 'eGov OASIS'; 'Anders Rundgren'; 'Ed Chase'
Subject: RE: [egov] Re: Secure Workflow. Was: [egov] "Dry" and "Wet"
signatures - A definition
I think that it depends upon the goal and whether it is within the Charter
of the TC. If the goal is to create a new standard around which applications
can be developed for a specific purpose, such as browser-based web signing,
as Anders proposed, then I think a new TC or another TC must do the work, as
the Charter of this TC is limited to policy matters such as recommendingf
best practices and OASIS XML standards to governments but not the creation
and testing of XML standards as such.
> -------- 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 1: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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]