Subject: Re: Global PKI on DNS?

From: "John Stracke" <[email-masked]>
Date: Tue, 11 Jun 2002 18:36:55 -0400

>> Because it's not their software? If I wanted to do PKI through DNS, and 
my
>> ISP's server did not support TCP, I might be stuck.  Personally, I 
don't
>> depend on my ISP for DNS, but many users do.
>
>So users wanting this new service will be pretty motivated to switch DNS
>servers when the time comes, what's the big deal in that? 

The big deal is that some of the more restrictive ISPs may not permit 
customers to bypass their DNS servers.  Same as with HTTP interception 
proxies.

/===============================================================\
|John Stracke                    |Principal Engineer            |
[email-masked]   |Incentive Systems, Inc.       |
|http://www.incentivesystems.com |My opinions are my own.       |
|===============================================================|
|Reality is what refuses to go away when I stop believing in it.|
\===============================================================/

---

From: Peter Deutsch <[email-masked]>
Date: Tue, 11 Jun 2002 16:17:35 -0700

> customers to bypass their DNS servers.  Same as with HTTP interception

And ther are multiple possible answers to that sort of behaviour, none
of which require technological solutions, since it's not a technological
problem. Users can be told "this function is not available from this
ISP, change ISPs" and we let the free market do its thing. Operators of
such a new service can run DNS servers on different ports for this
functionality. There are probably lots of things you could do, but the
fact that a particular ISP is behaving in an antisocial manner shouldn't
be an issue for this list, should it?

Last week I was told by a relative down in Australiaa that his ISP still
scans for multiple hosts hiding behind NAT boxes. OTOH, one of my ISPs
(Earthlink) regularly tries to *sell* me NAT boxes. Neither behavior
would seem relevant to the NAT versus anti-NAT debate on this list but I
happen to rather like the fact that my ISP recognizes that I want run
this technology and doesn't try to treat me like a criminal for doing
so.

Now, it's a bit more tricky when the ISP is doing proxy interception,
but frankly maybe we shouldn't be overloading the current DNS service
with this. I didn't see anything so far in this thread that would
discourage me from using DNS *technology* in this application, but maybe
you would definitely want to set up your own root for this service. It
would get you out from under the many operational restrictions folks put
on DNS for "stability" reasons anyways, and by using a different port
you'd find the proxy/interception issues go away, too.

Sounds like a win for everybody...

				- peterd

-- 
-----------------------------------------------------------------------
   Peter Deutsch                   [email-masked]

   "I had to do an assignment on wild animals, and I decided to
    do my report on alligators. To complete my research, I took a
    trip to the zoo. I wanted to make a day of it, so I took along
    my pet dog. I figured we could throw a little frisbee,
    enjoy the sun, but boy was that trip a disaster. I had to
    tell my teacher that my homework ate my dog..."

----------------------------------------------------------------------

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 Jun 2002 18:34:51 -0500

> customers to bypass their DNS servers.  Same as with HTTP interception 

No, the big deal is that the roots and TLDs would be crippled from
millions of TCP queries for their certs.

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

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 11 Jun 2002 18:51:05 -0600 (MDT)

> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> From: "John Stracke" <[email-masked]>

> customers to bypass their DNS servers.  Same as with HTTP interception 

That's as irrelevant as whether customers of some cable TV system
might not be able to get some new TV network, because they are not
getting Internet service.  No matter what your bill might say, you
are not getting Internet service if you also get interception proxies
or even just port 25 blocking.

Noticing [email-masked] in the CC list of this thread makes me
ponder the compatibility of TLS with SMTP and HTTP interception proxies.

Vernon Schryver    [email-masked]

---

From: David Conrad <[email-masked]>
Date: Tue, 11 Jun 2002 18:00:13 -0700

> millions of TCP queries for their certs.

Why do you think the roots and TLDs would get millions of TCP queries for
their certs?  Why would anyone want to get the certs of the roots or tlds?

These arguments are going beyond silly and reaching ludicrous.  Yes, some
ISPs do stupid things.  That's when you choose a different ISP or come up
with some workaround.  Yes, there are broken DNS servers out there that
can't handle TCP queries.  Get an unbroken DNS server, there are plenty.
Yes, there may be fragmentation issues, however we are going to have to deal
with this if we're ever going to deploy DNSSEC.

Can we stop with the FUD?

Rgds,
-drc

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 Jun 2002 20:15:19 -0500

> their certs?  Why would anyone want to get the certs of the roots or tlds?

Why do you think anybody would cache them long-term if they were right
there handy in the DNS database?

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Jun 2002 23:14:21 -0400

> with this if we're ever going to deploy DNSSEC.

well, all of the above is sort of besides the point, because you really
don't need to use DNS to return certs (and there are a lot of problems
with doing so) - you still get to leverage DNS if you simply define a way 
to use DNS to obtain certs with a different protocol (say, using SRV 
records).  then you don't have to stand on your head to try to fit 
the certs into DNS and/or adapt DNSSEC to the needs of your particular app.

the trust issues are a separate matter.  but again, if you get away from
trying to make DNSSEC do this job then you can just build a query mechanism
for certs that responds to the addresses/ports in those SRV records,
and let each host/site/application decide whether the certs that come back
are sufficient for its particular needs.  and you don't need any kind of
distinguished cert or cert hierarchy to make that work.

of course if DNSSEC can help validate the SRV records, discourage denial
of service attacks on the DNS lookups used to find keys, or provide 
additional means to validate keys, that's all well and good.

Keith

---

From: David Conrad <[email-masked]>
Date: Tue, 11 Jun 2002 21:01:07 -0700

> there handy in the DNS database?

Let me try again.

Why would anyone care about root or TLD _certificates_?  They might be
interested in the root or TLD sig/key records but that is a completely
different thing and unrelated to cert records.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 11 Jun 2002 21:13:47 -0700

On 6/11/02 6:51 PM, "Derek Atkins" <[email-masked]> wrote:

> David Conrad <[email-masked]> writes:
> 
> Just to play devil's advocate, if a resolver was going to track a
> signature chain all the way back up, it's going to have to request the
> KEY/SIG records for all the parent domains all the way back to the
> root.  

Yes.  Thanks.  I'm quite well aware of how DNSSEC works.  Which is
completely unrelated to putting _certificates_ into the DNS.  You don't even
have to DNSSEC sign certificates in the DNS since people put trust in their
CAs.  

There is no reason anyone would care about the root or TLD certificates
(unless they had communication relevant to the root or TLD certificate
owners).  There is nothing stopping anyone from putting their certificates
into the DNS and making use of the DNS characteristics of global
scalability, reliability, redundancy, and caching.  Indeed, it would appear
some people are already doing so.

However, mention PKI and DNS in the same sentence and you get a fascinating
array of knee jerk reactions.  All very amusing except for the fact that the
knee jerking is hindering efforts by folks with valid problems from
standardizing on a (note: not _THE_, _A_) mechanism using the DNS to
distribute key information.

Is it just me or is the IETF becoming the place to not standardize
protocols?

Rgds,
-drc

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 Jun 2002 23:29:27 -0500

on 6/11/2002 11:01 PM David Conrad said the following:

> Why would anyone care about root or TLD _certificates_?

Uhh, because it was requested:

 on 6/8/2002 8:22 AM Franck Martin said the following:

 | The root servers would share the ROOT Certificates and would sign a
 | certificate to each .org .com .net .fr,... managers of this domains...

Other people have given other reasons why this won't work. I'm giving my
reason why it won't work. What people do with their own servers and zones
is fine by me but I'd rather they not crap on the root and TLDs.

---

From: Eric Rescorla <[email-masked]>
Date: 12 Jun 2002 06:49:19 -0700

> distribute key information.

If all you want to do is cram PKIX/X.509 certs into the DNS, the 
question becomes: why?

Nearly all of the major IETF security protocols (TLS, IPsec, OpenPGP)
already have their own certificate discovery mechanism and therefore
have no need to have certificates in the DNS. TLS, in particular,
wouldn't know what to do with them if they were there.

The only IETF security protocol protocol which I can think of that
doesn't have a mechanism is S/MIME. The problem with S/MIME only
exists when someone wants to send an encrypted e-mail to someone 
who you've never spoken to before. (Certificates are already
delivered along with signed messages). But then, I'm not sure
that I see enough deployment of S/MIME or S/MIME certificates to
find this a very compelling argument....

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Derek Atkins <[email-masked]>
Date: 11 Jun 2002 21:51:26 -0400

Just to play devil's advocate, if a resolver was going to track a
signature chain all the way back up, it's going to have to request the
KEY/SIG records for all the parent domains all the way back to the
root.  In other words, resolvers all over the world are going to make
requests to verify the KEY of, e.g. .COM.  So, yes, there may be
millions of requests to the root servers for KEY/SIG records in order
to verify the leaf KEY/SIG record chains.

Hopefully caching will help, but the traffic for "COM. IN SIG" is
going to be a fairly popular DNSSec request, IMHO.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 12 Jun 2002 08:11:07 -0700 (PDT)

> wouldn't know what to do with them if they were there.

This is missing the point.  Sure, TLS provides the ability for both
clients and servers to send certificate chains to their peers as part of
session startup.  But what happens if I'm a client, and the chain the
server sends me ends in a cert that I don't know about?  I *might* be able
to construct a path from one of my trusted roots to one of the certs in
the path it sends me, and hence be able to validate the whole chain and
hence successfully start the session, instead of failing.  But I can do
this only if I can discover certs that *aren't* either in the set it hands
me or in my local set, and TLS says nothing about how to do this.  That's
the problem that people would like to solve to enable more scalable PKI;
it can't be handwaved away.  I'm not particularly a fan of using DNS for
this, but discovery remains important.

 - RL "Bob"

---

From: Eric Rescorla <[email-masked]>
Date: 12 Jun 2002 08:20:03 -0700

"RL 'Bob' Morgan" <[email-masked]> writes:

> me or in my local set, and TLS says nothing about how to do this. 
Yes, because it's an edge case. TLS certificate chains almost always
end either implicitly or explicitly in self-signed certs, which you
either trust or you don't. Trying to chain to some other root is highly
unlikely to work. 

We barely have any PKI at all, I think it's a little early to start
worrying about cross-certification.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2002 12:19:17 -0400

> this, but discovery remains important.

I don't want to discount the importance of cert discovery, but I do
think it's a stretch to believe that you're going to be willing to 
trust all of the certs that you discover in a chain of significant
length, for a significant set of purposes.

Keith

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 12 Jun 2002 09:50:49 -0700 (PDT)

On 12 Jun 2002, Eric Rescorla wrote:

> Yes, because it's an edge case.

So:  "scalability is an edge case".  I will restrain myself from
commenting further on this point.

> worrying about cross-certification.

I'm sure you're aware that many folks, including Your Federal Government,
are designing and building systems that rely on cross-certification even
as we type.  You may think these are doomed to failure (I have my doubts
myself) but you can't deny that they have requirements to meet.

 - RL "Bob"

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 12 Jun 2002 09:57:06 -0700 (PDT)

On Wed, 12 Jun 2002, Keith Moore wrote:

> think it's a stretch to believe that you're going to be willing to trust
> all of the certs that you discover in a chain of significant length, for
> a significant set of purposes.

So do you think that there's a necessary difference in trustworthiness
between the certs that you "discover" when you take your computer out of
the box, or download the latest browser, and those that you would discover
via some lookup mechanism?  Even if the certs discovered via that
mechanism were associated with policies based on explicit agreements
and terms of use between your organization and the various issuers?

 - RL "Bob"

---

From: Eric Rescorla <[email-masked]>
Date: 12 Jun 2002 10:03:55 -0700

> commenting further on this point.
Good, because that's not what I said.

I expect peers to send full cert chains to a small number of common
roots. There's no reason this can't be made to scale, and since
it's the only thing that works at all now, there's every reason to
expect that it's what we'll continue to be using in the future.

> myself) but you can't deny that they have requirements to meet.
As you say, I think that those systems are doomed to failure. Even if
I didn't it's not at all clear to me that the number of cross-linking
certificates is going to be anywhere near large enough to require
them to be fetched via DNS.

-Ekr

---

From: David Conrad <[email-masked]>
Date: Wed, 12 Jun 2002 10:03:36 -0700

On 6/12/02 8:20 AM, "Eric Rescorla" <[email-masked]> wrote:
>> But I can do

Scalability as an edge case.  Hmm.

> We barely have any PKI at all,

Actually, it would appear we barely have a bunch of different,
non-interoperable, non-scalable PKIs.  However, since I'm not a card
carrying credentialed security person, I'm probably mistaken.

> I think it's a little early to start

I think it is more than a bit late.

Rgds,
-drc

---

From: Eric Rescorla <[email-masked]>
Date: 12 Jun 2002 10:15:09 -0700

> Scalability as an edge case.  Hmm.
Well, I see that you're as confused about what I said as Bob was.

If you have a singly-rooted cert hierarchy, then you always can
provide an explicit path to a known root. This scales extremely
well. 

> I think it is more than a bit late.

I guess we'll just have to differ here.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2002 13:15:34 -0400

> and terms of use between your organization and the various issuers?

no, I think there's likely to be a difference in the trustworthiness
of a short chain of certs involving a small number of other parties 
vs. that of a long chain of certs involving a larger number of other
parties.  and if the cert discovery mechanism can incorporate 
personal and/or site policy, that's great - as long as it knows 
which policy to use under which circumstances.  

in general I think the longer the cert chain, the narrower the applicability.

Keith

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 12 Jun 2002 19:44:08 +0200 (CEST)

could we perhaps move this discussion to [email-masked]?

	jakob

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Jun 2002 14:23:29 -0400

>in general I think the longer the cert chain, the narrower the applicability.

I think that it is an oversimplification to argue that shorter chains 
are necessarily less trustworthy than longer ones, and this seems 
especially true in this context.

if one were to create a PKI paralleling the DNS, each CA would 
correspond to a component of a DNS name and each of those points is 
authoritative for the naming of the entities under it. this is not a 
new notion introduced by making a PKI parallel to the DNS, but is an 
intrinsic feature of the DNS design. if one chose to create such a 
PKI, the CAs would not be trusted third parties in the common sense 
of the term. they are precisely the entities that are responsible for 
managing their parts of the DNS name space and are implicitly trusted 
to do so.

Those who have argued against a single root in general should note 
that there are ways to have multiple entities act in a coordinated 
fashion to sign on behalf of a root, which mitigates the security 
concerns associated with what might appear to be a single root. But, 
that does not diminish the problems noted earlier re increased 
traffic for TLD DNS servers, etc. I'm just addressing tyhe security 
aspects of a DNS-based PKI. Also even if one were to have a singly 
rooted DNS, that does not make it the only game in town, i.e., there 
should be lots of other PKIs, each with its own root and serving a 
well defined constituency.

Steve

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 12 Jun 2002 11:56:33 -0700

>could we perhaps move this discussion to [email-masked]?

Yes we could, but whether or not people want to is another question.

As for the people who have made comments about "it would be nice to 
be able to discover paths to trusted roots", please be advised that 
the PKIX WG is working on this. In fact, it has been the 
most-discussed topic in the WG lately. Yes, it has been discussed 
there for a few years, but it appears that in the fine IETF 
tradition, convergence through attrition is happening.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Ben Laurie <[email-masked]>
Date: Wed, 12 Jun 2002 19:53:50 +0100

> length, for a significant set of purposes.

We're already trusting chains of signficant length (i.e. DNS delegation)
with no decent verification at all. I presume I'd be prepared to trust
certificate chains of that kind of length for those kind of purposes
even more than I trust the current system.

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: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2002 16:48:41 -0400

> especially true in this context.

indeed, I'd agree.  but that's not quite what I said.  I said it's
a stretch to expect most apps to be able to make use of a long cert
chain because of the natural difficulties in trusting so many other
parties.  the implication I was trying to make was that being able 
to look up missing certs in a long cert chain was only a weak 
justification for a cert lookup mechanism, rather than a strong one.

it's not as if I'm opposed to a cert lookup mechanism, or that I think
it's nearly useless - but I do think we need to be realistic about
its limitations.

> managing their parts of the DNS name space and are implicitly trusted

right, that doesn't mean they're trustworthy. e.g. but just because 
the maintainer of (say) COM presumably knows and can authoritatively 
state that FOO.COM has certain properties, doesn't mean that I am 
willing to trust this maintainer to not (accidentally or deliberately)
return false information about some BAR.COM, or to (accidentally or 
deliberately) leak keying material with which a rogue other party 
could claim to make assertions about BAR.COM.

actually history would cause me to seriously question the trustworthiness
of certain TLD registries even though there is on doubt as to whether
they are authoritative for those TLDs.

> well defined constituency.

I don't have an inherent problem with using DNS as part of a means to 
allow clients to find CERTs that bind properties to DNS names.

(I do have some concerns about DNS being the entire mechanism - but
the devil is in the details.  I'm skeptical that everything can be
worked out satisfactorily, but if it can, just using DNS might
actually be okay.)

OTOH the "single root" (or if you prefer, "distinguished root") is so
fundamentally flawed that I would consider it unacceptable for 
standards-track.

Keith

---

From: Chris Evans <[email-masked]>
Date: Wed, 12 Jun 2002 21:45:36 -0700

Then a global PKI protocol server needs to be invented so you can just get the 
certs from the domain in question.   i dont wanna see DNS system bogged down by 
this stuff. IMHOOC!

use dns to get the IP and request from its IP the pki doc.. duh.

---

From: Einar Stefferud <[email-masked]>
Date: Wed, 12 Jun 2002 22:42:06 -0700

May I suggest that someone do a little work on proving the trust is 
transitive, as that is what this is really all about, and if it turns 
out that trust in not transitive, then what was the point?

Maybe if you ask Google about trust transitivity, you all might learn 
something;-)...

Cheers..Stef

PS:  I trimmed the address list to just IETF;-)...\s

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Jun 2002 09:47:42 -0400

At 10:42 PM -0700 6/12/02, Einar Stefferud wrote:
>transitive, as that is what this is really all about, and if it 
>turns out that trust in not transitive, then what was the point?
>
>Maybe if you ask Google about trust transitivity, you all might 
>learn something;-)...
>
>Cheers..Stef
>

Stef,

Trust generally is not transitive, but cert chains are not about 
transitive trust. The DNS is a hierarchy with clear lines of 
authority for name spaces. A PKI modeled on the DNS would parallel 
the existing hierarchy and merely codify the relationships expressed 
by it in the form of public key certs.

Steve

---

From: Einar Stefferud <[email-masked]>
Date: Thu, 13 Jun 2002 09:08:37 -0700

I understand clearly about chains of authority and about the lack of 
trust transitivity.

What makes a DNS delegation of naming zone authority into a trust 
transitivity vehicle.

Why should I trust VeriSign to vouch for my reasons to trust you?

When you turn out to have a bogus CERT, after I have trusted you, and 
I go to VERISIGN seeking redress for trusting them and their breach 
of my trust, what do they offer me other than the simple statement 
that

	"Go away!  You do not have a contract with us!"
	"Our contract is only with the CERT holder!"
	"And we have disclaimed all liability to him as well."

And when I go to ICANN for redress, because they supposedly vouched 
for their delegated authority to run a DNS Zone, they say:

	"Sorry, this has nothing to do with us!"
	"We are not a party to any liability here!"
	"We only deal with DNS Zones, and do not
	 Vouch for the data contained there-in,
	 because we do not verify it in delegated zones!"

So, what is it about DNS delegations that give you reason to inform 
this list that trust is transitive in the DNS?

I see nothing in any part of this combined DNS and CA set up that 
offers transitivity of trust (of any kind), that was not already 
there (outside of the DNS zone data assertions) before DNS and the CA 
were somehow informally lined up by some kind of IETF (3rd party 
without direct participation) protocol declaration, which in no way 
bears any liability to any party relying in  the DNS/CA information 
structures.

The last time I saw any trust transitivity, it was in the SPOOK 
industry, where subordinates agree in contracts (sometimes verbal) to 
trust their handlers.
that is, they overtly agreed to make trust transitive between 
themselves, even if it might cause their death.  Apparently, the 
agent is paid to assume the risks.

Now, where in the DNS does anyone assume that kind of liability?

Thus, I want someone to explain why trust is transitive in the DNS/CA 
combination
of Domain Naming Authority trees naming authorities and CA CERT issuers.

Quite frankly, I find myself with little or no trust in any of the 
current PKI certs, except for my use of them in SSL/TSL connections 
which is one case where they work to provide a trusted channel 
between two parties, but do not do anything to induce trust between 
those parties.  Any trust must derive from other channels of 
information flow.

Remember that self assertion of trust is not reliable.  \

	Remember "Trust Me!" jokes!

Tell me, why do you laugh when the car salesman says "Trust Me!".

Now, please explain, with more than brief hand waving, how trust is 
transitive in your vouching for the transitivity of trust in a 
DNS/PKI marriage?

What liability do you assume if I trust your advice?

Enjoy;-)...\Stef

---

From: Ed Gerck <[email-masked]>
Date: Thu, 13 Jun 2002 09:32:06 -0700

Stef's point that PKI cannot represent trust relationships
is deflected -- but not denied -- by Kent. Does this mean
that we can have a global PKI on DNS?

No.

I believe that Kent is right when he says that PKI deals with a
chain of authority, not a chain of trust.  This may seem to be an
arcane point but a chain of authority can be defined by a
self-reference and can be propagated from a single reference
to a single reference whereas a chain of trust cannot, in both
counts.  Indeed, a PKI hierarchy (and chain of authority)
is very similar to the DNS hierarchy and zone delegation
system.

There is a nit, however.

A PKI modeled on the DNS would fail to work as a PKI.  Contrary
to the DNS and as an "infrastructure", a PKI should be able to
accept --  and use -- multiple roots.   But there is no concept  of
"cross CA" certification in the DNS, which would be akin to
routing across multiple roots in the DNS. In fact, this is exactly what
the  ICANN folks set out to prevent...

Cheers,
Ed Gerck

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2002 13:43:10 -0400

> A PKI modeled on the DNS would parallel

so what you're saying is that the cert would mean something like:

"we certify that this key was supplied by a party who gave us money
in exchange for our assigning domain name x.y to it.  we have no
idea who that party really is, whether it is trustworthy, and 
in particular whether that party can be trusted to manage its keys
in such a way as to make compromise unlikely.  for that matter,
we're not even entirely sure whether the party that gave us money
for this domain last time it was renewed was the same as the party 
that gave us money for the domain in the past.  for that matter,
we didn't get the money directly from that party, we got it from 
a registrar who you may or may not be able to trust either.

and for that matter, you have no idea whether we are trustworthy.
we could be making all of this up, and in fact we're so large and
control the trust relationships to so many domains that there is
a fair amount of incentive for us to do exactly that under some
conditions, but we won't tell you want those are  but you should 
trust us anyway, because we said so"

Keith

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Jun 2002 14:15:38 -0400

>I understand clearly about chains of authority and about the lack of 

The rest of your message strongly suggests that you don't.

>What makes a DNS delegation of naming zone authority into a trust 

I assume there was an implied question mark above.

>Why should I trust VeriSign to vouch for my reasons to trust you?

I think you may be falling into a common trap, i.e., assuming that 
PKIs must be based on explicit trust in CAs. A trusted third party 
public CA, which is what VeriSign is primarily know as, does require 
explicit trust, because it is not authoritative for the identities 
for which it vouches. However, the entities that operate domains in 
the DNS are authoritative for the names in their subdomains. If they 
act as CAs, there is no explicit trust requirement. With suitable 
controls (specifically, use of the NameConstraints extension) these 
CAs can not issue certs (that will be considered valid) for entities 
outside of their name spaces. Thus they cannot do any worse than they 
can do today, in terms of basic assertions about the binding between 
a name and an address. The primary motivation I see for a DNS-based 
PKI is to provide a basis for better security for these bindings, in 
support of PKI-enabled applications.

>When you turn out to have a bogus CERT, after I have trusted you, 
>and I go to VERISIGN seeking redress for trusting them and their 
>breach of my trust, what do they offer me other than the simple 
>statement that
>

Are you referring to VeriSign as a public CA or VeriSign as the owner 
of NSI, and operator of .COM and several other TLDs? There is a big 
difference.

In either case, you seem to be assuming that liability must be 
associated with issuance of these certs, which need not be the case. 
not all certs are for use with applications that support 
non-repudiation. one could adopt a cert policy, and express it in the 
DNS certs, to minimize the liability associated with their use. if 
the goal is to use certs to improve the quality of host & user 
authentication, that need not imply any new liabilities compared to 
what is implied by current DNS management.

>this list that trust is transitive in the DNS?

You are the one who keeps saying that trust is transitive. I'm the 
one saying that it's not, and that a DNS-based PKI does not imply 
transitive trust.

<rest of message deleted, since it didn't say anything new, 
constructive, or generally relevant to the topic ...

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Jun 2002 14:15:42 -0400

>a registrar who you may or may not be able to trust either.

you're putting words in my mouth, and they're not especially good words :-).

>trust us anyway, because we said so"

Why does everyone keep thinking that explicit trust is an essential 
element of every PKI?

A CA that attests to the accurate binding of a DNS name to an entity 
is making NO assertions about the trustworthiness of that entity! It 
is just asserting that the private key corresponding to the public 
key in the cert is held by the entity, period. Whether that entity 
does a good job of protecting the private key is not known to the CA 
(that's generally true in ANY PKI anyway).

A modest, realistic ambition for a DNS-based PKI would be to improve 
the security of the binding between DNS entries and the associated 
machines. That would help with the deployment of all major security 
protocols that use certs: TLS/SSL, S/MIME, and IPsec. It would enable 
organizations to more readily create extranets and intranets using 
these security protocols. Note that, with the possible exception of 
S/MIME, the other protocols do not support non-repudiation, and so 
some of the stickier legal issues associated with the use of certs do 
not necessarily arise. Even for S/MIME, one can distinguish between 
messages signed for authentication vs. for NR purposes.

Steve

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2002 14:47:07 -0400

> machines

yes, I think this is right.  it eliminates some kinds of threats. but 
it still doesn't guarantee that you're talking to the service you think 
you're talking to. and that's a difficult distinction to communicate 
to users.

that and putting this much trust in the registries makes them very
attractive targets.

Keith

---

From: Ed Gerck <[email-masked]>
Date: Thu, 13 Jun 2002 12:01:07 -0700

> so what you're saying is that the cert would mean something like:

;-) actually, to a lawyer, a PKI cert says something like:

    "By issuing this certificate We state in accordance with the rules which We
     make and vary as We think fit for that purpose from time to time without
     accepting any obligation to any other person (including any Internet
     standardization entity) for the effect or consequences of Our choice of
     those rules or of Our variation of them, hereafter called "CPS," that:

     1. The text string herein designated 'name' contains the string received by Us
     from a person, entity or machine, hereafter called entity, claiming it as that
     entity's name.

     2. We may have taken some measures at some time to receive evidence (which
     We may not have preserved and may not be able to produce) of a
     connection between the name and the entity from whom it was apparently
     received.

     3. We have reproduced the string as We believe that We received it, which
     We have denoted and formatted as to Our exclusive understanding of it,
     of its context and of its validity, as regulated by Our CPS.

     4. We may have tested the bit string herein designated 'key' to test whether,
     at the date appearing in this certificate, it appears to correspond to a
     counterpart apparently available to the entity from whom We apparently
     received the name.

     5. We are whom We claim to be.  This claim can be verified by checking Our
     signature on this certificate We supply with a key which We claim to be Our
     public key.  We do not offer you any grounds for believing that the public
     key in question is Our public key or that it has not been revoked before
     or after the date of signature of this certificate.  The only evidence We
     provide of the correctness of the date of signature stated in this certificate is
     that it is dated before the date on which you are reading this certificate.

     6. We may revoke this certificate at any time without telling you or anyone
     else.  The fact that you have downloaded this certificate from Our server
     does not mean that it has not previously been revoked. The fact that no
     revocation for it can be found in Our server does not mean that this
     certificate is valid either.

     7. You may rely on this certificate only at your own risk, and by so doing
     you confirm your acceptance of the conditions subject to which it is issued
     as stated in the CPS for the time being in force, which is not to be
     construed as any obligation regarding the time this certificate was signed by Us or
     used by you.  These conditions include terms prohibiting you from claiming
     to be inadequately qualified or trained to understand or apply the conditions,
     or to have relied upon Us as an expert, or that you were forced to rely on
     Us through lack of information with which to verify Our statements, or that
     you were forced to rely on Us through lack of choice by any reason such as
     the named entity's lack of alternatives for certificates, the browser's lack
     of alternatives for embedded root keys, etc.

     8. What public-key cryptography has joined, may time and machines not part,
     but of such binding We provide no assurance.

     In  Honor of Our Root-Certificate, which attests to Our faith in the
     Root-Key, until We decide to revoke them but maybe not both."

For a user's view, check http://www.mcg.org.br/x509cert.htm

Cheers,
Ed Gerck

---

From: Harald Koch <[email-masked]>
Date: Thu, 13 Jun 2002 15:32:52 -0400

Of all the gin joints in all the towns in all the world, Stephen Kent
> Why does everyone keep thinking that explicit trust is an essential 

If the reasonably intelligent, technically skilled persons in the IETF
can't "get it", what makes you think anyone else will?

-- 
Harald Koch     <[email-masked]>

---

From: Einar Stefferud <[email-masked]>
Date: Thu, 13 Jun 2002 14:54:33 -0700

At 2:15 PM -0400 6/13/02, Stephen Kent wrote:

[snip]... [snip]... [snip]... [snip]... [snip]... [snip]... [snip]... [snip]...
>constructive, or generally relevant to the topic ...

I am simply astounded.  Where in my texts have I said that trust is 
ever transitive.

I asked on for an explanation of why some in this list think trust is 
transitive.
And I cited the only instance I can think of where it might be 
transitive by mutual agreement between a SPY and her handler!  But 
this is not to be construed as my "saying that trust is transitive."

If you can find he message and the text where I state that trust is 
transitive. please return the message to me so I can compare it with 
the copy of it that I kept in my outgoing mail folder.

For clarity, I will now more simply restate my QUESTION:

Explain for me (and others here) how trust is ever transitive!

That is what I am really driving at.  I don't think you can prove it.

Cheers...\Stef

---

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Jun 2002 07:40:54 -0400

>can't "get it", what makes you think anyone else will?

The technical skill of most of the individuals in this debate is not 
in the area of security. Also, there has been a very big PR campaign 
for many years that was designed to cause people to equate explicit 
trust and PKIs, because those who funded the campaign were public CAs 
requiring such trust. That campaign has been effective in creating a 
perception among many folks, technical or not, intelligent or 
otherwise, and it is this perception that clouds this discussion, in 
large part. But, on any case, it is not necessary for everyone to 
"get it" for everyone to "use it."

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Jun 2002 08:03:28 -0400

>you're talking to. and that's a difficult distinction to communicate

It is unlikely that we can ever create a system that ensures that 
every user is " talking to the service you think you're talking to" 
because users can make all sorts of mistakes in trying to express who 
they really want to talk to. That's why I think it makes sense to 
settle for a more modest aim, i.e., authenticating that you are 
connected to the entity registered with the DNS name that you 
asserted that you wanted to talk to.

>that and putting this much trust in the registries makes them very

Which registries? DNS servers are already attractive targets. Absent 
other forms of strong authentication, we rely on the integrity of the 
DNS to ensure that we are talking to who we ....

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Jun 2002 07:55:07 -0400

At 2:54 PM -0700 6/13/02, Einar Stefferud wrote:
>I asked on for an explanation of why some in this list think trust 
>is transitive.

Stef,

I should have said that you are the one who keeps focusing on the 
question of whether trust is transitive, not that you said it was 
transitive.

You keep trying to cast this as a debate about the transitivity of 
trust, and I keep saying that it is not.

I made a slight type in my message, as you cited above.

You keep ignoring what I have said about the irrelevance of trust in 
a PKI where CAs are authoritative for the data they bind into certs.

As Tina Turner would have said, "What's trust got to do with it?"

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Jun 2002 08:15:10 -0400

Ed,

>      those rules or of Our variation of them, hereafter called "CPS," that:

Good start.

>      from a person, entity or machine, hereafter called entity, 

Note that we are talking about certs with DNS names, not general DNs, 
and the DNS name is precisely what any DNS admin already asserts is 
accurately represented in the DNS sever he/she manages.

>      connection between the name and the entity from whom it was apparently

Again, because of the name space in question, and the intrinsic 
limitations on what names can be asserted as one goes deeper in the 
hierarchy, the issue you cite here is not that big a deal.

>      of its context and of its validity, as regulated by Our CPS.

Formatting is well defined and limited in DNS names, e.g., they are 
restricted to a restrictive, caseless character set (prior to 
internationalization).

>      counterpart apparently available to the entity from whom We apparently

Whether POP was employed or not should be part of the CPS, as you 
know, so this point is inappropriately vague.

>      that it is dated before the date on which you are reading this 

Except at the root, the CA is who the next higher tier has verified 
it to be, which is precisely what the DNS asserts today, but without 
any security mechanisms for assurance.

>      of alternatives for embedded root keys, etc.

And how would this be worse than relying on unsecured DNS responses?

>      Root-Key, until We decide to revoke them but maybe not both."

Again, if one established a PKI that paralleled the DNS, item 8 would 
apply to only one point in the system, and that could be managed in a 
parallel, distributed signature fashion.

