Subject: RE: Software for PKI

From: [email-masked]
Date: Wed, 7 Nov 2001 16:06:54 -0700

For 99.9999999 of the certificate associated events in the world today ....
aka with SSL domain name certificates .... they aren't really a PKI ... it
is manufactored certificates. Furthermore, the users are told that SSL is
there to keep people from evesdropping on the credit card number ... which
is a key-exchange protocol issue. There is some noise about certificate
being used to make sure you are really dealing with the web-site that you
think that you are dealing with ...  but I believe for the majority of the
end-users that is just noise ... the majority already believe that they are
dealing with the web-site that they are dealing with. From that stand-point
the certificate part of SSL domain name certificates is pretty much
extraneous protocol noise.

Furthermore, the perported purpose of the SSL domain name certificates
(aside from the SSL key exchange stuff) is because of worries about the
integrity of the domain name infrastructure. However, if somebody goes to
get a SSL domain name certificate from a TTP ... the TTP has to validate
the request with the authoritative agency for domain names (aka the domain
name infrastructure). To a large extent domain name infrastructure
integrity issues ... that exist can impact not only standard domain-name
lookup ... but also validation requests from TTPs. So a proposal to improve
the domain name infrastructure for the purposes of TTPs validating
information for manufactoring SSL domain name certificates ... turns out
would go a long way to improve the integrity of the domain name
infrastructure for everybody's use (which in turn, nagates the
justification for having SSL domain name certificates in the first place).
random ref:
http://www.garlic.com/~lynn/subtopic.html#sslcerts

[email-masked] on 11/07/2001 11:09 AM wrote:

I agree.  Why do you think SSL implementations and IPsec/VPN implementation
are widely in use.  TRANSPARENT to the end-user!

---

From: Eric Rescorla <[email-masked]>
Date: 07 Nov 2001 16:03:29 -0800

[email-masked] writes:
> dealing with the web-site that they are dealing with.
They may believe it, but without some cryptographic assurance they 
believe it on bogus grounds. It's our job to provide that assurance.
The purpose of authenticating the server is to prevent active attack
on the connection and therefore recovery of the CC#.

> integrity of the domain name infrastructure.
Or any other kind of active attack that redirects the client's request,
such as IP spoofing.

> However, if somebody goes to
> name infrastructure).
This certainly doesn't have to be the case. The most important CA
(Verisign) has authoritative first-hand knowledge of who is entitled
to use a certain domain without having to go to DNS. As domain name
registrar it can check it's own database. This is far superior to
getting the information via DNS requests. 

The primary security threat isn't that Verisign's internal
information is incorrect but rather that an attacker can interfere
with your obtaining that information by tampering with DNS.

Of course, it's possible that some CAs (even Verisign, perhaps) gets
the information from DNS but those CAs have insecure policies.
Discovering that they did so wouldn't invalidate the purpose of
SSL certificates any more than it would be invalidated by discovering
that Verisign left it's private key lying around. You'd just want
to stop trusting said CA.

-Ekr

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

---

From: jim <[email-masked]>
Date: Wed, 07 Nov 2001 08:45:41 -0500

I have to agree with Lynn.  SSL  is inherently insecure just because of its
nature.  It is a "secure pipe for rats to run through"  according to government
sources.  If I were hacking someone for information, I would never hack at the
message in transit as I would have to obtain everyone of the many packets being
sent (the larger the message, the more difficult it is to get it all).  It is
infinitely easier to hack the sending or receiving platform, specifically where
SSL, SSh, and VPNs do not protect the data.  This is the call for PKI.

If the call is to abandon PKI rather than overcome the proprietary solutions
being offered by CA-PKI vendors or that will be offered by application
developers, that is taking the easy and cheap way out.  Note that this is not
easy and cheap to the owner-protector of data, but to the people tasked with
finding the best workable approach.  Certificates and some of the structures of
PKI need to be commoditized to reduce the cost issues.  There is just no reason
for the inflated costs.  I would easily accept that the answer in the HTTP
domain is a middleware approach, and I believe that this august group should be
looking at the approaches that will make PKI valuable to business, not at making
it complex to the organizations that are selling it.

Jim Heimberg, Ph.D.