Subject: Re: Client-side revocation checking capability

From: [email-masked]
Date: Mon, 14 Aug 2000 12:08:31 -0700

it goes further than that ... since the "authority" for which domain name
certificates are issued is the domain authority .... it is possible to "poisen"
that infrastructure (domain name hijacking) ... apply for a certificate ... have
it verified as valid by the domain name infrastructure, and have such a
certificate certified as valid.

there are proposals for improving the infrastructure of the domain name
infrastructure with digital signatures and public keys .... which addresses both
dynamic poisening as well as domain name hijacking types of poisen. Such a
trusted DNS infrastructure then could also return the same public key as part of
domain name lookup. At that point, existing certificates become superfulous and
redundant. In part, the problem of vulnerable DNS infrastructure is not only the
dynamic name lookups but also extends to core DNS infrastructure ... which
domain name certificates rely on for validating information that goes into a
certificate. Addressing the vulnerabilities of the DNS infrastructure (for both
dynamic name lookup as well as certification/validating of certificate
information) turns out to also make certificates redundant and superfulous.

Dennis Glatting <[email-masked]> on 08/14/2000 10:56:39
AM

To:   Bob Jueneman <[email-masked]>
cc:   [email-masked], [email-masked], [email-masked]
Subject:  Re: Client-side revocation checking capability

I disagree. To access www.amazon.com one uses DNS, which is not secure
and often easy to poison. Consequently, mafia.com can redirect some
number of browsers by poisoning some number of DNS servers, present a
Amazon.COM store front, and use Amazon's cert and private key. If the
browser doesn't check for revocation then the consumer is none the
wiser, at least for a while.

> Bob
>
> >>> "Anders Rundgren" <[email-masked]> 08/12/00 12:02AM >>>
> Juan Carlos,
>
> That on-line checking of server-certificates is not standard in browsers is
probably
> beacuse a revocation is not that likely to happen.  In case of a key
compromize at the VeriSign
> CA the whole world will be notified and in the case of key compromize in a
web-server no
> one will know or be notified.  You can steal a web-cert+key from a lousy
installation (most are)
> in case you have sys-admin rights.   Nothing to do about except tighten up
internal security.
> And if the host-name is no longer valid (the company filed for bancruptsy) the
> server will be taken down some day.
>
> IMO status-checking is only needed (or implementable at least) for
person-oriented certificates, where
> you may revoke yourself due to loss (of card) or by the company because you
got fired.
>
> This is a slightly different answer than you get by asking a typical crypto
expert but to my
> knowledge they usually know zilch, nada etc. about practical things that may
be 100 times more
> important than the cryptologic solurtion.  I.e. as long as there are serious
practical problems
> associated with server-certificates, CRLs etc. would basically add nothing
(but delays).
> Regards
> Anders

--
Dennis Glatting
Copyright (c) 2000 Software Munitions

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Aug 2000 16:30:47 -0400

Lynn,

I agree that a PKI based on the DNS would be a great benefit to the 
Internet. Now that VeriSIgn has bought NSI, the likelihood of 
creating such a PKI seems remote, as it would create a decentralized 
PKI that would challenge the VeriSign TTP model.

DNSSEC makes use of non-certificate constructs (for understandable 
reasons having to do with DNS security details), that are not really 
a good substitute for real certs.  Of course, you're a strong 
believer in no certs at all, so I'm not surprised that you would find 
DNSSEC a suitable alternative all by itself :-).

Steve