I don't think the dollar analogy is very useful. The kind of trust
we place in money is a very specific kind of trust, and the risk
we take in trusting money is generally limited to the denomination
of the note or coin. This is so well-understood that most of us
never think about it - though we
> How does Jon know that the dollar Jon received from Mike is a
dollar?
>
> A dollar has specifications that tell you it's a dollar (type of
paper, ink, micro printing, etc)
I don't think the dollar analogy is all that useful. A dollar is backed up
by people with guns, who hunt do
lto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]]
> >Sent: Tuesday, June 18, 2002 7:45 PM
> >To: ietf
> >Subject: Re: Global PKI on DNS?
> >
> >None of this, whether the dollar was stolen or not, has any impact on
> >the trustworthiness of the original do
Title: RE: Global PKI on DNS?
There appears to be two main points of contention about PKI on DNS. Using the dollar analogy
1. Uniqueness
How does Jon know that the dollar Jon received from Mike is a dollar?
A dollar has specifications that tell you it's a d
> At 11:58 AM -0400 6/25/02, Keith Moore wrote:
> > > 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
At 11:58 AM -0400 6/25/02, Keith Moore wrote:
> > 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 autho
> 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 mana
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
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 t
yeah, but they not assuming your personality if some1 snooks some dead presidents
from ur wallet.
6/18/02 4:45:02 PM, Einar Stefferud <[EMAIL PROTECTED]> wrote:
>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
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 m
At 11:03 AM -0500 6/18/02, Alex Audu wrote:
>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
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
Alex Audu wrote:
> 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
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 a
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
Stephen Kent wrote:
> 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 issu
Stef,
>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 f
At 11:30 AM -0700 6/14/02, Ed Gerck wrote:
>Stephen Kent wrote:
>
>>
>> Could you elaborate, perhaps privately, with why you believe a "true
>> PKI" needs multiple roots?
>>
>>
>> My view is that too many
>> folks have tried to get too much out of any single PKI, and that has
>> caused a
> 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).
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 tha
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 co
Ed Gerck <[EMAIL PROTECTED]> writes:
> 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.
These numbers sound quite low. Netcraft's 2001
At 2:05 PM -0400 6/14/02, John Stracke wrote:
> >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.
>
>The problem is that, although the owner of the domain is authoritative
>fo
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
Stephen Kent wrote:
>
> Could you elaborate, perhaps privately, with why you believe a "true
> PKI" needs multiple roots?
>
>
> 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 PKI
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 chang
>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.
The problem is that, although the owner of the domain is authoritative
for who gets to use which name, that doesn't mean thei
> "Robert" == Robert Elz <[EMAIL PROTECTED]> writes:
Robert> There's a simple reason why the DNS isn't suitable as a PKI,
Robert> and it has nothing to do with transitivity of trust, and nothing
Robert> to do with DNS packet size limitations, or root server workloads.
Robert>
Stef,
>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 n
Ed,
>Stephen Kent wrote:
>
>> Ed,
>>
>>
>> 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
Stephen Kent wrote:
> Ed,
>
>
> 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 limitatio
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 intentiona
> >Such software would not see this kind of data unless a user
> >of the server tried to use this stuff, and in that case I don't see
> >why that user couldn't upgrade her own software to get it to work.
>
> Because it's not their software? If I wanted to do PKI through DNS, and my
> ISP's server
In message <[EMAIL PROTECTED]> on Thu, 13
Jun 2002 10:08:49 -0400, "John Stracke" <[EMAIL PROTECTED]> said:
jstracke> >The CERT extension to DNS allows to place there a URI, a
jstracke> >URI is smaller than a cert and stays in a udp packet.
jstracke>
jstracke> Bootstrap problem: how can you trus
"John Stracke" <[EMAIL PROTECTED]> writes:
>>The CERT extension to DNS allows to place there a URI, a URI is smaller
> than
>>a cert and stays in a udp packet.
>
> Bootstrap problem: how can you trust the results of the URI?
The URI can contain a hash (fingerprint) of the target data. C.f. TLS
At 11:30 PM -0700 6/13/02, Einar Stefferud wrote:
>[EMAIL PROTECTED] said:
>
>>On Fri, 14 Jun 2002 10:52:47 +1200, Franck Martin <[EMAIL PROTECTED]> said:
>>
>> > Ideally, we should rate each CA in our applications and the application
>> > should give us a level of risk...
>>>
>>>Hey.. it's the
Ed,
>Keith Moore wrote:
>
>> > 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.
>>
>> so what you're saying is that the cert would mean something like:
>
>;-) actually, to a lawyer, a
At 2:54 PM -0700 6/13/02, Einar Stefferud wrote:
>At 2:15 PM -0400 6/13/02, Stephen Kent wrote:
>
>[snip]... [snip]... [snip]... [snip]... [snip]... [snip]...
>[snip]... [snip]...
>>
>>You are the one who keeps saying that trust is transitive. I'm the
>>one saying that it's not, and that a DNS-b
At 2:47 PM -0400 6/13/02, Keith Moore wrote:
> > 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
>
>yes, I think this is right. it eliminates some kinds of threats. but
>it still doesn't guar
At 3:32 PM -0400 6/13/02, Harald Koch wrote:
>Of all the gin joints in all the towns in all the world, Stephen Kent
>had to walk into mine and say:
>>
>> Why does everyone keep thinking that explicit trust is an essential
>> element of every PKI?
>
>If the reasonably intelligent, technically ski
At 12:51 PM -0700 6/13/02, Christian Huitema wrote:
> > > > 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.
>> >
>> > so what you're saying is that the cert would mean somethi
There's a simple reason why the DNS isn't suitable as a PKI,
and it has nothing to do with transitivity of trust, and nothing
to do with DNS packet size limitations, or root server workloads.
It is that DNS admins did not sign on for the job of authenticating
anything (with the possible exception
[EMAIL PROTECTED] said:
>On Fri, 14 Jun 2002 10:52:47 +1200, Franck Martin <[EMAIL PROTECTED]> said:
>
> > Ideally, we should rate each CA in our applications and the application
> > should give us a level of risk...
>>
>>Hey.. it's the PGP Web of Trust. ;)
>>
>>Content-Type: application/pgp-s
On Fri, 14 Jun 2002 10:52:47 +1200, Franck Martin <[EMAIL PROTECTED]> said:
> Ideally, we should rate each CA in our applications and the application
> should give us a level of risk...
Hey.. it's the PGP Web of Trust. ;)
msg08597/pgp0.pgp
Description: PGP signature
At 5:14 PM -0500 6/13/02, VILLARREAL, STEVE (SBC-MSI) wrote:
>You gents have too much time on your hands. this list should be
>used as a means to assist with questions regarding technologies ...
>not used as a forum for posturing
>
Really?
Here's the scoop from http://ww
If some cretin p8s your domain name away from your IP then when some1 request the
pubic pki from that domain they will get bogus info. and the transaction will
abort. now if the same pki info was on DNS, they still get good and transact
with the cretin instead of u. that info need be on your
on www.example.com being squatted, the problem is the squatter does not
get the private key, so yes it has a certificate with a public key, but
everybody does...
To use the certificate, he will have to regenerate a private key, which
means a new certificate and expiring the old one.
The question
: Ed Gerck; Keith Moore
Cc: Stephen Kent; Einar Stefferud; ietf
Subject: RE: Global PKI on DNS?
> > > 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.
&g
At 2:15 PM -0400 6/13/02, Stephen Kent wrote:
[snip]... [snip]... [snip]... [snip]... [snip]... [snip]... [snip]... [snip]...
>
>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.
>
>constructi
> > > 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.
> >
> > so what you're saying is that the cert would mean something like:
>
> ;-) actually, to a lawyer, a PKI cert says someth
Of all the gin joints in all the towns in all the world, Stephen Kent
had to walk into mine and say:
>
> Why does everyone keep thinking that explicit trust is an essential
> element of every PKI?
If the reasonably intelligent, technically skilled persons in the IETF
can't "get it", what makes
Keith Moore wrote:
> > 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.
>
> so what you're saying is that the cert would mean something like:
;-) actually, to a lawyer, a PKI cert says so
> 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
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
yo
> 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.
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 excha
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
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 ha
>The CERT extension to DNS allows to place there a URI, a URI is smaller
than
>a cert and stays in a udp packet.
Bootstrap problem: how can you trust the results of the URI?
/=\
|John Stracke|Principal Engineer
At 10:42 PM -0700 6/12/02, Einar Stefferud wrote:
>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 transit
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..St
--Original Message-
From: Chris Evans [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 13 June 2002 4:46
To: David Conrad; Derek Atkins
Cc: Eric A. Hall; John Stracke; ietf; [EMAIL PROTECTED]; Key Distribution;
[EMAIL PROTECTED]
Subject: Re: Global PKI on DNS?
Then a global PKI protocol server needs to be i
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.
6/11/02 6:51:26 PM, Derek Atkins <[EMAIL PROTECTE
At 10:27 PM 6/7/2002 -0400, [EMAIL PROTECTED] wrote:
>2) DNS has to be *FAST*, especially at the root - we're talking on the
>order of 200K queries a *SECOND*. You figure out how to do that while
>also tossing certificates around, let us know...
I must be missing something. As far as I know, the
> >We're already trusting chains of signficant length (i.e. DNS delegation)
> >with no decent verification at all.
>
> That's a good point. PKI on DNS might not be the most trustworthy system
> imaginable, but it would probably be an improvement over no PKI. Provided
> it doesn't break DNS...
I have started this thread... Sorry people, I didn't know I will create so much passion on these lists... I propose that we meet next week at INET2002 in Washington to draft something. (www.isoc.org/inet2002/)
I have heard the pros and cons of doing it with DNS and I'm well aware of them. We
> 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.
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
>> 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.
>
>We're already trusting chains of signf
Keith Moore wrote:
>>>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.
>>
>>Th
At 7:44 PM +0200 6/12/02, Jakob Schlyter wrote:
>could we perhaps move this discussion to [EMAIL PROTECTED]?
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", plea
At 1:15 PM -0400 6/12/02, Keith Moore wrote:
> > > 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
could we perhaps move this discussion to [EMAIL PROTECTED]?
jakob
> > 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.
>
> So do you think that there's a n
David Conrad <[EMAIL PROTECTED]> writes:
> On 6/12/02 8:20 AM, "Eric Rescorla" <[EMAIL PROTECTED]> wrote:
> >> 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.
> > Yes, because it's
On 6/12/02 8:20 AM, "Eric Rescorla" <[EMAIL PROTECTED]> wrote:
>> 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.
> Yes, because it's an edge case.
Scalability as an edge case. Hmm.
>
"RL 'Bob' Morgan" <[EMAIL PROTECTED]> writes:
> 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.
Good, because that's not what I said.
I expect peers to send full
On Wed, 12 Jun 2002, Keith Moore wrote:
> 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.
So
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.
> We barely have any PKI at all, I think it's a little early to start
> worrying about cross-certification.
I'm sure you're
> > 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.
>
> This is missing t
"RL 'Bob' Morgan" <[EMAIL PROTECTED]> writes:
> On 12 Jun 2002, Eric Rescorla wrote:
>
> > 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 part
On 12 Jun 2002, Eric Rescorla wrote:
> 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 wer
On Tue, 11 Jun 2002 23:09:09 PDT, Peter Deutsch said:
> You don't need a unique root if you're willing to relax the prior
> constraint that you absolutely must prevent name conflicts. I know that
> voicing this idea is considered an indictable (if not excommuncable)
> offense to many folks in thi
David Conrad <[EMAIL PROTECTED]> writes:
> 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?
Just to play devil's advocate, if a resolver was going to track a
signature chain all the way back up,
David Conrad <[EMAIL PROTECTED]> writes:
> 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
Since I assume that most people on the lists already understand
this stuff, I'll followup to Peter privately...
> Somebody suggested out-of-band that I might be trolling with my last
> post, but actually I was just surrendering to my frustration, for which
> I apologize. I know what a wasteland
g'day,
Keith Moore wrote:
>
> > Somebody (I
> > think it was Keith) suggested earlier in this thread that nobody should
> > be trusted with the single PKI root. Maybe the same sentiment applies to
> > DNS roots, as well??
>
> no, it doesn't follow at all.you need a unique root (of some kind
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
On 6/11/02 6:51 PM, "Derek Atkins" <[EMAIL PROTECTED]> wrote:
> David Conrad <[EMAIL PROTECTED]> writes:
>
>> 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?
>
> Just to play devil's advocate
On 6/11/02 6:15 PM, "Eric A. Hall" <[EMAIL PROTECTED]> wrote:
>> 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?
> Why do you think anybody would cache them long-term if they were right
> there
> 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 plent
on 6/11/2002 8:00 PM David Conrad said the following:
> 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?
Why do you think anybody would cache them long-term if they were right
there handy in th
On 6/11/02 4:34 PM, "Eric A. Hall" <[EMAIL PROTECTED]> wrote:
>> 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.
> No, the big deal is that the roots and TLDs would be crippled from
> millio
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> From: "John Stracke" <[EMAIL PROTECTED]>
> >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
> Somebody (I
> think it was Keith) suggested earlier in this thread that nobody should
> be trusted with the single PKI root. Maybe the same sentiment applies to
> DNS roots, as well??
no, it doesn't follow at all.you need a unique root (of some kind) to
prevent name conflicts - mutual sel
on 6/11/2002 5:36 PM John Stracke said the following:
> 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.
No, the big deal is that the roots and TLDs would be crippled from
millions of TCP
John Stracke wrote:
>
> >> 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 motiv
>> 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
g'day,
John Stracke wrote:
>
> >Such software would not see this kind of data unless a user
> >of the server tried to use this stuff, and in that case I don't see
> >why that user couldn't upgrade her own software to get it to work.
>
> Because it's not their software? If I wanted to do PKI thr
>Such software would not see this kind of data unless a user
>of the server tried to use this stuff, and in that case I don't see
>why that user couldn't upgrade her own software to get it to work.
Because it's not their software? If I wanted to do PKI through DNS, and my
ISP's server did not su
(Please respect Reply-To)
"Eric A. Hall" <[EMAIL PROTECTED]> writes:
> on 6/8/2002 8:54 PM Simon Josefsson said the following:
>
>> Despite the FUD presented by certain individuals that doesn't want
>> keys/certs in DNS, people have already tarted doing it and it works
>> fine.
>
> Setting aside
on 6/8/2002 8:54 PM Simon Josefsson said the following:
> Despite the FUD presented by certain individuals that doesn't want
> keys/certs in DNS, people have already tarted doing it and it works
> fine.
Setting aside the issue of whether or not people are spreading FUD,
perhaps you could tell u
> > 1) short lived certs
> > 2) CRL's published at regular intervals.
> >
> > both involve a regularly-signed short-lived objects.
>
> Errr - OCSP?
last year we implemented a system that used DNS (with security extensions)
to distribute ceritificate validity information (among other things)
1 - 100 of 130 matches
Mail list logo
