OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

egov message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]