I think your sample CPS, while more than a little tongue in cheek, is 
a good example of what a CA may assert. But, in the DNS context, many 
of the issues you note are much less serious concerns than in a 
general CA context, because of the existing limitations on the names, 
the existing semantics associated with names by the DNS, ...

Steve

---

From: Einar Stefferud <[email-masked]>
Date: Fri, 14 Jun 2002 09:27:09 -0700

Thank You Steve for clarifying your simple little error and 
correcting the record on what I did or did not say.  I admit that the 
error was small in commission but you must admit that it was huge in 
affect, so it is good for you to corrected the record.

I will assume that it was not intentional.

Now, all I did was ask you to offer proof that trust is ever 
transitive, as a separate sub-question of the general debate, because 
in my view, this question is central to the reasons for bothering to 
discuss the rest of this thread.

In short, if trust cannot be proved to be transitive, like DNS zone 
control delegation is transitive, then there is no reason to continue 
with PKI designs that ASSUME TRUST IS TRANSITIVE.

So, this (Trust Transitivity possibility or impossibility) is:

1. not an unreasonable question; and

2. not yet answered; and

3. still the same central question that it always was and is; and

4. still critical to the entire outcome of this whole discussion thread.

In other words, it is the critical meta question that needs to be 
answered by someone who can offer proof of their conclusion.

So, I take your refusal to consider that it is an important question 
to mean that you do not care if it is a central question, and that 
you do not have an answer of any kind, including the possibility that 
the answer is that "Trust is never transitive".

This completely sums up my issue of trust transitivity, and with this 
observation, I have completed my participation in this aspect of this 
discussion thread.

As long as you (or someone else) cannot or will not answer this trust 
transitivity question, as simply stated as it is, I have nothing more 
to add.

So, now, the podium is yours to do with as you wish.

My conclusion is that you cannot and will not prove that trust is transitive.

I doubt that anyone can because I believe it to already be proven that

				"TRUST IS NOT TRANSITIVE",

So further argument on this point only has to do with your position 
of not wanting to, or your being unable to ---	ANSWER THE QUESTION.

Over and Out;-)...\Stef

>>transitive. please return the message to me so I can compare it 
>>with the copy of it that I kept in my outgoing mail folder.
>>

---

From: Ed Gerck <[email-masked]>
Date: Fri, 14 Jun 2002 09:29:34 -0700

Stephen Kent wrote:

> <snip>

Steve:

I am in substantial agreement with your comments, especially the last one
above.  However, as I commented earlier, I believe that the DNS and the
PKI models are incompatible IF you truly want to have a PKI.  The reason
is that a true PKI would need to work with multiple roots while the DNS
cannot do it.  HOWEVER, since Verisign de facto controls the DNS
name space (the space that matters, anyway) AND is a CA, there is
a possibility (some might say the danger) for Verisign to use this
position to de facto control a quasi-PKI space and the domain name
space.

As a last comment, and already abusing the list patience, we need to
reinvent/revisit PKI! Changes are needed also in the DNS.

One just needs to take a look to the PKI space (and sales) to realize that
it is at a dead end, topped off. PKI experience is proving my assertion of
5 years ago that PKI cannot scale beyond a certain size and only  works
in a friendly context, or in one where liabilities to the user are utterly denied
(in the military or as US law still allows -- "user beware").

Thus, perhaps the DNS PKI experience will be good, after all. It may help
increase/motivate the need for reinventing both, PKI and the DNS.
Perhaps, in this new design,  we will be able to build in that elusive trust,
which has evaporated.

Cheers,
Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Jun 2002 13:04:23 -0400

Ed,

>position to de facto control a quasi-PKI space and the domain name

Could you elaborate, perhaps privately, with why you believe a "true 
PKI" needs multiple roots?

>Perhaps, in this new design,  we will be able to build in that elusive trust,

As you can tell from my messages, I have a broad view of what PKIs 
are and what they are good for, and so I have a different spin on the 
relative lack of success re PKI deployment. My view is that too many 
folks have tried to get too much out of any single PKI, and that has 
caused a lot of our headaches. if we admit to the need for many PKIs, 
each serving a well-defined user community, then I think each of 
these PKIS would be easier to create, manage, and deal with from a 
liability standpoint.

if I look in my wallet, I have a lot of credentials, each issued by a 
different organization. Each is useful only in certain contexts. Each 
tends to uniquely identify me via a number of some sort and often 
that number is meaningful only in the context for which the 
credential was developed. We would be in pretty good shape if we had 
PKIs that parallel these paper and plastic credentials. The security 
would be better and with good software, the convenience would be 
better for users.  Trying to create a single PKI that issues a cert 
that replaces all of these credentials is just not going to work.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Jun 2002 13:13:52 -0400

Stef,

>correcting the record on what I did or did not say.  I admit that 
>the error was small in commission but you must admit that it was 
>huge in affect, so it is good for you to corrected the record.
>

no, it was not intentional.

>transitive, as a separate sub-question of the general debate, 
>because in my view, this question is central to the reasons for 
>bothering to discuss the rest of this thread.
>
>control delegation is transitive, then there is no reason to 
>continue with PKI designs that ASSUME TRUST IS TRANSITIVE.

	<snip>

The essence of our disagreement is that I don't view the relationship 
between the CAs in a DNS-based PKI to be one of trust. We rely on DNS 
admins to correctly bind addresses to names in the zones they 
control. This is the seenace of the semantics of DNS operation. If 
these folks acted as CAs, we would rely on them in the same fashion 
to bind the same names to public keys, which just provides a secure 
mechanism to effect the binding of the name.  If we don't call the 
first relationship trust, then I don't feel we should call the second 
one a trust relationship either.

You uses the term "delegation" above and that's critical. In a system 
like DNS which makes clear who is authoritative for which names, I 
don't think the term "trust" is applicable, and that is the crux of 
our disagreement.

Pn a less polite note, your line of argument has been to saddle me 
with a need to prove something that I have never asserted, which is 
pretty silly, at best. It's not surprising that I continue to decline 
to take a side of a debate that you have tried to define for me and 
which does not represent my position.

Steve

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 14 Jun 2002 13:06:37 -0500

on 6/14/2002 11:29 AM Ed Gerck wrote:

> since Verisign de facto controls the DNS name space

Having any [registry-X] control [TLD-Y] at any given moment is a whole
'nother set of issues. EG, if the registry operator for a TLD changes,
would the private key linked to the TLD also need to be changed?

I'd say that the only way to meld these technologies is to use DNS as a
locator for a self-signed root certificate associated with a domain.
Caveat being that even then you are at the mercy of the signer. You don't
know if you are talking with [email-masked] or if you are really talking
to [email-masked] who has access to the repository. Likewise, you don't
know if you are talking with mailserver.example.com or if you are talking
to bofh-pc.example.com. And there's still the problem of ensuring the
integrity of the link between the DNS referral and how you get to the CA
authority; maybe [email-masked] has hijacked the target machine,
or maybe he is running a different copy of the zone and is happy to
redirect "only" half of the traffic.

About the only thing you could use this for is to prove that you aren't
talking to something -- they haven't been able to obtain a copy of the
private key, legitimately or otherwise -- meaning that it would
essentially be PTR/A validation on steriods. It could also be useful for
negotiating transport security services and a limited amount of identity
information (similar to what you get from PTR/A validation) but would not
be useful for any explicit identity information. Some sort of external
notary service is still necessary for that.

Of course the universe is at the mercy of network operator integrity
already so maybe this is ok.

---

From: Ed Gerck <[email-masked]>
Date: Fri, 14 Jun 2002 11:30:34 -0700

Stephen Kent wrote:

> My view is that too many

Steve:

You have answered your own question above. As you say,  folks have
tried too much out of a single PKI and failed. That is why a true PKI (ie,
one that works as an infrastructure) would need to include many PKIs.
Each one of these "many PKIs" represents one root, with multiple
PKIs creating multiple roots. Now, unless you want each one of these
many PKIs to be isolated -- and not create an infrastructure --  there
is a need for cross-certification allowing users of one PKI community
to talk to users of another PKi community. In DNS parlance, you need to
find AND validate routes among multiple roots.

> PKIs that parallel these paper and plastic credentials.

Agreed. The fundamental problem is that the PKI architecture cannot
directly provide mutiple root functionality. You need to overlay bridge
CAs and other artifacts in order to create the paths.  Now, imagine a
different mathematical structure, one that is not based on a hierarchy
and yet works with hierarchical systems (as well as non-hierarchical
systems liek a peer-to-peer network). Such structure could allow paths
to be found, and validated, from one hierarchy (PKI, DNS) to another
(PKI, DNS).

Someone may add that the DNS is not really a hierarchy, it is just an
ontology.  My argument still holds for ontologies and also applies
to how names are used in PKI certificates (as I have discussed
elsewhere, see google). A certificate is just an authenticated assertion
made within the context of a name space. The name space in a PKI
forms an ontology and that ontology  is defined by name space
ownership, just like in the DNS.

> The security

Agreed again. What we may see, because it is the only thing that will
work, are small PKIs using the DNS as a "directory".  These PKIs do
not need to interoperate and so they will be useful.  But one will not
see a single PKI that issues certs for all the DNS space.  For that we
would need a different beast.

Cheers,
Ed Gerck

PS: IMO the PKI market has been grossly exaggerated.  There are only
30,000 servers worldwide that can do SSL -- which limits PKI server certs
to that number worldwide, with a factor for virtual server usage. PKI
client certs have the private key problem, that cannot be solved by
PKI, and has not really taken off (except for military apps, with smart
cards controlling access to the private key).  And I am not the only
saying that PKI is at a dead end.  Which is good -- because now
perhaps some serious consideration will be given to solutions.
PKI is not dead, though. It is just at a dead end.

---

From: Einar Stefferud <[email-masked]>
Date: Fri, 14 Jun 2002 11:58:31 -0700

Hi Steve -- Now we are beginning to connect with the real meta issue.

I am talking about "Trust Transitivity" in general.
We agree that the DNS offers no trust functions, useful or otherwise.
So, my focus is not on PKI as related to DNS, which is what you addressed here.

It the fundamental issue of trust transitivity in PKI.

I will concede that PKI is transitive in terms of "connectedness" as is DNS.
Both have relations of relatedness, but this does not confer 
transitivity on trust.
Trust still has to be earned, not awarded, in any case.

I am questioning the validity of the widely held assumption that trust is
(or can be) transitive in PKI (or anywhere for that matter).

So, back to my basic question:

Is trust transitive anywhere under any conditions?

I question that it is, until someone proves that:

	"Trust is transitive somewhere/anywhere in real life";

and then prove that:

	"Trust is transitive in PKI Theory";

and then prove that:

	"Trust is transitive in PKI reality".

HINT:  It will help if you can refer to some Formal Logical Theory of TRUST.

First, forget PKI and forget DNS, and show that trust is transitive 
somewhere under some describable conditions.  Then show that trust is 
transitive in PKI.

I know that many people assume that Trust is transitive in PKI.
I am not asking about popular opinion here.
We need some formally logical facts.
If you have some, please show them to us.

Cheers...\Stef

