Subject: Global PKI on DNS?

From: Franck Martin <[email-masked]>
Date: 08 Jun 2002 13:22:28 +0000

I was wondering if the best system to build a global PKI wouldn't be the
DNS system already in place?

The root servers would share the ROOT Certificates and would sign a
certificate to each .org .com .net .fr,... managers of this
domains...Which in turn would use these certificates to sign sub domains
certificates...

The issued certifcates would have a constraint on the domain name to
ensure that the certificate can only be used in sub domains... and would
allow to be used for anything (web server, imap server, e-mail, code,
document,...)

There would be an extension to the DNS protocol to add a type record
which would allow to extract the certificate and the list of revoked
certificates...

The system would have to be quite secure but DNSSec is in place now...

It would be the easiest way as apparently nobody is trying to build a
global PKI infrastructure and LDAP people can't agree on a global
standard to link each ldap server to each other, which DNS has...

Comments?

Cheers.

---

From: [email-masked]
Date: Fri, 07 Jun 2002 22:27:10 -0400

> DNS system already in place?

No.

1) There's *NOT* a good mapping between the DNS and LDAP (hint - DN=, O=,
and OU+ can be at the same level...)

2) DNS has to be *FAST*, especially at the root - we're talking on the
order of 200K queries a *SECOND*.  You figure out how to do that while
also tossing certificates around, let us know...
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: "James Pullicino" <[email-masked]>
Date: Sat, 8 Jun 2002 22:16:15 +0200

What is the average size of a PKI certificate?

Regards,

James Pullicino
  ----- Original Message ----- 
  From: Franck Martin 
  To: [email-masked] 
  Cc: [email-masked] ; [email-masked] 
  Sent: Saturday, June 08, 2002 3:22 PM
  Subject: Global PKI on DNS?

  I was wondering if the best system to build a global PKI wouldn't be the DNS system already in place? 

  The root servers would share the ROOT Certificates and would sign a certificate to each .org .com .net .fr,... managers of this domains...Which in turn would use these certificates to sign sub domains certificates... 

  The issued certifcates would have a constraint on the domain name to ensure that the certificate can only be used in sub domains... and would allow to be used for anything (web server, imap server, e-mail, code, document,...) 

  There would be an extension to the DNS protocol to add a type record which would allow to extract the certificate and the list of revoked certificates... 

  It would be the easiest way as apparently nobody is trying to build a global PKI infrastructure and LDAP people can't agree on a global standard to link each ldap server to each other, which DNS has... 

  Comments? 

  Cheers.

---

From: Franck Martin <[email-masked]>
Date: 08 Jun 2002 23:06:58 +0000

1)This is what I said LDAP is highly unstructured at the global level
where DNS is not...

2)Wow, that's sheer load...How will it scale with more and more people
on the net? However for certifcate how many time your browser check for
a root certificate? Never... MS has built-in inside the windows update a
system to donload new root certificates but that's all. You get it one
time, you trust and forget about it till expiration time... as toor
servers and ccTLD and gTLD are likely to be srious people then you don't
need either to make any query to get the certificates. You just get them
one time...

Cheers.

On Sat, 2002-06-08 at 02:27, [email-masked] wrote:

    
    No.

---

From: Franck Martin <[email-masked]>
Date: 08 Jun 2002 23:18:03 +0000

Here is a sample certificate... which is less than 2kB long...

DNS protocol uses mainly udp, which I think can handle this size...

You can know what it means by using the command (I think):

openssl x509 -in thiscert.cert -text

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

On Sat, 2002-06-08 at 20:16, James Pullicino wrote:

    Regards,
     
    James Pullicino

---

From: Michael Richardson <[email-masked]>
Date: Sat, 08 Jun 2002 13:16:39 -0400

>>>>> "Franck" == Franck Martin <[email-masked]> writes:
    Franck> I was wondering if the best system to build a global PKI wouldn't be the
    Franck> DNS system already in place?

    Franck> The root servers would share the ROOT Certificates and would sign a
    Franck> certificate to each .org .com .net .fr,... managers of this
    Franck> domains...Which in turn would use these certificates to sign sub
    Franck> domains 
    Franck> certificates...

Please see the minutes from the "siked" BOF from #53... oops, none produced.

