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


Relevant Pages

  • Re: Proposal for a new PKI model (At least I hope its new)
    ... That is say I trust Paul Rubin's public key. ... two basic reasons for the SSL server domain name certificate: ... certificates have to check with the domain name infrastructure to see ... CA/PKI industry is that public keys be registered with the domain name ...
    (sci.crypt)
  • Re: TLS-certificates and interoperability-issues sendmail / Exchange / postfix ..
    ... > to assert that certificate validation doesn't happen, ... this trusted public key store contains public keys of that the ... signed by the CA. this digital certificate is returned to the "key ...
    (comp.security.unix)
  • Re: New Method for Authenticated Public Key Exchange without Digital Certificates
    ... you are referring to any situation where there might be some trust ... resorting again to the merged security taxonomy and glossary ... as definitions specifically within the context of a Public Key, ... Certificate, Certification Authority environment. ...
    (sci.crypt)
  • Re: Creating a root CA to encrypt mail
    ... The other way is using the Certificate Assistant. ... You don't need another keychain for the keys and certificates. ... CAs certificate you have to set it to allways trust, ... you need the public key of the recipent in your ...
    (comp.sys.mac.system)
  • Re: What is a Certificate?
    ... what exactly is a certificate? ... > I've read that it is a private key / public key pair. ... register public keys of something called "certification authorities" ... An example is the SSL domain name digital certificate scenario. ...
    (comp.security.misc)