Re: SSL certificates

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 02/13/04


Date: Fri, 13 Feb 2004 17:57:58 GMT

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
> What kind of compromise do you have in mind? The public key is,
> well, public. Nothing bad happens if the attacker learns what it
> is. If you're afraid the attacker might substitute his own public
> key for the server's, that means you're catching on. The public key
> is wrapped in a certificate which is signed by an issuer (the
> "certificate authority" or CA) that the client has to be
> preconfigured to trust (the CA public key is preinstalled in the
> client). If the CA private key gets loose, the system's security is
> shot. But fortunately, the CA private key is used only at the time
> the server certificate itself is created. That can be done
> completely offline using (say) a laptop computer that spends all its
> time locked in a safe when not in use.

a real attack against the SSL domain name certificate infrastructure
can have nothing at all to do with the CA private key. The certificate
is supposedly used to certify some information (the server's domain
name) that otherwise has integrity issues (because of perceived
integrity problems with the domain name infrastructure). as a result,
the integrity of the certificate is checked by the client (using a CA
public key), then the domain name in the certificate is checked
against the original URL ... and then the validity of the
communication with the server is check using the server's public key
from the certificate.

note however there is supposedly a "chain of trust" ... however the
chain of trust goes all the way back to the authoritative agency that
the CA checks with for validating the information that goes into their
signed certificate. In the case of SSL domain name certificates, the
authoritative agency for who owns a domain name is the domain name
infrastructure; so the trust root ... isn't with the CA ... but is
with the authoritative agency that the CA uses for validating the
information as part of the certification. Trust propagation goes from
the domain name infrastructure to the CA to the client (i.e. the CA is
the trust root for the certificate ... but not for the actual
validatity of the information being certified contained in the
certificate).

However, the catch-22 is that the original justification for these
certificates were trust and integrity issues with the domain name
infrastructure .... which continues to be the trust root .... even
with SSL domain name server certificates. So there are some proposals
to improve the integrity of the domain name infrastructure
... somewhat prompted by the CA industry. However, many of the
integrity improvements for the domain name infrastructure also go a
long way to eliminating the original justifications for the
certificates.

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ 
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm