Re: [egov] WebSign standardization effort - Encryption considerations

["Anders Rundgren" <anders.rundgren@telia.com>]

Hi John,
Sometimes things go a little bit wrong when die-hard "technicians" and
lawyers try to exchange ideas and this may be such an occasion :-)

May I add one MAJOR complication: In order to follow the threads
below the reader must know how current web apps actually work,
otherwise I don't think we get much farther.

JM Wrote:
Please permit me to challenge the assumption, which I believe is
widely-held and a foundation of much security thinking, that client
computers are inherently "safer" than servers for mission-critical
tasks such as encryption for privacy or signatures. With personal
computers connected 24/7 to the Internet over broadband connections,
and the advent of trojan horses and similar threats, available
statistics indicate a significant percentage of compromised individual
client computers. As encryption keys are difficult for lay persons to
master and maintain, so personal computer security from a wide variety
of network threats has become equally if not more difficult to
establish and maintain. Once a personal computer is compromised, all
bets about its security are off, including security of encryption keys.

Anders response:
I'm in 100% agreement (although some nit-pickers would add that
there is a difference between other parties' public [encryption] keys
and your own private [decryption] keys).

JM continued:
Without empirical evidence in the form of statistics to show that trust
in one's personal computer is inherently greater than trust of a public
server, I think the reasoning you have set forth in your preliminary
observation is questionable, which may have legal as well as policy
implications.

Anders response:
I did indeed proposed that encryption should not be done at the PC-
level, but not for security reasons but due to the fact that there is no
point in encrypting data if the recipient is the web server itself.
For that purpose we already have the industry standard HTTPS,
which is simple to deploy and puts no burden on the users.  To
add explicit message encryption may sound simple but it is actually
completely in disharmony with how the web is working.  Just to
give you an example:  Assume that you would sign and encrypt
a PDF.  Since the web provider apparently is untrusted you would
in fact have to:
- start MS Word
- write something
- create PDF
- sign
- encrypt (how do you locate the recepient's public key?)
- send the completed stuff to the recepient
This has little or nothing to do with the web,  this is e-mail.

In a web environment OTOH:
- the communication is encrypted using HTTPS for the entire session
- the user in an interactive session creates a transaction request
which is (when ready) shown to the user who is requested to sign it
- user performs signing
- the web app receives and verifies the signature
- behind the user-readable transaction request there is likely to be a
structured  transaction but it only "lives" on the server.  Shopping carts
are usually implemented like this.  Time-proven methodology
- all client-side stuff is happening in the browser.
100% web. 100% thin client.

regards
Anders

> -------- Original Message --------
> Subject: [egov] WebSign standardization effort - Encryption
> considerations
> From: "Anders Rundgren" <anders.rundgren@telia.com>
> Date: Thu, September 01, 2005 12:52 am
> To: "eGov OASIS" <egov@lists.oasis-open.org>
>
>
>
> 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 commun

icating 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 US computer security company but here acting as an individual
>