PKI Certificate question

No Spam wrote:
The Company recently implemented PKI certs to digitally sign and/or
encrypt email. Questions I have:

I thought a user should be able to publish her/his Public Key to the
GAL so others could import and use it? In other words, if I wanted to
send an encrypted email to a user, I should be able to retrieve
her/his Public key from the GAL entry and encrypt the message and
attachments. The user retrieving that email would employ her/his
Private key to decrypt.

But the way ours is set up (I think), the user has to send me a
digitally signed email first, and then I have to store the key in my
Address Book.

IMHO, keeping an Address Book kind of defeats the pupose of having the
GAL on the Exchange Server.. Now I have multiple entires for each
person - just to be able to use the PKI cert.

(I do understand I probably need the Address Book entry as a container
for correspndents external to the Company, not on our Exchange server
or its affiliated trusted domains.)

What am I missing as far as The GAL and PKI certs?

the basic technology called asymmetric (key) cryptography; what one key
encodes the other key decodes (differentiate from symmetric key
cryptogray where the same key is used for both encryption and
decryption.

a business process is defined called public key; one of the key-pairs
is identified as "public" and freely made available, the other of the
key-pair is identified as "private", kept confidential and never
divulted.

a business process is defined called digital signatures ... which is a
form of "something you have" authentication ... from 3-factor
authentication paradigm
http://www.garlic.com/~lynn/subpubkey.html#3factor

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

where a hash of a message/document is calculated and encoded with the
private key. the message/document and the associated digital signature
is transmitted. the recipient recalculates the hash of the
message/document, decodes the digital signature with the appropriate
public key and compares the two hashes. if the two hashes are the same,
then the recipient can assume that

1) the message/document hasn't been modified since the digital
signature
2) "something you have" authentication ... the entity transmitting the
message/document has access to and use of the corresponding private
key.

nominally a recipient loads a trusted public key repository with public
keys and caracteristics associated with the public key.

in the early 80s, there was a situation somewhat similar to the
"letters of credit" model from sailing ship days ... envolving offline
email of the period. The recipient dialed their local (electronic) post
office, exchanged email, and hung up. At that point they might have
some first time email from a total stranger ... and not having either
local information about the total stranger and/or access to some other
information source about the total stranger.

certification authorities were defined (somewhat similar to financial
insitutions issuing letters of credit) that validated some piece of
information and created a document that attested to them having
validated the particular piece of information. They digitally signed
these documents called digital certificates.

Recipients or relying parties were expected to have preloaded the
public keys of the better known certification authorities into their
trusted public key repositories. Now when a recipient received some
first time communication from a total stranger ... there would be the
1) message, 2) appropriate digital signature, and 3) corresponding
digital certificate iissued by some well-known certification authority.

The digital signature verification process previously described ... not
morphs into a two-part operation when first time communication with
total strangers is involved. Now the recipient first computes the hash
on the digital certificate and then decodes the digital signature (on
the digital certificate) with the appropriate public key (for the
corresponding certification authority previously stored in the
recipients trusted public key repository). The two hashes on then
compared, if they are equal then the recipient can assume

1) the digital certificate hasn't been modified since the digital
signature
2) "something you have" authentication, that the digital certificate
originated from the corresponding certification authority

now the recipient can recompute the hash on the actual message/document
and decode the (message's) digital signature (using the public key
taken from the attached & validated digital certificate). If the two
hashes are equal, then the recipient can assume

1) the message hasn't been modified since the (message) digital
signature
2) "something you have" authentication as indicated by the information
supplied by the certification authority in the digital certificate.

In all cases ... both PKI operations and certificateless operation
http://www.garlic.com/~lynn/subpubkey.html#certless

the recipient (relying party) has some trusted public key repository
that has been loaded with public keys trusted by that recipient. In the
original case, the recipient is dealing directly with parties that the
recipient knows and trusts.
In the PKI case, the recipient is dealing with total strangers, but
"relies" on their trust in the certification authority.

In the common SSL type scenario ....
http://www.garlic.com/~lynn/subpubkey.html#sslcert

the client browser contacts a server ... and the server returns a
digital signed message along with their digital certificate. The client
validates the digital certificate (by validating the certification
authorities digital signature using the appropriate public key from the
client's trusted public key repository) and then compares the domain
name in the SSL certificate with the domain name typed into the browser
as part of the URL. If they are the same, the client is possibly really
dealing with the server they think they are dealing with. To confirm,
the client has to validate the server's digital signature on the
returned message (using the server's public key taken from the digital
certificate).

the client now generates a random (symmetric) session key and encodes
it with the server's public key and sends back the encrypted session
key and message that has been encrypted with the session key. the
server uses their private key to decode the random (symmetric) session
key ... and then uses that key to decrypt the actual message.

the issue with these kind of SSL domain name certificates is to provide
the client with an extra level of confidence that the server they think
they are communicating with ... is actually the server they are
communicating with.

The process at the PKI certification authority is that somebody applies
for a domain name SSL certificate and provides a lot of identification
information. The certification authority then contacts the domain name
infrastructure and gets the identification on file as to the owner of
that domain name. then the certification authority has the expensive,
error-pone, and time-consuming task of attempting to match the
identification information provided by the certificate applicant with
the identification information on file with the domain name
infrastructure.

If the PKI certification authority feels that the two batches of
identification information appear to refer to the same entity ... they
then will generate a digital certificate (certifying that they have
checked the two batches of identification information).

However, there has been an issue where communication with the domain
name infrastructure has been compromised and incorrect identification
information substituted at the domain name infrastructure. A
countermeasure to such a vulnerability (somewhat backed by the PKI
certification authority ... since the whole trust root for their
certification is accurate domain name identification information on
file with the domain name infrastructure) is to have entities register
a public key when they register a domain name. Then all future
correspondance from the domain name owner can be digitally signed, and
the domain name infrastructure can validate the digital signature using
the onfile public key.

Now, the PKI certification authority could also require that applicants
for SSL certificates, also digitally sign their application. Now the
PKI certification authority can replace an expensive, error-prone, and
time-consuming identification process with a much simpler, less
expensive and reliable authentication process ... by retrieving the
onfile public key from the domain name infrastructure and validating
the digital signature on the SSL certificate application.

this however, creates something of an issue for the PKI certification
authority industry. If the certification authority can make use of
onfile (certificateless) public keys, then the rest of the world might
also (doing away with the requirement for the digital certificates and
therefor also the certification authority).

one could imagine a highly optimized SSL protocol ... that when the
client requests the server's ip-address from the domain name
infrastructure (which is the first step that happens in all internet
operations today) ... that the domain name infrastructure piggy-backs
in the response any related onfile public key and SSL options.

Now the client in their initial message to a server, generates a secret
(symmetricial) session key and encodes it with the public key for that
server (returned by the domain name infrastructure as part of returning
the ip-address) ... and then encrypts the rest of the message (with the
secret session key). The server gets the message, decodes the secret
session key with the server's private key ... and then decrypts the
rest of the message with the secret session key.

there are similar scenarios for almost all other PKI relying-party
operations when it turns out that the relying-party actually has their
own repository about the communicating party and/or have online access
to an authoritative agency with real-time, online information about the
communicating party. sample recent posting on the subject:
http://www.garlic.com/~lynn/aadsm21.htm#4