Re: Proposal for a new PKI model (At least I hope it's new)

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 09/03/03


Date: Wed, 03 Sep 2003 01:09:40 GMT


"George Ou" <2038george_ou9127@2342netzero.com2897> writes:
> DNS system where you would have a ".com" root CA that would assign
> your domain level root CA signing privileges for your domain only?
> Then the world would have no problem trusting your domain level PKI
> servers for just your domain. That trust is impossible under our
> current PKI system because they would have to trust your PKI servers
> to sign for everything under the sun. I believe that this lack of
> granularity grants an absurd monopoly to companies like Verisign, in
> addition to many other problems that make public PKI deployment
> pathetic. If a PKI system (like DNS) that delegates signing
> authority to the individual domains could be standardized, it would
> instantly allow PKI to realize it's original aspirations of vast
> global deployment to empower PKC everywhere! Just think, you will
> never need to purchase more than one certificate from Verisign for
> your entire domain once every 5 years!
>
> I don't know if this concept is new and I can only hope it is, but I
> wrote the following original work which I hope you will enjoy
> reading.

we were working on this thing with this small client/server startup
that wanted to do payment transactions:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

and as part of that had to perform due diligence on all these things
that were supposedly PKI Certification Authorities. As part of that we
coined the term "certificate manufacturing" to distinquish from actual
PKIs.

it turns out that one of the reasons for the SSL server domain name
certificates was because of perceived issues in the domain name
infrastructure. However, it turns out that the authoritative agency
for domain names is the domain name infrastructure and all the CAs
issuing SSL server domain name certificates have to go to the
authoritative agency for domain names in order to validate the
information for placing in SSL server domain name certificates (the
very same domain name infrastructure that integrity concerns about
gave rise to the need for SSL server domain name certificates)

Now, it so happens that the SSL server domain name certificate
industry is in something of a quandary ... they are dependent on the
domain name infrastructure which has integrity issues that gave rise
to the need for SSL domain name certificates.

So there have been some number of proposals to strengthen the
integrity of the domain name instructure ... somewhat prompted by the
SSL server domain name certificate industry ... so that they can rely
on the integrity of the domain name infrastructure for their purposes.
This creates something of a catch-22 for the SSL server domain name
certificate industry since improving the integrity of the domain name
infrastructure reduces the need for SSL server domain name
certificates (compensating for integrity issues in the domain name
infrastructure).

The other issue is that somewhat from the SSL server domain name
certificate industry is one of the proposals for improving the
integrity of the domain name infrastructure is that public keys be
registered at the same time as domain names are registered. This also
represents a catch-22 for the SSL server domain name certificate
industry. If there you had a trusted, timely, dynamic, online
information distribution infrastructure and it also had public keys
that were available for distribution, it would go a long ways towards
eliminating all of the requirement for SSL server domain name
certificates.

Rather than having stale, static, SSL server domain name certificates
for being able to validate a server's public key .... the public key
is distributed from the same trusted infrastructure that distributes
the domain name to ip-address information (aka the existing domain
name service implementations are actually is able of distributing
timely, dynamic, online information not restricted to ip-addresses).

So the SSL server domain name certificate industry is in a real
catch-22, (effectively sowing the seeds for their own demise) they are

1) proposing that the integrity of the domain name infrastructure be
fixed (so that they can trust it), but that means that everybody could
trust it also, eliminating much of the requirement for SSL domain name
certificates

2) part of the their proposal for improving the integrity of the
domain name infrastructure involves registering public keys when
domain names are registered. However, this sets up an infrastructure
for timely, dynamic, online trusted information distribution of the
public keys (in addition to the trusted distribution of the
ip-address), eliminating the need for stale, static certificate-based
distribution of public keys.

This also opens up the ancillary option of improving the SSL protocol,
the domain name infrastructure can have the public key and the
preferred crypto optionss registered. At the same time the client made
a domain name infrastructure request for an ip-address, the system
could optionally return the associated public key and preferred crypto
options piggybacked in the same transfer. If the client is in
agreement, then it could bypass all the certificate protocol chatter
and just send the initial session key, encrypted with the server's
public key as part of initial contacting the host. Assuming something
like an XTP, 3 packet transaction protocol .... the actual encrypted
session data could ride in the same packet. Assuming everything is
perfectly valid on the server end ... the encrypted response and
session tear-down could come back in the response.

Basically, for on online world, you eliminate the static, stale,
offline PKI paradigm, and move to a modern, timely, dynamic online
infrastructure.

lots of past threads regarding the catch-22 for the SSL domain name
server industry sowing the seeds of their own demise:
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg1 Domain Name integrity problem
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg2 Domain Name integrity problem
http://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work?
http://www.garlic.com/~lynn/aepay6.htm#dspki3 use of digital signatures and PKI (addenda)
http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#34 some certification & authentication landscape summary from recent threads
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#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#80 Invisible Ink, E-signatures slow to broadly catch on (addenda)
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/aepay11.htm#37 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aepay11.htm#43 Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)
http://www.garlic.com/~lynn/aepay11.htm#45 Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)
http://www.garlic.com/~lynn/aepay12.htm#18 DNS inventor says cure to net identity problems is right under our nose
http://www.garlic.com/~lynn/aadsm4.htm#2 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#3 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#8 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki3 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki4 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#softpki12 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI)
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/aadsm12.htm#5 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/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#36 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm15.htm#0 invoicing with PKI
http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
http://www.garlic.com/~lynn/2000e.html#47 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/2001c.html#82 ARP timeout?
http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001d.html#36 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001e.html#26 Can I create my own SSL key?
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#10 Root certificates
http://www.garlic.com/~lynn/2001g.html#16 Root certificates
http://www.garlic.com/~lynn/2001g.html#19 Root certificates
http://www.garlic.com/~lynn/2001g.html#21 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#3 PKI/Digital signature doesn't work
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/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001l.html#22 Web of Trust
http://www.garlic.com/~lynn/2001l.html#26 voice encryption box (STU-III for the masses)
http://www.garlic.com/~lynn/2001l.html#29 voice encryption box (STU-III for the masses)
http://www.garlic.com/~lynn/2001l.html#31 voice encryption box (STU-III for the masses)
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/2002.html#32 Buffer overflow
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#72 Digital certificate varification
http://www.garlic.com/~lynn/2002g.html#65 Real man-in-the-middle attacks?
http://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002j.html#61 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002j.html#79 Q: Trust in an X.509 certificate
http://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?
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#7 Are ssl certificates all equally secure?
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/2002p.html#10 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#11 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#17 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#19 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#52 SSL & Man In the Middle Attack
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


Relevant Pages