[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [egov] WebSign standardization effort - Encryption considerations
...which convinces me all the more that the initial consideration must be to adequately scope the requirements (both user and functional) before any considerations of specific transaction or security models Peter -----Original Message----- From: John Messing [mailto:jmessing@law-on-line.com] Sent: 01 September 2005 16:10 To: Anders Rundgren Cc: eGov OASIS Subject: RE: [egov] WebSign standardization effort - Encryption considerations Hi Anders: 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. 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. My two cents. John Messing > -------- 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 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 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]