Let me point folk at http://www.securityfocus.com/news/5654 for a related issue. To put it very briefly, *real* authentication is hard.
"real" authentication is actually that hard; it is "identification" that tends to really get sticky. one of the reasons for simplified security taxonomy like PAIN or PAIIN ... aka
Privacy
Authentication
Identification
Integrity
Non-repudation
3-factor authentication is
something you have (like a token) something you know (like password) something you are (like biometrics)
In the past, I've posted regarding proposals for implementing authentication techniques in association with various internet operation registries .... in part because they are currently relying primarily on identification which is easily spoofed.
the previous posts highlight the domain name take-over exploits .... using the same techniques used in the referenced article for ip-address take-over.
the issue for SSL domain name certificates .... and people concerned about the integrity of the domain name infrastructure .... is that the certification authorities aren't the authoritative reference for the information that they are certifying .... it is the domain name infrastructure (and similarly the ip-address registry). The domain name take-overs have been very similar to the described techniques in the article for ip-address take-over. Somewhat the CA industry proposal is for the registries to implement public key registration at the same time the domain name (or ip-address) is registered. The public key is registered in the registry account record .... and all future interaction is done via authenticated signed transactions (authenticated using the public key in the registry account record).
The claim regarding the operation of the internet operational registries is that they are effectively non-authenticated .... in much the same way that current credit card transactions are not authenticated. The x9.59 standard is for all electronic retail payments and are authenticated using a public key registered in the account record. This is effectively the some proposal (somewhat instigated by the certification authority industry) for transitioning the internet registries from non-authenticated transactions to authenticated transactions (by using digitally signed messages that are authenticated with public key registered in the corresponding registry account record).
as in previous observations .... having a domain name owner register their public key in the internet registry (domain name infrastructure or ip-address registery) starts to lesson the requirement for having SSL domain certificates.
random past posts regarding irony/catch22 for the CAs and SSL domain name certificates:
http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
http://www.garlic.com/~lynn/2001l.html#22 Web of Trust
http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
http://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
http://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
http://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app
http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure?
http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003d.html#29 SSL questions
http://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption in a system to system interface
http://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
