Re: What is a Certificate?

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


Date: Fri, 22 Apr 2005 01:54:25 -0600


"TC" <golemdanube@yahoo.com> writes:
> I understand public key encryption, but I do not understand the
> terminology surrounding security certificates.
>
> For starters, what exactly is a certificate? On the Microsoft website,
> I've read that it is a private key / public key pair. Verisign has told
> me, however, that a certificate is a public key signed with a
> certification authority's private key. Which is it?

basically there is technology with asymmetric encryption (one key
encrypts, another key decrypt ... they form a key pair).

public key encryption involves a business process for doing things
like digital signature authentication. the businees process designates
one of the keys from the key pair to be a private key which will be
kept confidential and never divulged or exposed. The business process
designates the other key as public and allows it to be made widely
available.

for authentication purposes, public keys can be registered
in place for pin/passwords &/or other shared-secrets
http://www.garlic.com/~lynn/subpubkey.html#secrets

a person then can use the private key to encode a hash of some data
... creating a digital signature. the digital signature can be
transmitted and verified using the registered public key. From
3-factor authentication paradigm

* something you have
* something you know
* something you are

... the verification of a digital signature with a public key implies
"something you have" authentication ... i.e. the originator has
exclusive access to the private key producing the digital qsignature.
The advantage of public key vis-a-vis a shared-secret ... is the
public key can be used for verifying a digital signature ... but can't
be used for impersonation by creating a digital signature (while
anybody with access to a registerd shared-secret can not only used the
shared-secret for verification but also for impersonation).

digital certificates were originally targeted at the offline email
paradigm from the early 80s ... where somebody called the local
(electronic) postoffice, exchanged email and hung up. The scenario was
if email was received from somebody with no prior contact ... how was
the receiver going to authentication a complete stranger ... never
having contact with the person before.

In the PGP secure email model ... you register the public keys of the
parties that you are acquanted with. In the offline stranger scenario
... you have no method of validating whether any specific public key
belongs to a specific person. So the idea was that in your trusted
public key repository ... in addition to directly registering public
keys of entities you directly communicated with ... you would also
register public keys of something called "certification authorities"
(or CAs). CAs would create things called digital certificates where
they bind some information about an entity to their public key ...
and the digital certificates are digitally signed by the certification
authorities.

This is basically the "letters of credit" model from the sailing ship
days. The recipient gets a communication that is digitally signed and
has an appended digital certificate. The recipient verifies the CA's
digital signature (on the digital certificate) using the CA's public
key stored in the recipient's trusted public key repository. Having
validated the CA's digital signature, they can now trust the contents
of the digital certificate ... from which they pull the originator's
public key ... to validate the digital signature on the actual
message. This provides for indirect authentication when a total
stranger is involved and the recipient has no recourse to online,
electronic, and/or other forms of timely communication to validate
communication from an unknown stranger. This is compared to the PGP
trust model ... where individuals load their trusted public key
repository with the actual public keys of individuals they communicate
with ... as opposed to having it loaded with public keys of
certification authorities (since the actual public keys are directly
available ... there is no need for certification authorities and/or
digital certificates, certified by certification authorities).

An example is the SSL domain name digital certificate scenario. The
issue were various perceived integrity issues with the domain name
infrastructure and whether a browser client could actually trust that
the URL they had typed into the browser ... corresponded to the
webserver they were talking to.

The browsers have a preloaded trusted public key store.of numerous
recognized certification authorities. Servers contact one of these
certification authorites to get a SSL domain name digital certificate
containing their domain name and their public key (digitally signed by
the certification authority). The browser contacts the server in a SSL
session. The server returns a digitally signed message and their SSL
domain name certificate. The browser validates the CA's digital
signature on the returned digital certificate (using the CA's public
key that has been preloaded into their browser) ... and then uses the
public key from the digital certificate to validate the digitally
signed message. If that works ... they then can check whether the
domain name (in the supplied digital certificate) matches the domain
name that they typed in as part of the URL (aka prooves that the
server you think you are talking to is actually the server you are
talking to)..

So an issue for the SSL domain name certification authorities is that
an applicant supplies some amount of identification information. The
certification authority then must cross-check that identification
information on file with the authoritative agency responsible for
domain name ownership. This identification matching process is an
error prone, time-consuming, and expensive activity. It also turns out
that the authoritative agency responsible for domain name ownership is
the domain name infrastructure ... which has the integrity concerns
giving rise to the need for SSL domain name certificates.

So somewhat a proposal backed by the SSL domain name certification
authority industry ... is that applicants for domain names should also
provide a public key as part of domain name registration. Use of this
"on-file" public key could help with a number of the existing domain
name infrastructure integrity issues. Also the certificaton authority
industry could require that SSL domain name certificate applications
be digitally signed. Then the certification authority can replace an
error-prone, expensive and time-consuming identification matching
process with a much simpler and more reliable authenticaton process
(they simply retrieve the on-file public key for that domain from the
domain name infrastructure and validate the digital signature on the
SSL domain name certificate application ... note that this is a
certificateless operation being able to do real-time online retrieval
of public keys instead of getting them from a stale, static digital
certificate).

All well and good ... however it represents soemthing of a catch-22
for the certificaton authority industry. By improving the integrity of
the domain name infrastructure ... they improve the integrity of their
certifying that the entity requesting the domain name certificate is
the actual owner of the domain name. However, the questions about the
integrity of the domain name infrastructure is a major factor for
needing SSL domain name digital certificates. Improving the integrity
of the domain name infrastructure reduces the requirement for SSL
domain name digital certificates.

The other issue is if there are now public keys on-file for real-time,
online retrieval ... for access by the certification authorities in
certificateless digital signature authentication ... then it would
also be possible for other entities to also do real-time online
retrieval of such public keys. One scenario would be to modify the the
SSL protocol for certificateless operation by retrieving the
appropriate public key directly from the domain name infrastructure.

misc. past postings about SSL domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

misc. past postings about certificateless public key authentication
http://www.garlic.com/~lynn/subpubkey.html#certless

recent posting on other aspects of certificaton authorities and
digital certificate business model
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates

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


Relevant Pages

  • 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: Public Encryption Key
    ... encrypt the message with the recipient's public key (or ... the two can be combined by: first do a digital signature of the ... certificate, certifying the validity of the assertion (ex: ...
    (comp.security.misc)
  • Re: Public Encryption Key
    ... encrypt the message with the recipient's public key (or ... the two can be combined by: first do a digital signature of the ... certificate, certifying the validity of the assertion (ex: ...
    (sci.crypt)
  • Re: Is symmetric key distribution equivalent to symmetric key generation?
    ... > channel through which you can request the public key. ... That person might provide a certificate signed by some ... then (trusting the digital certificate) using the ... for transaction scenar, the individual created a transaction, ...
    (sci.crypt)
  • Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked
    ... to a public key posted in whois. ... infrastructure to update the domain name inframation. ... To some extent the SSL domain name vendors were supporting such DNSSEC ... name certificate application be digitally signed. ...
    (comp.arch)