* Kyle Hamilton wrote on Thu, Jan 14, 2010 at 12:03 -0800: > * Steffen asked... > > ...on this level [thanks a lot again for all the clarifications: authentication levels, authentication-agnostic, URI-dependent certificates, bugfix because missed intention, MITM tricks twitter to decrypt and disclose, epoch 1 to detect renegotiation, and GnuTLS]
> There's an implementation which uses OpenPGP keys/assertions, > called GnuTLS. [...stores client cert hashes...] > (and no, this doesn't count as 'design a cryptosystem'. What you're > proposing is essentially to allow the client to set its own public > key, and thus trust anchor, upon correct authentication. > public/private keypairs are first-order identities; the reason CAs > exist is because it's impossible to know who claims that any given > keypair belongs to him without external intervention, and CAs are > *supposed* to strongly bind [using their own private key] the > appropriate details of the individual who did present the public key > for certification. However, authenticating to the Server with a > username/password, and submitting a public key, is more than enough to > be able to issue a certificate related to that username.) ahh ok. This isn't common because not so easy-to-use, yes? > > Using (real) CAs could have disadvantages when it comes to > > privacy or when someone wants to use pseudonyms, I think. > > Oh dear gods yes. I've been trying to get people to see that for > years. Thank you. > > (As I think I mentioned, Wes Kussmaul is working on a project that > provides a different approach to the issue, but we're both hampered by > the lack of decent client certificate generation UIs.) Even with a UI avialable I could imagine that it could be difficult to get a wide acceptance; I think many know the term "SSL" and associate it 1:1 with "internet security". > > Difficult topic. Good to know that experts (like you) are > > working on it. > > You, since your signature says that you work for a payment > solutions provider, would not normally be one (in my eyes) to > raise the privacy concern -- but this suggests that you are in > the EU, where regulations are more strict. There are several privacy concerns in payment systems. For example, error messages may not be transmitted to protect card holder privacy (sometimes making it difficult to track down some issues), laws and requirement specs are about how to store data (like PAN of credit cards). The German electronic purse (pre-paid card) is even able to do anonymous payment transactions (requiring a card not bound to any account; such cards are rarely seen but exist). Whatever I write here is my personal opinion only and I'm not a security expert etc #include <disclaimers/full_super_safe.h>... > > Yes, you helped me a lot, it was great lecture. Thank you very > > much that you again provided me free lessons with so many > > information!! > > You are most welcome. I think that this knowledge, above all else, > *must* be free, if people are to be able to learn how to protect > themselves and their information. > > Also, your comments here have spurred me into thinking about different > parts of the problem... for example, a user cannot be a CA, under > X.509. Ohh why not? Forbidden by rfc5280 or so? I though setting the needed basic constraint cA=TRUE would do the job? (beside that I don't know any public CA that would ever certify such a certificate because typically in the web then I would inherit the trust :-) which maybe just shows that this "chains" might be bad in general - just because I trust a CA this does not neccesarily mean I trust anyone who was able to authenticate itself to this CA). In theory, wouldn't even a self-signed user certificate be possible (e.g. when the server maintains a user-password-certhash data base), like you mentioned in GnuTLS (unless I missunderstood)? A self-signed-only "PKI"? > However, there is a different certificate profile which allows > users to issue certificates based on their own credentials, called the > "proxy certificate profile" (defined in RFC 3820 -- which I wish they > hadn't numbered it as, since it's so easy to lysdexiate that to RFC > 3280 -- the predecessor to the current PKIX, RFC5280.) It might be > useful to issue a user a certificate, and then allow authentication > using proxy certificates issued by that user's certificate, thus > reducing the number of times the private key is actually used -- > allowing it to be stored offline, for example, while proxy > certificates issued by it are online and used. ohh yes, and my USB class 3/4 smart card reader's display could display the proxyPolicy in an appropriate (for me verifyable) form, I could decide to enter my PIN or to cancel. I could generate a 1yr valid myspace cert stored on my laptop and a 10 minutes valid one for my banking account or even limited to a single transaction (including amount and destination account name in the proxyPolicy to allow me to verify on a trusted class 3/4 device). cool. Or having a cell phone application. Since cell phones are so popular for everything I'm sure there are heaps of projects working on that already. oki, Steffen --[end of message]------------------------------------------------->8======= About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