At 1:13 PM -0400 6/14/02, Stephen Kent wrote:
>The essence of our disagreement is that I don't view the 
>relationship between the CAs in a DNS-based PKI to be one of trust. 
>We rely on DNS admins to correctly bind addresses to names in the 
>zones they control. This is the seenace of the semantics of DNS 
>operation. If these folks acted as CAs, we would rely on them in the 
>same fashion to bind the same names to public keys, which just 
>provides a secure mechanism to effect the binding of the name.  If 
>we don't call the first relationship trust, then I don't feel we 
>should call the second one a trust relationship either.
>
>You uses the term "delegation" above and that's critical. In a 
>system like DNS which makes clear who is authoritative for which 
>names, I don't think the term "trust" is applicable, and that is the 
>crux of our disagreement.
>
>pretty silly, at best. It's not surprising that I continue to 
>decline to take a side of a debate that you have tried to define for 
>me and which does not represent my position.
>
>Steve

---

From: Eric Rescorla <[email-masked]>
Date: 14 Jun 2002 12:06:28 -0700

Ed Gerck <[email-masked]> writes:
> to that number worldwide, with a factor for virtual server usage.
These numbers sound quite low. Netcraft's 2001 SSL survey reported
500,000 SSL sites with 121,000 of those having valid third
party certificates.

Heck, Netcraft's April survey shows 41,000 installations of Stronghold
alone, all of which can do SSL.

-Ekr

---

From: Ed Gerck <[email-masked]>
Date: Fri, 14 Jun 2002 12:34:07 -0700

Eric:

Thanks for your clarification.

But CAN DO is not DO.  Many SSL-capable servers
are not actually using SSL ( looks like a factor of 10:1).

Second, the number 30,000 that I cited was for servers, not web
sites, where you need to factor in the virtual servers (as I
commented). That number comes from 2001 data published by
Certicom and other sources (eg -- company leaflet).  True,
NCipher for example reports that Netcraft's SSL survey for
October 2001 counted over 140,000 web sites offering SSL
connections  with valid server certificates.  Still, when you
count web sites (not just servers), don't you think that
140,000 certs/year (of which close to 20% have key lengths
shorther than 640 bits) is a very very low number of customers
to divide among all those companies selling servers certs?

In short, IMO what is important here is that the PKI server cert
market is a pin head market that does not justify all the bloated
expectations around it. It simply does not size up.

Cheers,

Ed Gerck

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Jun 2002 12:40:16 -0700

> are not actually using SSL ( looks like a factor of 10:1).
The January 2001 Netcraft report I'm citing had 500,000 sites that
were offering SSL (albeit many with bogus certificaes). I'd be very
surprised if that was a 15:1 virtual server ratio.

> expectations around it. It simply does not size up.
That may be the case. I was merely addressing the absolute
number issue.

-Ekr

---

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Jun 2002 16:07:57 -0400

>find AND validate routes among multiple roots.

I see what you mean by a "true" PKI, but I don't want one :-)

My examples of disjoint credential spaces in the physical world are 
not unified and they ought not be.  There usually is no incentive for 
the issuers to cross certify in most cases for these separate roots, 
and it creates new liability concerns, and raises trust issues.

>to be found, and validated, from one hierarchy (PKI, DNS) to another

I disagree; PKIs can accommodate multiple roots. Mesh certification 
is and old concept (intrinsic in X.509), but it is way too complex 
for most (if not all) folks to comprehend and manage. I always point 
to the inability of people to program VCRs as an example of a lower 
bound for people's tolerance of complexity. Mesh PKIs go way beyond 
VCR programming.

>ownership, just like in the DNS.

I don't know who would argue that the DNS is other than a singly 
rooted tree, but I think we are in agreement re what a cert is.

>would need a different beast.

I don't think you've substantiated the last part of the above assertion.

>PKI is not dead, though. It is just at a dead end.

I used to be CTO for a PKI product/service vendor and my recollection 
is that there were many more certs issued for a variety of 
applications than the number of server certs you allude to above. SSL 
is not the only game in town. Also, my biggest problem with client 
certs for SSL is the lack of easy means of synchronizing them among 
my destop at work,  at home, and my laptop. Compared to the 
alternative of using passwords for the many web sites that require me 
to login, I see no need to go beyond software protection of these 
private keys.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Jun 2002 17:15:25 -0400

Stef,

>somewhere under some describable conditions.  Then show that trust 
>is transitive in PKI.
>

This is getting tiresome. I have the feeling that you do not read to 
the end my messages. I'll keep this short:

	- I have never stated that trust is transitive; in fact, I 
have given numerous talks and written a number of papers that state 
the opposite, so my position has been consistent and on the record 
for many years.

	- although many popular PKIs (including PGP) assume on 
transitive trust, this it not an intrinsic feature of PKIs.

	- a PKI in which each CA is authoritative for the name space 
in which it issues certs need not involve transitive trust.

	- cross-certification in such a PKI need not involve trust; 
it can merely represent a recognition by one CA of the authority of 
another CA for a different part of a name space

In the case of DNS, where authority for each part of the name space 
is well defined,  I argue that having the folks who are responsible 
for the domains assume the role of CA for their domains is a natural 
way to create a PKI that attests only to the binding of DNS names to 
keys. I maintain that this does not involve transitive trust.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Fri, 14 Jun 2002 14:29:58 -0700

> and it creates new liability concerns, and raises trust issues.

OTOH, it is a problem if you want to talk outside of your gopher hole ;-)

>
> Ed Gerck wrote:
>  The fundamental problem is that the PKI architecture cannot

Certainly, as well as the explanation why "mesh certification" does not work.

To begin, consider that a certified end-user key exists to establish assurance
in the authenticty of the keying material; certification is the process for
effecting such assurances.

However, more generally, a certification chain can exist whose purpose
is to 'distribute the (asymmetric) key". Key Distribution, unlike key
certification, requires notions of revocation, compromise recovery, and
management of risk to compensate for inadequate or costly procedures of
key distribution..

In such a simple theory, key certification validity is not a overly-variable
quantity: the degree of variability is limited to the "legal fact" (affirmative
fact exists, or does not exist) established when a using party ("relying
party"?) *accepts* it, or not, as useful.

The systemic purpose of key distribution is to provide a "metric space"
whereby many procedures, which handle certification chain(s), may be
(multiply) used to measure whether a given asymmetric key pertaining to
an end-user is indeed useful, or not. The metric is an expression of
relative certainity for a specific security problem, and application
context, given all available knowlege of the operational vulnerablities.

Try www.mcg.org.br/cie.htm , which uses such a geometric model for
certification to show that PKI certification must depend on an external
reference *even though* the external reference "cancels out" in the final
result.

> rooted tree,

The DNS names do not have the same hierarchy that one associates
per X.509/X.500 witth a DN.  The DNS is less than a single rooted tree
because there are no neccessarily hierarchical dependencies, just
hierarchical placements.

> but I think we are in agreement re what a cert is.

;-)

> I don't think you've substantiated the last part of the above assertion.

For a theory, see the reference cie.htm above. But let me try by a negative
example. There is not a single example of a PKI -- even on paper -- that can
work with multiple, *indepedent*  CA roots. Of course, if the CA roots
are not independent then they are not multiple.

> Ed Gerck wrote:

Eric already allowed me to stress that the number I cited was given for
"servers" and not for web sites. For web sites, the number was
over 140,000 in October 2001.  Now, should we discuss whether $1/day
is  much better than $0.1/day for a person to live on, or should we just
say that both are far too small?  Likewise, the number of SSL servers
out there is far too small  to support so many CAs and much hype.

Cheers,
Ed  Gerck

---

From: Einar Stefferud <[email-masked]>
Date: Fri, 14 Jun 2002 15:32:50 -0700

Ok, we are getting somewhere now.

So, I ask, where does trust come from in PKI if not from transmission 
via some 3rd party CERT issuer, which I understand to be a use of 
transitivity of trust from the CERT buyer, though the CA to the 
relying party.

Maybe this is is erroneous thinking, but if so, please explain how 
the trust information is passed from the CERT holder through the CA 
to the cert recipient who will use if as a basis of trust.  To me, 
this looks like transitivity.

A trusts B; C Trusts A; therefore C trusts B????

Cheers...\Stef

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 10:06:43 -0400

At 3:32 PM -0700 6/14/02, Einar Stefferud wrote:
>So, I ask, where does trust come from in PKI if not from 
>transmission via some 3rd party CERT issuer, which I understand to 
>be a use of transitivity of trust from the CERT buyer, though the CA 
>to the relying party.
>

Stef,

A public key cert is a digitally signed attestation by a CA, binding 
attributes to a public key. It is a digital credential. We deal with 
physical credentials all the time and in most cases we don't ask 
whether we trust the issuer of the credential to correctly issue the 
credential, although there are exceptions. More often we worry about 
the integrity of the credential pre se, e.g., how hard is it to forge 
a credential.

I feel that the term "trust" is appropriately applied to certs when 
the CA is not authoritative for the attributes in the cert, but is 
not appropriate when the CA is authoritative.

By analogy, we normally do not say that we "trust" an employer to 
identify its employees or the U.S. State Dept. to identify U.S. 
citizens. They are authoritative as credential issuers and thus the 
term trust, while potentially applicable, is not commonly applied, 
i.e., it is implicit.

Steve

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Jun 2002 10:53:44 -0400

> large part. 

actually, that perception - which you admit is real - is part of what 
makes the DNS PKI dangerous.  it's what makes it so likely that 
DNS PKI will be misused and that the trust placed in it will be abused.

---

From: Ed Gerck <[email-masked]>
Date: Mon, 17 Jun 2002 08:30:18 -0700

> not appropriate when the CA is authoritative.

Trust is oftentimes used as a synonym for authorization.  This is fine if
you have a network, where a trusted  user is a user authorized by the
sysadmin to do or be something. However,  the concept of trust as we
have developed and learned to use it for thousands of years in commerce
and human communication (like an internet, a network of networks)
is much more complex than authorization. Thus, when we replace trust
with authorization we lose representation capacity -- we flaten out, so
to say, the descriptive capacity of our language.

As authorization, trust can be transitive.  Money is an authorization
for payment and it is surely transitive.  However, if trust is taken as
representing the usual concept of trust, then it cannot be considered
transitive. For example,  if I trust my brother this does not mean that I
must trust my brother's friends.  We cannot grant it to be associative,
either. Let me exemplify.

Definition 1: (associative)
  An operation * is associative in the space of {A,B,C} if and only if
  (A*B)*C = A*(B*C). Example: (3*5)*7 = 3*(5*7)

(NOTE: "distributive" in the social sense)

Proposition 1: Trust is not associative
Proof: Let trust be the operation *. We want to prove that Definition 1 is
not obeyed and one counter example will suffice.

Suppose Jon trusts a CA and has his PKI cert issued by that CA.
After the cert was issued, the CA decides to trust Khadaffi and grants
Khadaffi access and control to all of its issued certificate and CRL
files, including Jon's of course -- which was already issued. This is
represented by the result of (Jon*CA)*Khadaffi, which is Ok because Jon
trusts the CA before the CA trusts Khadaffi, and thus gets his PKI
cert from that CA.

Suppose now that Jon learns beforehand that the CA trusts Khadaffi and all
his data will be also know to Khadaffi if he decides to trust that CA and
that Khadaffi could revoke his cert at will (eg, simulating an error).
Then, if Jon does not trust Khadaffi, he will not have his PKI cert
issued by that CA. This is represented by the result of Jon*(CA*Khadaffi),
which is not Ok and Jon does not get his PKI cert from that CA.