http://www.ietf.org/ietf/02mar/siked.txt
and the mailing list at [email-masked].

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Pekka Savola <[email-masked]>
Date: Sat, 8 Jun 2002 21:31:14 +0300 (EEST)

> and the mailing list at [email-masked].

I think this was when Randy Bush (with Ops & Mgmt Area Director hat on)  
said that certificates will not be stored in DNS; keys.. if you really 
want, why not (but if you don't understand the difference between keys 
and certificates, be quiet).

Or at least that was how I remember how it went.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: David Conrad <[email-masked]>
Date: Sat, 08 Jun 2002 13:30:18 -0700

On 6/7/02 7:27 PM, "[email-masked]" <[email-masked]>
wrote:
> order of 200K queries a *SECOND*.

While true, this is a bit misleading.  Each individual root server gets less
than 10K queries per second.

> You figure out how to do that while

Distribute the load.

Rgds,
-drc

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 08 Jun 2002 16:09:19 -0500

> DNS system already in place?

This is an ongoing argument. Essentially there are two camps:

  Pro--there's a global database out there, let's put useful stuff
       into it. Certs is a no-brainer, but people have also argued for
       baseball scores, usernames, and everything else short of kitchen
       sink inventories.

  Con--the more crap you put into DNS, the less usable it becomes for
       its primary purpose of providing fast and lightweight lookups
       for Internet resources. While certs can be argued to be in that
       camp, they cannot be handled with fast and lightweight lookups.

As other people have already pointed out, the use of large objects
requires that clients and servers use TCP for lookups. TCP imposes a large
burden on servers (especially busy servers) in comparison to UDP. Add to
that the fact that many DNS systems do not support the use of TCP for
queries whatsoever, meaning that it just won't work with a large number of
systems in the first place. And even if it did work, it would result in
other simple lookups failing, essentially punishing everybody for the
benefit of a single application.

> standard to link each ldap server to each other, which DNS has...

There is some work underway to develop an LDAP infrastructure for the
Internet community, with DNS being used as a stub to kickstart the
process. That will get you the same thing as what you want, but without
crushing DNS as a result.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Bill Manning <[email-masked]>
Date: Sat, 8 Jun 2002 21:44:35 -0700 (PDT)

% I was wondering if the best system to build a global PKI wouldn't be the
% DNS system already in place?
% 
	As others have pointed out, the DNS already has the capability
	to store certs.  So you could use the DNS as a publication 
	method.  But is this the only thing a PKI needs?  How would
	one revolke a cert that was in the DNS?  How can you update
	-every- cached copy of the cert in question? 

	For this (among other) reason(s), the DNS can't really be 
	considered a PKI in any real sense.

-- 
--bill

---

From: Keith Moore <[email-masked]>
Date: Sun, 09 Jun 2002 19:39:25 -0400

> DNS system already in place?

A global PKI is a Bad Idea.  Nobody is sufficiently trustworthy to be the 
root CA.  

Keith

---

From: Michael StJohns <[email-masked]>
Date: Sun, 09 Jun 2002 17:33:32 -0700

Correction:  A single global rooted PKI is a bad idea, a single global (in 
the namespace sense, not a single system) PKI database where we can look up 
certificates is a good idea.

---

From: Keith Moore <[email-masked]>
Date: Sun, 09 Jun 2002 20:57:58 -0400

> certificates is a good idea.

assuming that you can keep the folks who control the TLDs from trying
to sell themselves as authoritative CAs for those TLDs, I mostly agree.  

Keith

---

From: [email-masked]
Date: Sun, 09 Jun 2002 21:18:30 -0400

> to sell themselves as authoritative CAs for those TLDs, I mostly agree.  

Unfortunately, Zymyrgy's Law of Evolving Thermodynamics applies here.
The worms are out of the can, and I suggest anybody who wants to fight
this battle order at least a 4-sizes-larger can....
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: Keith Moore <[email-masked]>
Date: Sun, 09 Jun 2002 21:36:08 -0400

> this battle order at least a 4-sizes-larger can....

these particular worms are still in the can, and it's probably better 
for everyone if they stay there.  

I think it's probably reasonable to use DNS as part of a way to look 
up keys and certs for DNS names, provided the keys and certs only
appear at the leaves.

Keith

---

From: [email-masked]
Date: Sun, 09 Jun 2002 21:57:26 -0400

> for everyone if they stay there.  

