[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
If it is an egov-centric issue, as I suspect it
is, shouldn't it be a subcommittee, rather than
another full TC?
Ciao,
Rex
At 10:18 AM +0200 8/30/05, Peter F Brown wrote:
>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
>
>
>
>
>
>
>
>
>
>Attachment converted: Macintosh HD:eCitizenship
>model_v1.png (PNGf/«IC») (000922D2)
>---------------------------------------------------------------------
>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
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]