Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- What is a Certificate?
Re: What is a Certificate?
Certificate binds your public key with your identity, confirmed by
Certificate Authority by its signature. The public key itself is not
enough -- you have to be sure that the public key really belongs to the
person whose name/address is in it. To verify the signature, you need
something you can trust. For this purpose browsers have some
certificates of well known root CAs built in. When you start an SSL
session, your browser gets a certificate for that website and the
certificates of all CAs (trust path) until it reaches self-signed
certificate of root CA it knows. If it is not able to do it, it warns
you that it cannot confirm the identity of that website.
The same applies to other uses of PKI -- e-mail and so on. For example,
if you want to encrypt a message, you have to get a public key of the
recipient. You use that key to encrypt a symmetric session key, which in
turns is used to encrypt a message. If you get this key (in the form of
certificate) from public source (web page, e-mail, directory server)
then you have to confirm that this key is really belongs to that person
-- you (your software) validate trust path using a set of root CA's
certificates you trust.
- Anne & Lynn Wheeler
April 22, 2005, 7:06 am
Re: What is a Certificate?
note with respect to previous posting
on SSL domain name certificates
for original e-commerce ... minor reference:
the basic idea is whether you are really taling to the webserver you
think you are talking to ... or are you talking to the webserver that
corresponds to the URL that you typed in.
the problem was that most webservers found that the SSL overhead
decreased their webserver capacity by at least 80% ... so SSL was
quickly limited to just the payment portion of the e-commerce shopping
so no longer do you typically type in a URL and have an immediate SSL
session that validates that the domain name in the URL (you typed) is
the same as the domain name in the SSL domain name certificate sent
back as part of SSL handshake (since there is no SSL handshake, there
is no SSL domain name validation).
Instead, you wait until you get to shopping experience checkout and
select the PAYMENT button ... which takes you to a URL SSL session
provided by the PAYMENT button.
The problem is that if you really aren't at the website you think you
should be at ... and there is some possible slight-of-hand or
faudulent activity afoot ... then the basic shopping experience could
be occuring at a fraudulent site ... and there is no SSL domain name
certificate validation that the website you are talking to is the same
as the URL you typed in.
Now if you actually happened to be at a fraudulent site ... and they
put up a PAYMENT button ... it is likely that the fraudulent site will
have obtained a valid SSL domain name certificate ... for some
doamin/host name that they actually registered ... and the PAYMNET
button will invoke an SSL URL that corresponds to the certificate that
they do have (their SSL certificate is validating the domain that they
provided in their PAYMENT button ... and not validating something that
So everything appears to work ... but it actually isn't correct.
This is separate from the issue mentioned in the previous postings
where the certification authority ... in ceritifying the request for
an SSL domain name certificate ... has to certify that the requesting
entity is entitled to request a SLL domain name certificate for that
domain. They do this certification by checking with the authoritative
agency for domain name ownership ... and require that somebody
requesting an SSL domain name certificate is actually associated
with the ownership of that domain.
The problem is that the authoritative agency that the certification
authorities have to check with (responsible for domain name ownership)
is the domain name infrastructure. The possible integrity issues with
the domain name infrastructure is what gave rise to requiring SSL
domain name certificates in the first place. So if there is an
integrity issue with the domain name infrastructure .... and the
domain name infrastructure is the authoritative agency responsible for
domain name ownership ... then there is possibly integrity issues with
domain name ownership (various stories about domain name hijacking
over the years).
So it turns out that the actual trust "chain" for domain name
ownership ... doesn't stop with a "ROOT" certificaton authority
.... but continues back to the authoritative agency responsible for the
information that is being certified by the certification authorities.
If the information is wrong at the authoritative agency responsible
for the information being certified ...then the certification
authorities can be certifying invalid information ... aka somebody
does a domain name hijacking and then applies for a domain name
certificate (this is different than somebody obtaining any possible
domain, applying for a valid SSL certificate for that domain, and then
using it in conjunction with a fraudulent e-commerce site and a
fraudulent "PAYMENT" button).
As mentioned in the previous posts ... a solution for improving the
integrity of the domain name infrastructure ... to better improve the
integrity of the information that is being certified by the
certification authorities .... is to start requiring registration of
public keys at the same time domain names are obtained. Then they
require that SSL domain name certificate application be digitally
signed. The certification authorities then can validate the digital
signature on the application by doing a real-time, online retrieval of
the "on-file" public key from the domain name infrastructure. Note
that this is a digital signature validation with public key in a
certificateless operation ... using online, realtime access instead of
stale, static certificates that were originally designed to address
the offline email authentication problem in the early 80s.
The issue (or catch22) then becomes if the certification authorities
can do certificate-less authentication of digital signatures with
on-file, online, real-time public keys ... then it is possible that
others could also start doing certificate-less authentication of
digital signatures with on-file, online, real-time public keys (rather
than redundant, superfluous, static, stale certificate-based public
keys) ... aka modify SSL protocols to directly do real-time retrieval
of public keys from the domain name infrastructure instead of
relying on public keys in stale, static certificates.
Anne & Lynn Wheeler | http://www.garlic.com/~lynn /