I stand corrected.  The company I was thinking of is in both lines of business,
but hasn't succeeded in actually equating them....

/Valdis

---

From: Franck Martin <[email-masked]>
Date: 10 Jun 2002 18:04:45 +0000

I see who you are talking about....

But I think it is a IETF pb to provide an informational RFC to provide a
map between certificate DN and DNS namespace and to provide a mechanism
to look at CERT and CRL Then it is an ICANN problem to implement on the
root-servers and delegate to ohers...

From reviewing the 2 RFCs (CERT and SIG) it appears that DNS protocol
has all which is required now, but needs some structure and
standardisation.

For instance:
In the certificate C= coult be root or the ccTLD or gTLD then O= could
be the rest of the domain name
CN would be the hostname, e-mail address, name of a person (all
belonging to the domain)

an X509 critical key would be use to limit the issue of certificates
outside the domain name.

It is then easy to map the certificate to a CERT DNS entry by doing a
DNS query for the CERT record to O=+C= domain.

The CERT DNS entry allows to use a URI, the URI would point:
1) to the certificate (http://www.sopac.org/ssl/sopac.crt)
2) to the CRL (http://www.sopac.org/ssl/sopac.crl)
3) to the OSCP?

(ldap could be used instead of http)

Lastly using 1) but adding certificate.html?ID=xxx You could retreive
any certificate signed by 1) and then get the public key amongst other
things...

This is a quick write up of ideas, which needs more thinking but, 
1)it provides the mapping between certificates and DNS system
2)it is not heavy on the DNS because it answers a URI and not the
certificate or key or whatever
3)it provides independent way to check CRL without the DNS TTL issue and
caching....
4)http, ldap and DNS are well established protocols that are mostly
enabled via firewalls.

Should such RFC be written?

Cheers.
[email-masked]

On Mon, 2002-06-10 at 01:57, [email-masked] wrote:

    
    /Valdis

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Jun 2002 10:11:30 -0400

> Then it is an ICANN problem to implement on the root-servers and
> delegate to ohers...

ICANN has enough problems already.  Please don't make the situation worse.

---

From: [email-masked]
Date: Mon, 10 Jun 2002 10:28:35 -0400

> be the rest of the domain name

Note that (a)  there's no C= field in 'foobar.com', and (b) you're not allowing
for l= location fields as they may or may not map into 'location.state.US'.

Read RFC2163 for a discussion of mapping X.400 to RFC822, which is a very
similar problem....  It's NOT as easy as you think...
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: Nguyen Thi Mai Trang <[email-masked]>
Date: Mon, 10 Jun 2002 20:32:43 +0200

Hi everybody,

I have a question about class E IP address. I read a book which indicate that
class E IP address has the following format:
1111 xxxx . xxxx xxxx . xxxx xxxx . xxxx xxxx
Thus, the lowest address is 240.0.0.0 and the highest address is
255.255.255.254

Another document I read states that the format of class E IP address is:
1111 0xxx . xxxx xxxx . xxxx xxxx . xxxx xxxx

I try to verify in RFCs of IETF about this but I cannot. I read RFC 790, 791,
796 but they do not mention about it. Could you please give me the RFCs
indicating the format of class E?

In the first case I describe in this message, I wonder why the lowest address
of class E is not 240.0.0.1 because the adress with all 1 and all 0 have
special meanings (all 0 means "this" and all "1" means broadcast).

Thank you very much,
Mai Trang

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 09 Jun 2002 03:54:32 +0200

> and certificates, be quiet).

Both public keys and certificates can already be stored in DNS; see
RFC 2535 and RFC 2538.  RFC 2535 is "editorially" updated to not
include the application public key support any more though.

Since this was CC:d to keydist: I think the keydist effort has been
superseded by reality.  Despite the FUD presented by certain
individuals that doesn't want keys/certs in DNS, people have already
started doing it and it works fine.  The only difference is that the
way people do it is not standardized.

---

From: Bill Sommerfeld <[email-masked]>
Date: Sun, 09 Jun 2002 12:17:32 -0400

> 	-every- cached copy of the cert in question?

you don't need to.  there are in general two options for this sort of
thing:

  1) short lived certs
  2) CRL's published at regular intervals.

both involve a regularly-signed short-lived objects.

						- Bill

---

From: Ben Laurie <[email-masked]>
Date: Sun, 09 Jun 2002 20:34:02 +0100