Of course, the result of the first operation is not equal to the second.
The same could be exemplified for competing businesses or competing
countries.

Or, you may trust your lawyer before you know he trusts your competitor
but not after you know it, and so on.

In summary, trust depends on the event sequence.

Of course, you may never know that an untrustworthy C of (A*B)*C exists
(ie, the confidence-leak problem) and you may forever trust Aldrich Ames!
This is also part of the unsolvable problems of PKI certification,
when trust is used as a reference even though it is always relative to
unknown assumptions.

This means that the only reliable trust is self-trust (which cannot have
an unknown C, by hypothesis) and the verifier must be able to decide on
the basis of his intrinsic and independent measurements. Further, trust on
a third-party is not only always unreliable but it cannot even be reliably
estimated (eg, Aldrich Ames).

These problems eventually invalidate any PKI scheme which grows beyond
a certain "critical radius". And, it also casts serious doubts on the validity of
delegation and authorization chains if such aspects of trust are not taken into
account.   As they are not, in PKI and in the DNS.

Cheers,
Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 11:56:33 -0400

>OTOH, it is a problem if you want to talk outside of your gopher hole ;-)

I anticipate belonging to a lot of communities (PKIs), just as I do today.

>effecting such assurances.

right

>management of risk to compensate for inadequate or costly procedures of

I don't understand this. Because certs are signed, distribution is 
relatively easy, e.g., I can store them and transmit them with 
relative ease. I don't need to issue certs just to distribute keys. 
Even for revocation this is true, if one uses CRLs.

>party"?) *accepts* it, or not, as useful.

Oh, let's not bring legal issues into this. I don't consult my 
general counsel about the length of passwords or the mandated 
frequency of change, etc. when we're putting in place systems to 
authenticate users. If we refrain from trying to make too much out of 
a PKI, we ought to be able to do the same thing.

>context, given all available knowlege of the operational vulnerablities.

I don't agree. I looked briefly at your reference (cited below) and 
it begins by arguing about the difficulty of naming things uniquely 
in the Internet. But in the DNS context, this is a solved problem, so 
I don't think the extensive analysis you provide is applicable here.

>because there are no neccessarily hierarchical dependencies, just

Huh? Both DNS and X.500 use hierarchic names allocated in a 
distributed fashion from a singly rooted tree. We have a convention 
for how to map DNS names to DNs, using the DC attribute. I do not 
understand the phrase "there are no neccessarily [sic] hierarchical 
dependencies, just
hierarchical placements"

<snip>

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 12:00:28 -0400

>to say, the descriptive capacity of our language.

I agree that the two concepts should be kept distinct, and that's why 
I try to use "trust" to describe CA relationships where authorization 
is absent. In the DNS, and in many other cases, CAs are authorized 
and thus need not be "trusted" in the traditional sense.

>either. Let me exemplify.

We agree.

>account.   As they are not, in PKI and in the DNS.

I don't understand your assertion in this last sentence.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Mon, 17 Jun 2002 09:51:57 -0700

> I anticipate belonging to a lot of communities (PKIs), just as I do today.

and you anticipate having the same problems to communicate among them ;-)
Instead, why not solve the problems ...

> Even for revocation this is true, if one uses CRLs.

Yes, it does look easy doesn't it? But what the text above asks is
what is the merit/value of key distribution if notions of  revocation,
compromise recovery, and management of risk  are NOT taken into
account.

> a PKI, we ought to be able to do the same thing.

There are no legal issues.  Note the double quotes -- what is meant
here is that there really is a need for evidence supporting the assertion.

> I don't think the extensive analysis you provide is applicable here.

;-) there is not such beginning. Either you did not reach the correct
site/paper or you need to read it.

> dependencies, just hierarchical placements"

Apparently, you believe that DNS names are X.500 names are somehow
similar ("use hierarchic names allocated in a distributed fashion from a
singly rooted tree'). They are not -- DNS names do not to a hierarchy
belong.

Cheers,
Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 13:11:21 -0400

>Instead, why not solve the problems ...

If I am a member of multiple communities, and if I have a cert issued 
by each community for use in its context, I don't need to communicate 
AMONG the communities, just within them.

>		<SNIP>

I quote from your paper, with the relevant text in bold:

3.1.2. Distinguished Names
The first question of Section 3.1. was "who is S?", which has to be 
answered with a name-like attribute. Of course, if we use natural 
names we will not go very far before a similar name is found in the 
world population. Thus, to allow for programs (i.e., verifiers, 
subjects, etc.) to deal with entities in the Internet, it is 
necessary to have a "naming convention" that may allow a unique and 
singular name to be used for each entity -- which is usually called a 
"Distinguished Name" or DN. With DNs, it would be possible to 
uniquely associate entities to contract numbers, accounts, etc., 
without requiring the account numbers, etc. to be also unique. The 
problem is that there is no naturally found DN for each member of the 
human race, computer, machine, etc. Of course, if such a DN existed, 
then the reference problem in the Internet would also not exist. But 
since the Internet is void of a standard reference as we saw in 
Section 1, this means that the DN question has also no extrinsic 
solution.

DNS names are "natural" in the Internet and provide unique IDs for 
machines, at the granularity needed for the sorts of applications we 
are discussing.

>		<SNIP>

Why do you say that? Any DNS name specifies a path from the root to 
an node the the DNS tree, just as an X.500 DN does.  What is not 
hierarchic about a DNS name?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 13:11:21 -0400

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 13:11:21 -0400

Steve

---

From: Ed Gerck <[email-masked]>
Date: Mon, 17 Jun 2002 10:53:40 -0700

Stephen Kent wrote:

> <snip>
> If I am a member of multiple communities, and if I have a cert issued by each community for use in its context, I don't need to communicate AMONG the communities, just within them.

Why restrict how you/I/we can communicate? The technical system should not pass its limitations as features.

> <snip>I quote from your paper, with the relevant text in bold: 3.1.2. Distinguished NamesThe first question of Section 3.1. was "who is S?", which has to be answered with a name-like attribute. Of course, if we use natural names we will not go very far before a similar name is found in the world population. Thus, to allow for programs (i.e., verifiers, subjects, etc.) to deal with entities in the Internet, it is necessary to have a "naming convention" that may allow a unique and singular name to be used for each entity -- which is usually called a "Distinguished Name" or DN. With DNs, it would be possible to uniquely associate entities to contract numbers, accounts, etc., without requiring the account numbers, etc. to be also unique. The problem is that there is no naturally found DN for each member of the human race, computer, machine, etc. Of course, if such a DN existed, then the reference problem in the Internet would also not exist. But since the Internet is void of a standard reference as we saw in Section 1, this means that the DN question has also no extrinsic solution. DNS names are "natural" in the Internet and provide unique IDs for machines, at the granularity needed for the sorts of applications we are discussing.

The paper at http://www.mcg.org.br/cie.htm is name-agnostic. That text is not in the beginning and
is NOT a problem handled by the paper. The paper just makes the (correct) affirmation that X.500
DNs do not work as expected.  The reader can use any naming convention the reader wants --
including DNS names or DNs.

> <snip>Why do you say that? Any DNS name specifies a path from the root to an node the the DNS tree, just as an X.500 DN does.  What is not hierarchic about a DNS name?
>

As Stef has already discussed elswhere, the DNS naming scheme is an ontology.  That is, it is hierarchical
only in that the totality of names in the tree is a hierarchy, but there need be no meaningful relationship
between  the names at any level of the DNS name tree.

DNS names bear no specific relationship to anything, hierarchical or not.  Some people want them to
represent geography, others want them to confirm to rigid product and service categories, others want them
to be used a  Directory.  There are many hierarchical and non-hierarchical relationships you can define
within the *same* DNS name space. The environment is potentially much more complex and varied than
a relatively simple one dimensional hierarchy, inckuding: (1) territories (e.g., cnri.reston.va.us), (2) type of
sponsoring institution (e.g., fcc.gov), or (3) a hybrid of the two (e.g., dillons.co.uk). Because the Internet is
basically an open, distributed information system, the identifiers aren't really tied to any physical notion of
geographical exercise of sovereignty either.

Also, contrary to DNs assigned by a RA as defined in X.509, most DNS names are self assigned and then
are registered in some system that is used to advertise arbtrarily assigned bindings to other entities.

Cheers,
Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Mon, 17 Jun 2002 10:53:40 -0700

Cheers,
Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Mon, 17 Jun 2002 10:53:40 -0700

Cheers,
Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 14:27:33 -0400

At 10:53 AM -0700 6/17/02, Ed Gerck wrote:
>
>
>Stephen Kent wrote:
>
>><snip>
>>If I am a member of multiple communities, and if I have a cert 
>>issued by each community for use in its context, I don't need to 
>>communicate AMONG the communities, just within them.
>>
>Why restrict how you/I/we can communicate? The technical system 
>should not pass its limitations as features.

We're not talking about a communication restriction. We're talking 
about whether credentials that attest to my identity in one community 
are meaningful in another community.  I have an ISOC member card. It 
identifies me uniquely via my member number. So does my ACM card. So 
does my video rental card. None of these ID numbers is useful outside 
the community in which it was issued. The same would be true for 
certs issued by these folks acting as CAs for their respective 
communities.

>><snip>I quote from your paper, with the relevant text in bold: 
>>3.1.2. Distinguished NamesThe first question of Section 3.1. was 
>>"who is S?", which has to be answered with a name-like attribute. 
>>Of course, if we use natural names we will not go very far before a 
>>similar name is found in the world population. Thus, to allow for 
>>programs (i.e., verifiers, subjects, etc.) to deal with entities in 
>>the Internet, it is necessary to have a "naming convention" that 
>>may allow a unique and singular name to be used for each entity -- 
>>which is usually called a "Distinguished Name" or DN. With DNs, it 
>>would be possible to uniquely associate entities to contract 
>>numbers, accounts, etc., without requiring the account numbers, 
>>etc. to be also unique. The problem is that there is no naturally 
>>found DN for each member of the human race, computer, machine, etc. 
>>Of course, if such a DN existed, then the reference problem in the 
>>Internet would also not exist. But since the Internet is void of a 
>>standard reference as we saw in Section 1, this means that the DN 
>>question has also no extrinsic solution. DNS names are "natural" in 
>>the Internet and provide unique IDs for machines, at the 
>>granularity needed for the sorts of applications we are discussing.
>>
>The paper at 
><http://www.mcg.org.br/cie.htm>http://www.mcg.org.br/cie.htm is 
>name-agnostic. That text is not in the beginning and

Sorry, but I didn't infer that from the text, but then I admit that I 
did not read al of the paper.

>>  <snip>Why do you say that? Any DNS name specifies a path from the 
>>root to an node the the DNS tree, just as an X.500 DN does.  What 
>>is not hierarchic about a DNS name?
>>
>>
>
>to be used a  Directory.  There are many hierarchical and 
>non-hierarchical relationships you can define
>a relatively simple one dimensional hierarchy, inckuding: (1) 
>territories (e.g., cnri.reston.va.us), (2) type of
>sponsoring institution (e.g., fcc.gov), or (3) a hybrid of the two 
>(e.g., dillons.co.uk). Because the Internet is
>basically an open, distributed information system, the identifiers 
>aren't really tied to any physical notion of

Perhaps we just don't mean the same thing when we talk of names being 
hierarchic. By hierarchic I mean that they have a syntax that is 
mapped directly to a hierarchy, in this case a singly-rooted tree. 
An authority for one part of the tree cannot assign names for another 
part of the tree, because the names are always assigned relative to 
the issuer's name. the examples you give above do not contradict any 
of this, so I assume we're just talking about different properties of 
names. I do agree that there are limits on what can infer about an 
entity based on a DNS name, but these are precisely the limits we 
live with by virtue of using these names to identify machines and 
people, and all I am suggesting is that we improve the quality of the 
binding by using certs instead of just DNS entries.

Yes, DNS names do not always adhere to strict geographic notions, but 
then people have had trouble deciding how to deal appropriately with 
X.500 DNs for ,multi-national companies. So, what's the big deal?

DNS names are not totally self-assigned. One is restricted in the 
selection based on where one can attach in the tree. I cannot get a 
name under ibm.com as an employee of BBN. The binding are not 
arbitrary, in general.  The MIL and GOV domains are pretty 
restrictive, and EDU is not too bad. ORG and NET lost their original 
meanings over time. But, my point is that a DNS name is just what it 
is, nothing more, and we rely on these names every day, for better or 
worse. So, why not make this reliance more secure?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 14:27:33 -0400

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jun 2002 14:27:33 -0400

Steve

---

From: Ed Gerck <[email-masked]>
Date: Mon, 17 Jun 2002 19:12:46 -0700

Stephen Kent wrote:

>  We're not talking about a communication restriction. We're talking about whether credentials that attest to my identity in one community are meaningful in another community.  I have an ISOC member card. It identifies me uniquely via my member number. So does my ACM card. So does my video rental card. None of these ID numbers is useful outside the community in which it was issued. The same would be true for certs issued by these folks acting as CAs for their respective communities.

There is value in cross-identification and in mulit-identification. To get into a private plane,
today, most people show their state issued driver'license.  To open a bank account, you
need to have two different IDs -- which are not even issued by the bank.  There is also
value in cross-communication. IMO, isolated communities of interest are a PKI-bug, not a
communication feature.

> <snip>
> But, my point is that a DNS name is just what it is, nothing more, and we rely on these names every day, for better or worse. So, why not make this reliance more secure?

I thought we were talking about using the DNS to host a PKI, not about making the DNS more secure.  These are two separate issues.

Making the DNS more secure needs IMO to address a whole different, and thornier, set of issues. In this regard, I find the DNSSEC
approach to be insufficient because you cannot build a safe superstructure on a faulty infrastructure (the DNS itself).

It is a lot simpler to propose using the DNS for authenticated public key distribution -- and this has been done before [RFC 2065].
But key distribution, unlike key certification, requires notions of revocation, compromise recovery, and management of risk to
compensate for inadequate or costly procedures of key distribution -- which questions are not even considered. And it is awkward to
have the key and the parent's signature residing in the child's zone; this may lead to very complicated procedures for large TLD's
and over time. An alternative scheme has been proposed in which the parent zone  stores the parent's signature over the child's
key and also a copy of the child's key itself, but how about revocation?

Additional questions arise, as I was trying to motivate. For example,  PKI cannot scale under a single root, which is what the DNS model
has to offer. To work as an infrastructure (beyond your club's solipsistic needs) , a PKI needs to work with multiple roots. So, what PKI
needs DNS cannot offer. Also, DNS names form an ontology where a child's zone can and does change independently of the parent's
control, whereas PKI's path discovery relies on top-down control.  Using the example noted by Eric Hall some postings before, having
different registries controlling domains in the same TLD at any given moment brings a whole new set of issues. If the registry operator
for a TLD domain changes, would the private key linked to the TLD also need to be changed?

IMO, the DNS can be used with great care and no reliable revocation as a distributed locator for a self-signed or PKI root certificate
associated with a domain.  Just like anything we can put in the TXT record.  But the DNS cannot be used as basis for a PKI --
with an "I" for infrastructure.

Just my opinion.

Cheers,
Ed Gerck

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Jun 2002 00:20:36 -0400

> There is value in cross-identification and in mulit-identification. To get
> into a private plane, today, most people show their state issued driver'license. 

correction:

in most places, you don't need to show any identification to get into 
a private plane.  many airports serving private planes are nothing more
than a long field, and even those that are paved do not necessarily
have a fence or any security guards - because there is no reason for them
to have such things.  it's only in those places where the government is 
headed by incompetent morons that insist on imposing useless restrictions 
which do absolutely nothing for security that you have to put up with 
such stupidity.

we now return you to the debate on global PKI...

Keith

---

From: Alex Audu <[email-masked]>
Date: Tue, 18 Jun 2002 11:03:58 -0500

Ed,

You made some interesting points which leads me to wonder if
we can define Trust in such a way that its parameters are verifiable,
then we can verify that it is transitive. In other words, if Jon gets
a dollar from Mike, and Jon can verify the parameters of the dollar,
then Jon doesn't care about the "trustworthyness" of  Mike's source.
Or should he?

Regards,
Alex.

---

From: Ed Gerck <[email-masked]>
Date: Tue, 18 Jun 2002 12:31:24 -0700

> then Jon doesn't care about the "trustworthyness" of  Mike's source.

Alex:

We can define trust in many different ways and we can surely
define it in a way that it is 100% transitive. The real question,
however, is how should we define trust such that: (1) it corresponds
to the concept of trust that we humans have developed/learned in
thousands of years of history and commerce; and (2) it makes sense
in terms of a communication protocol that is executed by machines
and exchanges data with humans.

In other words, trust is a word that is commonly applied to many
situations and consequently has many shades of meaning. My work
focuses on one precise set of coherent meanings: the concept of
trust in the context of communication. More specifically, in the
context of the engineering problem of Internet communications. At
the same time, I believe that trust is needed in this context.  We cannot
just wave it off, or reduce it to authorization.  If we do that, we end up
where we are right now ;-)

In the way I see it applied to solve the engineering problem of Internet
communications[ 1, 2], trust is  considered something essentially
communicable, but with specific rules for its communication. The induction
(communication) of trust in heterogeneous environments, from human
to machine, machine to  machine, and machine to human, needs also
to be considered.

This also serves to bring together many different threads that are
discussed on and off-line, regularly. All the talk about the Net being
edge controlled needs to be revised in some new framework. In short,
the Internet does not really have a center or edges. It only has
connection points, each of which can be connected to any other such
connection point for the purpose of packet exchange. One reason that
the Internet does not have an edge is that at any termination
connector, it is possible to extend the Net beyond that point by
relaying packets, or by relaying messages, via dial-up modem, FAX or
channels.

Finally, let me address the last part of  your question. Why can't trust be
something I hand over to someone, and that someone can hand over again
to someone else?  Because that is not how we learned to use trust -- i.e., that
is not what we understand by trust in our social/economic behavior. Trust
is earned. Trust is  the result of a "slow" interaction, of a step-by-step build
up, with multiple channels of information.  The idea is that when trust develops
between machines, or machines and humans, we should essentially have
the same model as when trust develops  between humans. In short,  if we want
"trust"  to be a bridge between these worlds, we need a common model.

Cheers,
Ed Gerck

[1] "Trust as Qualified Reliance on Information", published in The Cook Report
on Internet, January 2002 (copy available upon request).

[2] (draft paper)  http://www.mcg.org.br/trustdef.htm

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 18 Jun 2002 13:17:58 -0700

Hello Alex;-)... et al ...

