[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [egov] WebSign standardization effort - Encryption considerations
Peter: Some comments inline: Peter F Brown wrote: >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. > > <DN> The (partial) answer is that this crosses the virtual/real world boundary. The signature by itself is not enough. One has to also prove intent and benefit from the action. For example, it would be hard to deny a signature if you had installed a software package on your system and used it to send out several files in that format if the software installer was configured to not install unless you sigend the terms of the license. There are two key tenets of digital signatures that are a bit tricky. 1. Ensuring you can reproduce exactly what was on the screen and presented to the signer and have proof positive that they did not see something different; 2. Ensuring you take a snapshot of the signed content and can flag any changes (even 1 single bit) to the file; 3. Capturing the "intent" and motivation behind the signature. If I produced a signature saying you signed it and promised to give me a million dollars and I would give you nothing in return, the intent would be highly questionable. Some other items that are "nice to have" in a signature mechanism: 4. The ability to compare the document as it was when it was signed vs. how it is now to ascertain if the modifications are material to the contract (not all changes automatically negate a signature); 5. Having a "one button" verification of signature button that can present the signature properties and perform authentication (the functionality is required, I am merely talking about the specific implementation with one button). >- 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? > > DN - If you use Adobe Acrobat and PDF you can easily note the changes since our mechanism has complete audit capabilities and allows you to show exactly what you signed. I have attached two examples here to illustrate what happened. The first form with the suffix *goodSig.pdf is a contract stating I will buy Peter Brown 3 beers on a specific date. I signed it after the values were filled out and you will be able to see the signature and look at its' properties by right clicking on it. 1. Right click on the signature and select properties 2. select the appropriate tabs The second, is one where Peter got hold of it and changed the number of beers to 45 from 3. My signature is still there however there is a small glyph that notes the document has changed. If you view the signature properties, you can actually see the original document by: 1. Right click on the signature and select "properties" 2. select the "document" tab 3. click on "view signed version" This allows you to see the version that I had signed and note the changes. In short, Peter changed the number of beers from 3 to 45 so I will now revoke my signature since this is a material change to the contract. If he had picked a more reasonable number of beers like 10, I may have decided to honor this still. Duane >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 > > > > >--------------------------------------------------------------------- >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]