|
Hi Teow,
I'm sure that SecureAge can handle message
encryption.
What I did was really pointing out that there are
few use-cases for using encryption in a Web Sign scenario. HTTPS is the
industry-standard for facilitating encryption between users and web
applications. In case you need additional encryption, it must depend on
that the target for the signed message is not the web provider
(your organization, your bank, your government), but some other party
that you don't want the provider to know about, at least not the message
content.
This to me this looks like an e-mail system,
something that I simply concluded was another possible standards
effort.
The anticipated Web Sign standards effort is
primarily intended for high-volume, structured, and
transaction-oriented operations such as purchase orders which are
preferably checked, and stored by the local purchasing system before eventually
sent away to a selling party. Other applications include "signing
off" doctor appointments, on-line banking payments, and income tax
declarations. In none of these scenarios there is an obvious need for
encryption beyond what is already provided by HTTPS. Similar schemes
(although highly national), are already used by millions of
Scandinavians. None of these schemes offer encryption
options.
In fact hardly nobody publishes
certificates either (not even the FKPI users do that AFAIK!), in
spite of being a prerequisite for the kind of encryption you mention, unless we
are talking about proprietary approaches or reliance on local key
stores. The latter does not fit to well in a standard.
regards
Anders Rundgren
Working for a major US computer security company
but here acting as an individual
----- Original Message -----
From: Andrew Ferguson
Cc: 'Troy Braban'
Sent: Thursday, September 01, 2005 12:33
Subject: RE: WebSign standardization effort - Encryption
considerations Hi
Anders, One of our eB2Bcom
partners has responded to your latest post along the following
lines:- The SecureAge Web Form (web
encryption), Web Sign (web signing), and Secure Webmail already take care of all
the security requirements described below in Anders Rundgren’s post
- including basic support for no plain text and attachment being sent to
the server at all. The various technical difficulties mentioned by the author
have also been resolved in our solutions. We disagree with the author's
position in terms of usefulness of such technology. Specifically, we believe
that there is an increasing trend of enterprises moving various IT related
functions to the Web (like moving to webmail). Naturally, if the client based
solution requires security, the same goes with web based
version. On the other hand, the author is
right in saying that a standardization effort in this area may not be too useful
at present. Teow
Hin CEO
SecureAge Andrew
Ferguson Director eB2Bcom (Asia
Pacific) Pte Ltd 71 Ubi Crescent
#06-07 Excalibur
Centre Singapore
408571 Email: Andrew.Ferguson@eb2bcom.com Tel +65-67468286 Fax:
+65-6841-4676 H/P H/P From: Anders
Rundgren [mailto:anders.rundgren@telia.com] A potential WebSign standards
effort should IMHO not deal with explicit message encryption, as I believe
this is a less generally useful "feature". It is rather the
provider (your employer, your
bank, your government), that sets the policies, including
encryption, for a specific web application and
acts accordingly. In an off-line e-mail scenario you don't have this
option and due to this, policies effectively becomes a client issue.
However, finding the
proper encryption key to use is a major problem that clients should not have to
deal with in a properly designed web
application. To protect contents against the web
application provider's eyes seems like an odd measure, unless we are actually
talking about WebMail. Secure WebMail is though an
entirely separate issue as it must conform to S/MIME rather than using XML
security. In addition, if Secure WebMail is to be used with untrusted
mail providers, it requires the use of Wet Signatures (open forms), and
"semi-fat" clients, as the providers MUST NOT (if message encryption
is to be used), be able to "see" any clear text data, including possible
attachments. The latter means that the standard way to handle
attachments today, "upload", simply is not an option. Secure
WebMail is due to those constraints, IMO another [possible]
standardization effort. Even if a Secure WebMail standardization effort
indeed were launched, I would not build such a scheme for untrusted providers as
the "market" for such a scheme seems limited when standard e-mail clients comes
for free and already handles this scenario. The possible use-case with
public computers do not align well with encrypted content as public computers
cannot be assumed to be safe for communicating truly classified or very private
information, for that you should use your mobile phone or PDA, "model 2007"
with built-in TPM (Trusted Platform Module)
support. Comments? Anders
Rundgren Working for a major
|