Re: New Method for Authenticated Public Key Exchange without Digital Certificates

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 08/06/04 

Date: Fri, 06 Aug 2004 15:01:46 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
> I am very sorry for my poor knowledge and hence having many dumb
> questions. I continue to surmise that without CAs there would be
> stuff that wouldn't go as fine. For CAs are by definition what
> common people can trust (whether that's inherently reasonable or not
> is irrelevant for the current discussion). Now without CAs how are
> the parties who don't know one another personally going to establish
> trust between them at all for doing electronic transactions? In
> particular, how does one know that a public key claimed to be one of
> a specific firm is really genuine? I don't yet see a good way for
> that. Note as analogy that even some number of normal
> (non-electronic) transactions may (under circumstances) need a third
> party that enjoys the trust of the ones doing the transactions as
> mediator. (Cf. notary for contracts, civil registry office for
> marriage, etc.)

ok ... try SSL domain name server certificates and associated
infrastructure for something called electronic commerce ... minor
reference:
http://www.garlic.com/~lynn/subtopic.html#asrn2
http://www.garlic.com/~lynn/subtopic.html#asrn3

one of the motivating factors for the SSL domain name server
certificates were issues with the integrity of the domain name
infrastructure and things like ip-address take-over ... and/or how do
i know that the server that i think i'm talking to is really the
server that i'm talking to.

so somebody applies to a certification authority for an SSL domain
name server certificate. in many cases the certification authority
isn't the authoritative agency as to the owner of the domain name.
therefor the certification authority has to contact the authoritative
agency for domain name ownership ... which is the domain name
infrastructure (the very operation that there are concerns with
regarding integrity ... giving rise to much of the motivation for SSL
domain name server certificates).

so somewhat motivated by the certification authority industry, there
is a proposal that when somebody registers a domain name with the
domain name infrastructure, they also register a public key. then when
the entity applies to a certification authority for a SSL domain name
server certificate, they digitally sign the request. Then the
certification authority just has to retrieve the naked public key on
file with the domain name infrastructure to validate the digital
signature on the SSL domain name server certificate request.

currently, there is identification information on file with the domain
name infrastructure as to the owner of the domain name. in the
existing SSL domain name server certificate application scenario, the
applicate would supply identification information and the
certification authority then would have to execute a complex,
time-consuming, expensive error prone process that attempts to match
the identification information supplied with the SSL domain name
server certificate application to the identification information on
file with the domain name infrastructure.

in the proposal to have naked public keys on file with the domain name
infrastructure, the certification authority would just have to
retrieve the naked public key from the domain name infrastructure to
validate the digital signature on the SSL domain name server certificate
application. this replaces a time-consuming, expensive, complex, and
error-prone identification process with an simple, inexpensive,
straight-forward, strong authentication process.

the catch22 for the certification authority industry are:

1) if communication related to correct domain name can be
authenticated with (naked) public keys on file with the domain name
infrastructure, it improves the integrity of the domain name
infrastructure, which mitigates the motivation for needing SSL domain
name server certificates

2) if there are public keys on file with the domain name
infrastructure which can be retrieved by certification authories for
validating digital signatures on SSL domain name server certificate
applications, then it would be possible for other people to retrieve
on-file public keys also to validate digital signature on other kinds
of communication. The ability to distribute on-file public keys
related to domain name issues then totally subsumes the need for
distributing public keys via SSL domain name server certificates.

some past threads mentioning notary infrastructures:
http://www.garlic.com/~lynn/aadsm5.htm#ocrp Online Certificate Revocation Protocol
http://www.garlic.com/~lynn/aadsm5.htm#ocrp2 Online Certificate Revocation Protocol
http://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate Revocation Protocol
http://www.garlic.com/~lynn/aadsm5.htm#ocrp4 Online Certificate Revocation Protocol
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure?

actually some of the notary issues ... don't so much come up with
respect to valid certifices ... but come up with respect to real-time
proof of intention related to signatures for demonstrating intent,
approval, and/or agreement with what has being digitally signed. This
is different that using digital signatures for strictly authentication
purposes demonstrating origin. In fact, I've made the assertion that
there may be comprimises where there is dual-use of the same key-pair
for both authentication and demonstrating intent, approval, and/or
agreement ... specifically some authentication protocols may send
random challenges which the receiver digitally signs (w/o reading) and
returns. An attack on digital signatures in the sense of intent, agreement,
and/or approval ... is send valid information in place of random challenge
as part of an authentication prototol. misc pieces of the dual-use
thread:
http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)

random past references to electronic commerce and SSL domain name
server certificate requirements
http://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror10 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
http://www.garlic.com/~lynn/aadsm8.htm#softpki Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki3 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki12 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability
http://www.garlic.com/~lynn/aadsm10.htm#cfppki20 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm11.htm#36 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
http://www.garlic.com/~lynn/aadsm11.htm#43 PKI: Only Mostly Dead
http://www.garlic.com/~lynn/aadsm12.htm#4 news: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#67 Offline Root CA with valid CRL hierachie
http://www.garlic.com/~lynn/aadsm13.htm#25 Certificate Policies (addenda)
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/aadsm13.htm#33 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#37 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#7 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#8 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#9 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#10 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#11 Resolving an identifier into a meaning
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm15.htm#26 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards
http://www.garlic.com/~lynn/aepay10.htm#75 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#78 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#79 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/2000e.html#50 Why trust root CAs ?
http://www.garlic.com/~lynn/2000e.html#51 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001c.html#9 Server authentication
http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001e.html#27 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#33 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#36 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#37 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#39 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#40 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#43 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#2 Root certificates
http://www.garlic.com/~lynn/2001g.html#55 Using a self-signed certificate on a private network
http://www.garlic.com/~lynn/2001h.html#4 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#6 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001j.html#10 PKI (Public Key Infrastructure)
http://www.garlic.com/~lynn/2001k.html#6 Is VeriSign lying???
http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
http://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks?
http://www.garlic.com/~lynn/2001n.html#57 Certificate Authentication Issues in IE and Verisign
http://www.garlic.com/~lynn/2001n.html#73 A PKI question and an answer
http://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002e.html#60 Browser Security
http://www.garlic.com/~lynn/2002e.html#72 Digital certificate varification
http://www.garlic.com/~lynn/2002g.html#65 Real man-in-the-middle attacks?
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
http://www.garlic.com/~lynn/2002j.html#38 MITM solved by AES/CFB - am I missing something?!
http://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?
http://www.garlic.com/~lynn/2002k.html#51 SSL Beginner's Question
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/2002n.html#16 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#10 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#12 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#21 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#40 Authentification vs Encryption in a system to system interface
http://www.garlic.com/~lynn/2003d.html#71 SSL/TLS DHE suites and short exponents
http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#46 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#51 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#54 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#55 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#57 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application
http://www.garlic.com/~lynn/2004b.html#41 SSL certificates
http://www.garlic.com/~lynn/2004h.html#28 Convince me that SSL certificates are not a big scam 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Relevant Pages