RE: [egov] WebSign standardization effort - Encryption considerations

["Peter F Brown" <peter@justbrown.net>]

Is there widespread evidence of "widespread impact of the pre-image
attacks"? That's not my impression from reading the recent literature.

Whatever the answer, I think that there are two issues:
- signing and authentication are two related but very distinct areas of
concern: IMO most users are mainly concerned  - if they are interested at
all - with authentication rather than signing. The burden of proof is on a
Certification Authority in an PKI infrastructure (in the EU they are legally
liable within a particular country) but what about non-PKI? Where is the
legally-binding chain of proof assertions about the validity of a particular
signature? That is a policy issue not a technology one.
- transparency in the chain of assertions: no security system is 100%
perfect but auditability should be. It is the prime consideration in the
sort of transactions Anders is considering: to be able reliably to assert
that I did or did not sign a document or transaction that someone lese has
claimed I have signed. For example, when I digitally sign one piece of mail,
sometimes my system remembers the hash value for subsequent messages,
sometimes it doesn't: in this example, how can I, reliably as a user, prove
that I have (not) explicitly signed something?

Peter
-----Original Message-----
From: John Messing [mailto:jmessing@law-on-line.com] 
Sent: 01 September 2005 18:58
To: Anders Rundgren
Cc: eGov OASIS
Subject: RE: [egov] WebSign standardization effort - Encryption
considerations

Anders:

I think I am in agreement with much of what you say with regard to
asymmetric crypto-systems but I would not rule out for requirements and use
cases per Peter's suggestion the use of symmetric keys, and I further
recommend putting a large question mark around the future of hashing, given
the Chinese recent contributions in this area and the widespread impact of
the pre-image attacks upon any system that relies upon hashes without
symmetric encryption, such as SSL, digital certs, and even VPN's.

Best regards.

> -------- Original Message --------
> Subject: Re: [egov] WebSign standardization effort - Encryption 
> considerations
> From: "Anders Rundgren" <anders.rundgren@telia.com>
> Date: Thu, September 01, 2005 9:44 am
> To: "John Messing" <jmessing@law-on-line.com>
> Cc: "eGov OASIS" <egov@lists.oasis-open.org>
> 
> 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
> >
> 
> 
> ---------------------------------------------------------------------
> 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