Edward A. Feustel wrote:
> Using mod_ssl with an Apache web service, you can specify mutual
> authentication.
> In this case the serving program and the client program both "sign" data,
> that is
> use their private keys to encrypt data that they send to the other. Using
> the public
> key of the serving program, the client program decrypts the encrypted data.
> The
> serving program does the same with the encrypted data provided by the client
> program.
> Assuming a correct decryption for both pieces of data (and assuming that the
> private keys have not been compromised), both the client and the server have
> been authenticated.
>
> Usually https web transactions only require that the server be
> authenticated.
>
> All this code could "easily" be adapted to provide SSL authentication of
> both parties
> in your P2P case.
the basic technology is asymmetric key cryptography ... what one key
(of a key-pair) encodes, the other key decodes (to differentiate from
symmetric key where the same key is used for both encoding and
decoding).
there is a business process where one key (of the key pair) is
identified as "public" and made readily available; the other key is
identified as "private" and kept confidential and never divulged.
there is a business process called digital signature where a hash of a
message/document is calculated and encoded with the private key,
resulting in the digital signature. the originator then transmits the
document/message along with the digital signature. The recipient
recalculates the hash, decodes the digital signature with the
appropriate public key (taken from the recipient's trusted public key
repository) and compares the two hashes. If the two hashes are the
same, then the recipient assumes that
1) the message hasn't be modified since the digital signature was
calculated
2) "something you have" authentication, i.e. the originator has access
and use of the corresponding private key.
to somewhat address the business opportunity analogous to the letters
of credit from the sailing ship days ... there is business process
involving PKI, certification authorities, and digital certificates. The
target is somewhat the offline email from the early 80s, i.e. dial-up
the (electronic) post-office, exchange email, hang-up and process
email. The recipient may be dealing with first-time communication from
total stranger with no recourse to information about the stranger.
in this scenario, the stranger has gone to a certification authority
and had certain information certified. the certification authority
issues a digital certificate containing the certified information and
the applicant's public key. this digital certificate is digitally
signed by the certification authority. in this scenario, the stranger
appends their digital ceritifcate to the digitally signed
message/document (as in the above description). the recipient first
performs the digital signature verification process on the digital
certificate issued by the certification authority (i.e. retrieving the
certification authority's public key from the recipient's trusted
public key respository to verify the certification authority's digital
signature on the digital certificate). once the digital certificate has
been validated, the recipient then retrieves the originator's public
key from the digital certificate (having already verified the
certification authority's digital signature) and uses the originator's
public key to verify the digital signature on the actual message.
Given that the originator's digital signature verifies, the recipient
now can use the other information in the digital certificate to
determine how to deal with first-time communication from total
stranger.
one of the issues that came up with this approach was the work on x.509
identity certificates in the early 90s. an objective was to require
that an x.509 identity certificate would be appended to all digitally
signed operations, turning even the most simple authentication
operations into heavy duty identification operations (even when first
time communication between complete strangers wasn't involved). The
other issue was that it wasn't necessarily clear to certification
authorities, at the time, exactly what identification information might
be required by relying parties in the future ... so there was some
direction to overload x.509 identity certificates with enormous amounts
of personal information.
in the mid-90s there was some direction involving relying-party-only
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
because of the realization that enormous amounts of personal
information in x.509 identity certificates represented significant
privacy and liability issues. as a result, the entity information from
the digital certificate was moved into some sort of repository entry at
the relying-party, and replaced in the digital certificate with some
sort of index value into the repository. however, it is trivial to show
that such digital certificates became redundant and superfluous, in
part because it basically invalidates the fundamental justifications
for PKIs ... i.e. to provide a solution for first time communication
between complete strangers.
for some topic drift ... a couple recent related postings on the
subject
http://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate
based login (PKI) w/o real smart card
http://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on
high-assurance certificates
P2P Authentication 
Linear Mode