The shoe is on the other foot;-)...  So to speak.

The problem is not that we should prove the negative, but that those 
who claim that trust is transitive should prove that this is true.

Those of us who see how it is false are satisfied to accept and work 
within the parameters that are implied.

Those who will not bother to prove their assertions will have to live 
with their consequences.  It is a simple matter of will.

There is no SHALL implied here.

The problem is that those who will not see, cannot see.
It is their problem to solve, and their consequences to suffer.

We are not interested in pushing on a string.
One can lead a horse to water, but cannot make it drink.

We have presented information to counter the belief that trust is 
transitive, but mind control is out of our scope, and we accept this 
fact.  We trust that others will allow us to also be free of mind 
controls imposed by others.

Cheers...\Stef

PS:  It has always been intuitively true for me that trust is not 
transitive, as long long ago I found that when I trusted some friends 
friends, that my trusting was in error, so it is obvious to me.
I am surprised that this is not also true for so many others.

      So when I discovered that Ed Gerck had found a formal logical 
proof of this fact, we came to form an alliance to spread the word 
and also to capitalize on the fact that this opened the doors to new 
ways to solve trust problems.  That others have not yet figured it 
out is, to some extent, a blessing for us.

But then, I have always been somewhat of a maverick, often looking at 
the obverse side of things, just out of curiosity.  The view from the 
other side is often quite interesting, iff you can see it.

The roots of MIME came from this kind of perspective.../S

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Jun 2002 17:50:45 -0400

>then Jon doesn't care about the "trustworthyness" of  Mike's source.

I didn't want to comment on this example, but your message forces me to do so.

Jon verifies the dollar, which is a bearer credential, and not Mike, 
the person from whom he received the dollar. (The dollar could have 
been stolen by Mike!) This example says nothing about transitivity of 
trust.

Steve

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 18 Jun 2002 16:45:02 -0700

None of this, whether the dollar was stolen or not, has any impact on 
the trustworthiness of the original dollar, as it is a bearer note, 
and a dollar stolen is a dollar earned in some quarters.

Just like car manufacturers consider a car stolen to be a car sold, 
unless it was stolen from the manufacturer.

We trust the intrinsic appearance of the dollar bill.

Or the pink slip for car ownership, but do not trust the car without 
its pink slip.

Now, if I give you a check, and you give my check, made out to you, 
endorsed to someone else, the recipient, if she accepts it is relying 
on the transitivity of trust, whether such reliance is reliably 
transitive or not.  Most people in the US will not accept such 
checks, but in some countries, such checks circulate for a long time 
and some are never cashed.

The real underlying issue here is reliance, and as Ed has pointed 
out, reliance depends on more than the bearer saying "Trust Me!" 
which is a single channel of communication.  In the case of a dollar, 
it depends on the perceived ability to find a greater fool to accept 
it at face value,
as in the act of buying or selling common stock shares.

This is why "Trust Me!" is generally considered a joke and why most 
people laugh at it, whether they understand the formal logic of the 
humor or not.

But it is clear that trust is not some simple property of objects!
It is much more complex and depends on subjective evaluations of its
value, gennerally incorporating many bits of information from 
multiple channels.

Cheers...\Stef

At 5:50 PM -0400 6/18/02, Stephen Kent wrote:
>been stolen by Mike!) This example says nothing about transitivity 
>of trust.
>
>Steve

---

From: Chris Evans <[email-masked]>
Date: Tue, 18 Jun 2002 19:54:32 -0700

yeah, but they not assuming your personality if some1 snooks some dead presidents
from ur wallet.

---

From: Alex Audu <[email-masked]>
Date: Wed, 19 Jun 2002 10:01:14 -0500

Steve,

You made a good observation. However, it does not nullify the assertion that if
the appropriate
parameters of trusting the source, and genuineness of the dollar can be verified,
then we shouldn't
have a problem.  So if theft of the dollar is a concern, then add a verifiable
"stollen/not stollen" paramater.

Regards,
Alex.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Jun 2002 17:32:31 -0400

