[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]