Re: simple question about certificate chains

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 07/05/05


Date: 05 Jul 2005 11:28:49 -0600


"Richard E. Silverman" <res@qoxp.net> writes:
> No, browsers generally do *not* do this, for several reasons. The
> most obvious is that, since the DNS is insecure, it would be easy to
> get a client to incorrectly accept a certificate by simply spoofing
> its DNS traffic. Browsers should (and generally do) match the
> certificate against what the user types, nothing else -- that's the
> point, to verify that you're connecting to the site you intended.
> It's also why aliases don't work -- for example, suppose a site's
> certificate says www.foo.com, but the server is reachable at foo.com
> as well. If you connect to https://foo.com/ the browser will give a
> warning; it's up to you to decide that a certificate with the name
> "www.foo.com" just as acceptable in this case.

the foo.com vis-a-vis www.foo.com was early problem ... and then they
went to wildcard certificates and wildcard browser processing ... so
that browser would get a *.foo.com ssl domain name certificate and it
would accept for all URLs ending in foo.com.

slightly related posting in sci.crypt
http://www.garlic.com/~lynn/2005l.html#19

what you typed in is matched against the site you are dealing with.

the original major application was e-commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the problem was that a lot of the e-commerse sites found that SSL
reduced their capacity by 80-90 percent. as a result, most sites went
to not invoking https/ssl until you hit the checkout/pay button.

the vulnerability is that one of the SSL objectives was countermeasure
against man-in-the-middle &/or impersonation attacks. if you happen to
be dealing with a bogus site w/o SSL (because nobody uses SSL until
the checkout/pay phase) ... and then you get to the checkout/pay
button ... it is highly probable that any bogus site will supply a URL
(which you haven't typed in) that corresponds to some valid SSL domain
name certificate that they actually posses.

there is actually a funny catch-22.

one of the SSL justifications was as a countermeasure to perceived
integrity problems in the domain name infrastructure.
http://www.garlic.com/~lynn/subpubkey.html#sslcert

however, when somebody applies for an SSL domain name server
certificate, the certification authority must check with the
authoritative agency for domain name ownership. this turns out to be
the same domain name infrastructure that has the integrity issues
giving rise to the requirement for SSL domain name certificates.

basically the certification authority asks for a lot of identification
information so that it can go through the complex, expensive and
error-prone process of matching the applicants supplied identification
information with the identification information on file for the
domain name owner at the domain name infrastructure.

so somewhat with the backing of the certification authority industry,
there has been a proposal to improve the integrity of the domain name
infrastructure by having domain name owners registering a public key
with the domain name infrastructure. An objective is improving the
integrity of the domain name infrastructure by having all
communication from the domain name owner be digitally signed ... which
the domain name infrastructure can authenticate with the on-file
public key (having all communication authenticated, improves the
integrity of the domain name infrastructure, which in turns improves
the integrity of the checking done by the certification authorities).

As an aside observtion ... this on-file public key
results in a certificateless, digital signature operation.
http://www.garlic.com/~lynn/subpubkey.html#certless

The other issue for the certification authority industry, is that they
can now require that SSL domain name certificate applications also be
digitally signed. Then the certification authority can retrieve the
on-file public key from the domain name infrastructure to authenticate
the digital signature on the application. This also turns an
expensive, complex, and error-prone identification process into a much
less expensive, straight-forward and more reliable authentication
process.

The problem (for the CA industry) is that the real trust ruot for the
SSL domain name certificates is the integrity of the ownership
information on file with the domain name infrastructure. Improving
this trust root, in support of certifying SSL domain name certificates
... also improves the overall integrity of the domain name
infrastructure. This, in turns minimizes the original integrity
concerns which gave rise to having SSL domain name certificates.

The other problem (for the CA industry), if they can retrieve on-file
trusted public keys from the domain name infrastructure, it is
possible that everybody in the world could also retrieve on-file
public keys from the domain name infrastructure. One could then
imagine a variation on the SSL protocol ... where rather than using
SSL domain name certificates (for obtaining a website's public key),
the digital certificate was eliminated and the website's public key
was retrieved directly.

In fact, a highly optimized transaction might obtain the website
ip-address piggybacked with the website public key in a single message
exchange (eliminating much of the SSL protocol chatter gorp that goes
on).

In that sense, such an SSL implementation, using on-file public keys
starts to look a lot more like SSH implementation that uses on-file
public keys (eliminating the need for digital certificates, PKIs
and certification authorities all together).

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/