Re: Is symmetric key distribution equivalent to symmetric key generation?
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: Thu, 25 Aug 2005 10:29:25 -0600
email@example.com (David Wagner) writes:
> Well, that's a different question! There are many possible ways.
> You might have that person's public key. You might have a secure
> channel through which you can request the public key. You might be
> able to ask some other trusted party ("Verisign") for that person's
> public key. That person might provide a certificate signed by some
> other trusted party ("Verisign"). One might use a hierarchical PKI
> (a la x509) or a web of trust (a la PGP). There are many answers,
> and which one is right is going to depend upon the application, upon
> the trust model, upon compatibility requirements, etc..
> But whether you use a key transport protocol, or a key agreement
> protocol, doesn't change the need to answer the question, and
> doesn't change the set of answers available. How to get the other
> endpoint's public key is orthogonal to what kind of key exchange
> protocol you use.
note ... in general ... all of the public key related infrastructures
have some out-of-band trust protocol.
basically the dependent or relying party ... has a trusted repository
of (trusted) public keys that was loaded by some out-of-band trust
one can consider that originally trusted public key repositories
consisted only of individual entity public keys.
the scenario of PKIs, certification authorities, and digital
certificates ... was targeted at addressing the offline email scenario
of the early 80s; an individual dialed their local (electronic) post
office, exchanged email, hung up ... and then possibly had to deal
with first-time communication from total stranger and had to resources
available to resolve any information about the stranger. this is the
"letters of credit" model from the sailing ship days.
to address this situation, certification authorities were created and
individuals had their trusted public key repositories loaded with
public keys of certification authorities.
people wishing to have first-time communucation with total stranger
could go to (well known) certification authority and register their
public key along with some other information. The certification
authority would validate the provided information and package it into
a digital certificate that they was digitally signed by the
the individual now could digitally sign a message/document and package
up the message/document, the digital signature, and their digital
certificate and send off this first time communication to a stranger.
the stranger/recipient (hopefully) having a copy of the appropriate
certification authority's public key in the trusted public key
repository could validate the digital signature on the digital
certificate, then (trusting the digital certificate) using the
sender's public key (from the digital certificate) validate the
(sender's) digital signature on the message/document. The
stranger/recipient then could relate the message/document to the other
information certified in the digital certificate.
one of the issues in the early 90s with the x.509 identity
certificate, was what possible certified information might be of
interest to future unanticipated and unspecified strangers. there was
some direction to compensate (making the digital certificate more
useful) by grossly overloading the digital certificate with enormous
amounts of personal information.
in the mid-90s, some number of institutions were started to realize
that digital certificates overloaded with enormous amounts of personal
information represented significant privacy and liability issues. as
a result, you started to see the appearance of relying-party only
basically the enormous amounts of personal information was replaced
with some sort of database index where all the personal information
individuals registered their public key with an institution (which was
placed in a secure repository containing information about the
individual), the institution then created a digital certificate
containing the individuals public key and an index to the
database/repository entry. a copy of this digital certificate was
given to the individual.
for transaction scenar, the individual created a transaction,
digitally signed the transaction and packaged the transaction, the
digital signature and their digital certificate and transmitted it
back to the institution.
the institution took the transaction, extracted the
database/repository value from the transaction, retrieved the
database/repository entry, and used the public key in their repository
to validate the digital signature.
the digital certificate need never, ever be referenced ... and
therefor it was relatively trivial to show that the digital
certificate was redundant and superfluous.
The other way of showing that the digital certificate was redundant
and superfluous was that the relying-party-only certificate violated
the basic PKI/certification model ... being required for first time
communication with a stranger. When the receiving party already had
all the possible information ... there was no point including the
digital certificate in the transmission.
there was a 3rd approach. in the financial transaction world, the
typical payment transaction is on the order of 60-80 bytes. the
financial industry relying-party-only digital certificates of the
mid-90s could add 4k-12k bytes certificate overhead to the basic
transaction. Not only were the replying-party-only digital
certificates redundant and superfluous ... they could represent an
enormous payload bloat of a factor of one hundred times.
so x9 financial standards group had an effort for "compressed" digital
certificates. however, a perfectly valid information compression
technique is to not include any fields that the recipient is known to
already have. since it can be shown in these cases that the recipient
has a superset of all fields in the digital certificate, it is
possible to compress such digital certificates to zero bytes. rather
than claiming it is unnecessary to include redundant and superfluous
digital certificates in every transmission, an alternative is to
demonstrate that it is possible to include zero-byte digital
certificates in every transmission.
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/