Stephan Neuhaus wrote: > That's because PSKs (as I have understood them) have storage and > management issues that CA certificates don't have, four of which are > that there will be a lot more PSKs than CA certificates, that you can't > preinstall them in browsers, that the issue of how to exchange PSKs > securely in the first place is left as an exercise for the reader (good > luck!), and that there is a revocation problem. > > To resolve any of those issues, code will need to be written, both on > the client side and on the server side (except for the secure exchange > of PSKs, which is IMHO unresolvable without changes to the business > workflow). The client side code is manageable, because the code will be > used by many people so that it may be worthwhile to spend the effort. > But the server side? There are many more server applications than there > are different Web browsers, and each one would have to be changed. At > the very least, they'd need an administrative interface to enter and > delete PSKs. That means that supporting PSKs is going to cost the > businesses money (both to change their code and to change their > workflow), money that they'd rather not spend on something that they > probably perceive as the customer's (i.e., not their) problem, namely > phishing. > > Some German banks put warnings on their web pages that they'll never ask > you for private information such as passwords. SaarLB > (http://www.saarlb.de) even urges you to check the certificate > fingerprint and provides well-written instructions on how to do that. In > return, they'll assume no responsibility if someone phishes your PIN and > TANs. They might, out of goodwill, reimburse you. Then again, they > might not. I believe that SaarLB could win in court. So where is the > incentive for SaarLB to spend the money for PSK support?
an alternative view of the server side is to recognize that the two most widest used authentication infrastructures are radius and kerberos http://www.garlic.com/~lynn/subpubkey.html#radius http://www.garlic.com/~lynn/subpubkey.html#kerberos furthermore both radius and kerberos not only have facilities for abstracting authentication function ... but also abstracting authorization functions. one of the short-comings of PKIs, CAs, and digital certificates was the issue of encorporating authorization information along with the authentication information into a single paradigm ... for one thing digital certificates tended to be publicly available .. and authorization information frequently tends to be sensitive. frequently then the issue is that attempting to replace existing authentication infrastructures with PKIs, CAs, and digital certificates still leaves the rest of the infrastructure for authorization in place. It is then frequently trivial to demonstrate that the stale, static digital certificates are redundant and superfluous ... and it is more efficient and less expensive to have an integrated authentication and authorization environment by simply registering public keys in lieu of passwords in an existing integrated authentication/authorizatin environment. for example ... the original pk-init draft for kerberos specified registering public keys in lieu of passwords ... giving a integrated authentication/authorizatin environment using digital signature verification in place of passwords for authentication. later PKI, CAs, and digital certificate operation was added to the pk-init draft. Another aspect was that in the early 90s ... certification authorities were started to wonder just what set of information would really be useful for unknown and undefined relying parties ... as a result there was some direction to start grossly overloading x.509 identity certificates with huge amounts of personal information. It was in the mid-90s that some institutions were starting to realize that x.509 identity certificates, grossly overloading with huge amounts of personal information represented significant privacy and liability issues. As a result you started to see the apperance of relying-party-only certificates (in fact, it may have been a german bank that started producing the first relying-party-only certificates) http://www.garlic.com/~lynn/subpubkey.html#rpo A relying-party-only certificate basically contains some sort of database lookup value (like userid, account number, etc) where the real information is kept and a public key. However it is trivial to demonstrate that a relying-party-only certificate is redundant and superfluous when the real information has to be directly accessed ... by demonstrating that the body of the signed message/transaction can also include the same database index value ... and the real information will be where the registered public key is recorded. That makes the public key in the digital certificate redundant and superfluous. Simple scenarios like transactions have to include the identifier ... and in certificate-based scenarios ... the identifier in the transaction needs to match the identifier in the certificate (or otherwise you could have somebody with a valid account doing transactions against any account at the same bank). With the identifier in the body of the message/transaction and the registered public key in the account record, the relying-party-only digital certificate becomes redundant and superfluous. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