> both involve a regularly-signed short-lived objects.

Errr - OCSP?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Arne Ansper <[email-masked]>
Date: Mon, 10 Jun 2002 12:24:32 +0300 (FLE Daylight Time)

> > both involve a regularly-signed short-lived objects.

last year we implemented a system that used DNS (with security extensions)
to distribute ceritificate validity information (among other things).

it was a closed system with couple of central servers (primary DNS server
and several secondary servers) running BIND 9 with signed zone files.
other servers (basically specialized firewalls) were running BIND 9 as
caching nameservers that were configured to accept only signed responses.

each valid certificate had a TXT entry in a zone file. the name of the
entry was base64 encoding of the SHA1 hash of the certificate. when
someone wanted to check the validity of some certificate they did a DNS
lookup and checked if the entry existed.

this way we had all the nice (and proven) capabilities of the DNS system
(redundancy and caching) without too much trouble. and it was quite easy
to use at the application level.

arne

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 Jun 2002 13:04:05 -0500

on 6/8/2002 8:54 PM Simon Josefsson said the following:

> Despite the FUD presented by certain individuals that doesn't want
> keys/certs in DNS, people have already tarted doing it and it works
> fine.

Setting aside the issue of whether or not people are spreading FUD,
perhaps you could tell us about your setup. How homogenous were the
applications and operating systems that requested the certs? What resolver
calls did you use? What other RRs were bound to the owner names? How many
delegation entries did you provide along with the data and what was the
message size without the certs? How big were the certs? Did any of the
lookups overflow, and did everything support TCP fallback? and finally, do
you think that the answers will be the same for all nodes across the
global namespace?

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 11 Jun 2002 20:46:17 +0200

(Please respect Reply-To)

> Setting aside the issue of whether or not people are spreading FUD,

I still wish a technical analysis of the consequences would be
performed by those who are critical...  Not using a protocol because
using it increases message sizes and round trips compared with not
using the protocol isn't a very convincing argument.

> perhaps you could tell us about your setup.

I am afraid that will require a shameless plug of my master thesis
(you asked for it! :-)):

http://josefsson.org/master-thesis/

Most answers to your questions can be found in it, but I'll continue
answering your questions specifically:

> How homogenous were the applications and operating systems that
> requested the certs?

Applications were all written in C, altough parsing of responses was
done in Lisp in one application.  OSes was Win2k, GNU/Linux and
Solaris.

> What resolver calls did you use?

One application used the "dig" application and another used
getcertinfo() (I'm not sure OpenBSD ended up with that resolver API
though, but that was a proposed solution back then).

> What other RRs were bound to the owner names?

None, just one or more CERT RRs.

> How many delegation entries did you provide along with the data and
> what was the message size without the certs?

Not many, number and sizes was similar to what you normally find on
the net.

> How big were the certs?

.5-2kb.

> Did any of the lookups overflow, and did everything support TCP
> fallback?

Yes.  Practically all lookups overflow if DNSSEC is used so this
shouldn't surprise anyone. (Try "dig www.josefsson.org a +dnssec".)

TCP (and perhaps also EDNS.0) should probably be a requirement for
those applications and servers that wants to use application keys in
DNS.

> and finally, do you think that the answers will be the same for all
> nodes across the global namespace?

No, there are other operating systems, programming languages, resolver
APIs, other RR owner name setups, different number of delegation
entries, and cert sizes than the ones I tried.

As for all nodes across the global namespace supports TCP fallback, I
would agree with you that they don't, but I would not see how it is
relevant.  Such software would not see this kind of data unless a user
of the server tried to use this stuff, and in that case I don't see
why that user couldn't upgrade her own software to get it to work.  If
users wants IPv6 they install IPv6, they (usually) don't complain that
IPv6 is broken since their IPv4 router doesn't support it.

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Jun 2002 15:13:17 -0700

>also tossing certificates around, let us know...

I must be missing something. As far as I know, the root would not be 
distributing any certificates other than its own. The root would do its 
20K/second/server identification of where the .com/.uk/.se/.whatever 
servers are just as it does now, and those servers would in turn do the 
example.com/etc service they do now, and example.com would reply with its 
key or cert.

The issue would be the signatures on the keys/certs. In DNSSEC, the TLD is 
also an authority (registration or certificate, perhaps both), and has to 
sign a bazillion certificates.