At 7:12 PM -0700 6/17/02, Ed Gerck wrote:
>>about whether credentials that attest to my identity in one 
>>community are meaningful in another community.  I have an ISOC 
>>member card. It identifies me uniquely via my member number. So 
>>does my ACM card. So does my video rental card. None of these ID 
>>numbers is useful outside the community in which it was issued. The 
>>same would be true for certs issued by these folks acting as CAs 
>>for their respective communities.
>>

Your example does not require cross-certification. It only requires 
that the relying parties be members of, or have access to the (CA) 
credentials for, the communities to which the individuals belong. 
Cross certification is one way to accomplish this, but it is not the 
only way.

>
>><snip>
>>But, my point is that a DNS name is just what it is, nothing more, 
>>and we rely on these names every day, for better or worse. So, why 
>>not make this reliance more secure?
>>
>I thought we were talking about using the DNS to host a PKI, not 
>about making the DNS more secure.  These are two separate issues.
>
>Making the DNS more secure needs IMO to address a whole different, 
>and thornier, set of issues. In this regard, I find the DNSSEC
>approach to be insufficient because you cannot build a safe 
>superstructure on a faulty infrastructure (the DNS itself).

Ultimately, DNS is not the focus of security, even for DNSSEC. If we 
implemented DNSSEC and did not use crypto-secure protocols to protect 
connections we would still be vulnerable to spoofing of those 
connections. We need to use protocols like IPsec or TLS to effect 
secure communications. But, if we had certs tied to DNS names, we 
would not require DNSSEC as a separate mechanism for this purpose, 
although it would serve some other security purposes.

>It is a lot simpler to propose using the DNS for authenticated 
>public key distribution -- and this has been done before [RFC 2065].
>But key distribution, unlike key certification, requires notions of 
>revocation, compromise recovery, and management of risk to
>compensate for inadequate or costly procedures of key distribution 
>-- which questions are not even considered. And it is awkward to
>have the key and the parent's signature residing in the child's 
>zone; this may lead to very complicated procedures for large TLD's
>and over time. An alternative scheme has been proposed in which the 
>parent zone  stores the parent's signature over the child's

yes, it is much easier to just use DNS to store certs from some set 
of CAs, but without an answer about who those CAs are, we have just 
postponed the problem, not solved it. The old DNSSEC design was 
flawed re where the records were stored, but that problem does not 
arise if one stores certs, so let's not go down that rat hole. 
DNSSEC also does not address revocation very well, but if one stored 
certs in the DNS, then oue could also store CRLs, which addresses the 
revocation question you raise.

>Additional questions arise, as I was trying to motivate. For 
>example,  PKI cannot scale under a single root, which is what the 
>DNS model
>has to offer. To work as an infrastructure (beyond your club's 
>solipsistic needs) , a PKI needs to work with multiple roots. So, 
>what PKI
>needs DNS cannot offer. Also, DNS names form an ontology where a 
>child's zone can and does change independently of the parent's
>control, whereas PKI's path discovery relies on top-down control. 
>Using the example noted by Eric Hall some postings before, having
>different registries controlling domains in the same TLD at any 
>given moment brings a whole new set of issues. If the registry 
>operator

You keep asserting that a single root does not permit scaling, but I 
have yet to see a good argument supporting that assertion. In part 
this seems to result from your approach to defining a PKI, a 
definition not consistent with most others in the literature. In 
response to your concrete question, yes, if the organization 
controlling a TLD changed, then new certs would have to be issued to 
the next tier of domains. But, this can be done unilaterally, by the 
new TLD operator. Yes, it would take effort, but we're not talking 
about a sudden, unexpected change.

>IMO, the DNS can be used with great care and no reliable revocation 
>as a distributed locator for a self-signed or PKI root certificate
>associated with a domain.  Just like anything we can put in the TXT 
>record.  But the DNS cannot be used as basis for a PKI --

I agree that one could do that with the DNS, and we have had specs 
for how to do it for some time. But, it does not address the harder 
problems we face re secure identification of DNS-named entities.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Jun 2002 17:32:31 -0400

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Jun 2002 17:32:31 -0400

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Jun 2002 17:43:51 -0400

>"stollen/not stollen" paramater.

Alex,

and what about counterfeit dollars? Mike may be a trustworthy person, 
but not be good at detecting counterfeit money, so trusting him re 
the integrity of the dollar when he hands it to you, in good faith, 
is still misplaced trust.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Thu, 20 Jun 2002 17:25:01 -0700

Stephen Kent wrote:

> Your example does not require cross-certification. It only requires that the relying parties be members of, or have access to the (CA) credentials for, the communities to which the individuals belong. Cross certification is one way to accomplish this, but it is not the only way.

Cross-certification is the way to do it automatically, tamperproof and that.
But PKI does not work with cross-certification, so cross-certifcation must
not be useful ;-)

>  You keep asserting that a single root does not permit scaling, but I have yet to see a good argument supporting that assertion.

;-) for starters, just read your own emails in this thread. You mentioned at least
two reasons why a single root is not good for PKI.  My reasons include the
observation that a single point of control is also a single point of failure.  One
perverse aspect of the single root is, thus, that as the PKI grows and the single root
gathers all the liability there is a point after which the liability at that single root
may not even be insurable. Just think of it: all world e-commerce compromised because
of one snafu at one point?  This would be involution, not evolution.

> In part this seems to result from your approach to defining a PKI, a definition not consistent with most others in the literature.

I have not defined what a PKI is.  I guess there are already plenty of definitions
around.  I just said that a PKI would need to be an infrastructure -- that pesky
"I" at the end of PKI.

But failure to be an infrastructure is IMO one of the reasons why PKI is at a dead
end.  The DNS, OTOH, is an infrastructure.  Mixing both will reduce the infrastructure
property of the DNS, reduce interoperation and alienate business drivers.

There are many problems with the DNS, surely.  I have catalogued more than forty
serious problems.  But the DNS has scaled from 10^4 users to almost 10^8 users
without much change.  We should be careful in adding a limited technology such
as PKI to the DNS.  The converse seems to be more reasonable -- using the DNS to
add distribution channels (for certs and revocation information) to a PKI.  This can
be done right now.

Cheers,
Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Jun 2002 10:24:13 -0400

At 5:25 PM -0700 6/20/02, Ed Gerck wrote:
>Stephen Kent wrote:
>
>>  Your example does not require cross-certification. It only 
>>requires that the relying parties be members of, or have access to 
>>the (CA) credentials for, the communities to which the individuals 
>>belong. Cross certification is one way to accomplish this, but it 
>>is not the only way.
>

there is an important difference between what one can do and what one 
must do. my point was that your example does not require cross 
certification, that's all. Moreover, there are many instances of 
PKI-like systems where cross certification is definitely not a 
desired feature, e.g., credit card issuers.

>  >  You keep asserting that a single root does not permit scaling, 
>but I have yet to see a good argument supporting that assertion.
>

I don't recall having said that a single root is bad for an 
individual PKI. Please refresh my memory.  Yoru example here is also 
flawed. Consumer e-commerce today relies on credit cards, and there 
are multiple issuers each of which is independent of the others. Each 
acts analogously to a root for an island of certification.

>  > In part this seems to result from your approach to defining a 
>PKI, a definition not consistent with most others in the literature.
>

We have lots of physical world infrastructure examples where there 
are the equivalent of multiple, independent roots. Infrastrucucture 
need not imply the universality that you seem to imply.

>property of the DNS, reduce interoperation and alienate business drivers.

I don't see how any of these assertions are supported by what you have said.

>add distribution channels (for certs and revocation information) to 

We seem to agree that the DNS could be sued to distribute certs, so 
the question is what should the certs attest to and who should issue 
them. I argue that we need certs that support validation of DNS 
bindings, and that the only authoritative sources for that info are 
the folks who manage the DNS. Anyone else is a TTP, with all the 
problems that implies. No other names that we might put in certs will 
provide the same sort of security features that DNS-based certs will 
provide, because people and software use DNS names to identify the 
machines they initiate communication with in the Internet. So, the 
fact that we could store certs issued by arbitrary TTPs, with non-DNS 
names, is true, but ultimately not very useful for basic Internet 
security.

Steve

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Jun 2002 11:58:50 -0400

> the folks who manage the DNS. 

and there is no assurance that they're trustworthy.

> Anyone else is a TTP, with all the
> problems that implies. 

the problems associated with TTPs may actually be less than the problems
associated with implicitly trusting the TLDs.  you *choose* whether to
trust a TP.  limited trust of the TLDs is essentially forced on you,
but it's a mistake to extend that trust beyond the minimum necessary.

it's one thing to get an address RR of a server from a TLD. you still
have the opportunity to authenticate that server via other means that
you trust.  the worst the TLD can do in this case is a DoS attack.

OTOH if the TLD has the capability of issuing a bogus cert for the
server you want to contact, and you are foolish enough to trust it,
you're screwed.  and the TLDs will mislead the public into trusting
them, because they'll be the "obvious" choice, and because there's 
nobody to keep them honest.

this is why a DNS-based PKI is a Bad Idea.  

OTOH being able to access TP certs via DNS could be quite useful.

the most trust that should be invested in the TLDs (or any zone)
should be the ability to authenticate the RRs in their zone,
and specifically NOT to authenticate servers.  and we don't need 
a DNS PKI to authenticate RRs, we have other mechanisms for that.

Keith

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Jun 2002 12:25:22 -0400

>and there is no assurance that they're trustworthy.

since trustworthiness is a relative term, that can always be said 
about any CA.  that's why I don't like dealing with CAs based on 
trust. authoritativeness is a quality that is less contentious in 
many contexts, including this one.

>but it's a mistake to extend that trust beyond the minimum necessary.

and a DNS-based PKI would not require anyone to trust it. people 
could choose to make use of it, or could continue to make use of the 
insecure system we have today. nobody said that making use of the 
certs would be mandatory; it would be an option we currently do not 
have.

you fear that people would decide to rely on this new aspect of the 
infrastructure and you think that, because of the specific 
organizations operating some TLDs, that this would be a bad choice. 
but, since we agree that people implicitly rely on it anyway, I don't 
see the change as a a bad one.

>nobody to keep them honest.

if you really do have viable means of independently verifying the 
accuracy of the binding, then you can always choose to employ them. I 
think that such means are rare in practice. but, in any case, these 
means could still be available.

>a DNS PKI to authenticate RRs, we have other mechanisms for that.

let's just say we disagree.

Steve

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Jun 2002 12:41:36 -0400

> many contexts, including this one.

the question is why IETF should endorse the idea of TLDs (or other
zones) being CAs when that is not needed to authenticate the RRs for 
which the zones are responsible.  

> and a DNS-based PKI would not require anyone to trust it. 

no, but IETF would be blessing the idea of TLDs becoming CAs when 
this is not necessary for them to serve their function, and then 
saying on the other hand "of course it's your choice about whether 
to trust them".  it reminds me of the "voluntary" income-tax 
collection system we have in the US.

> organizations operating some TLDs, that this would be a bad choice. 

no, it's not *because* of the specific organizations.  however
specific organizations have demonstrated that TLDs are not necessarily
trustworthy.  

or to put it another way, the trustworthiness of the DNS system as 
a whole is maximized if the shared zones (those that are not delegated 
to a single private individual or organization) are not given more 
responsibility or authority than absolutely necessary.

Keith