Tom,
The response I provided to Mark is somewhat more than an
"opinion" as you suggest, and I'll explain why as I respond to your
analysis below.
If you want to communicate privately with a user that you have
not dealt with before you must discover his CA or KDC and get a
certificate or a secret key before you send the message. Whats the
real-time difference in these? In either case you can get the
certificate (or key) from the CA (KDC) directly or from the
interchange partner.
The analysis here is inaccurate in several respects. In a secret key
system an originator needs to contact a KDC that serve him, and that
KDC must either serve the recipient(s) or must locate and contact
KDC(s) that serve the recipients. It is generally the case that you
cannot contact the interchange partner (electronically) for symmetric
key distribution because such distribution requires a confidentiality
and integrity secure channel, which is not available via a network (or
we would not be going to all of this trouble in the first place). So,
only in the case of asymmetric cryptography could one contact a
potential communicant directly and recieve the necessray set of
certificates and CRLs to enable authenticated, confidential communication.
KDCs are very sensitive machines because of the (interchange) keys
available to them, so there is a need to balance the desire to
minimize the number of KDCs (for security) against the need to provide
continuously available service. This means that there are substantial
costs associated with maintaining highly available KDCs to serve large
communities. In the asymmetric key management system described in
1422, the originator can fetch the requisite certificates for
recipients, their CAs and PCAs (and associated CRLs) from ANY
repository or set of repositories. Because the certificates are
signed data structures there is no need to store them in machines that
have the sort of security constraints typically associated with KDCs.
Thus there is good reasons to believe that it is easier to provide
highly available access to computers holding certificates and CRLs
than to KDCs.
In contrast, the sensitive key management machines (somewhat analogous
to KDCs in the level of sensitivity) are used by CAs and PCAs to sign
certificates and CRLs and they need not be continuoulsy available
because they perform their operations, signing certificates and CRLs,
relatively infrequently. Also, there is a major difference in the
level of sensitivity associated with KDCs vs. the machines used by CAs
and PCAs to sign certificates. The former have available keys that
are used to encrypt keys that are used to encrypt user data (pardon
the indirection). This makes the KDCs quite sensitive. If an
adversary were to covertly acquire keys held by a KDC, he could
monitor communications without knowledge of the communicants. In
contrast, a CA or PCA need never have access to a user's private key.
The only way an attack on a CA or PCA can result in disclosure of
traffic is if the CA's or PCA's private key is used to issue bogus
certificates, an activity that leaves a definate trail in the form of
the illicit certificates. If an adversary computed a MIC on a message
in a secret key system the evidence would be inconclusive, since not
only the KDC buit also both originator and receiver had access to the
requisite interchange key.
Lets look at repudiation, the key that you get in the secret
case is valid until revoked by the sender, in the public case the
certificate may be revoked at any time and you must get a CRL AFTER
RECEIPT OF THE MESSAGE to be sure that the message was sent
with a valid certificate. The CA (or PCA) is a single point
of failure in this case. It seems to me that the secret key
distribution case works better here.
First, I don't understand your reference to repudiation here. Secret
key systems with KDCs do not, by themselves, provide non-repudiation
services, reflected by the fact that if one employs symmetric key
management in PEM you do not get a basis for sender non-repudiation
(as explained in 1421). One has to go to great lengths to provide a
non-repudiation service analogous to that offered by public key
cryptography using symmetric keys. Both systems require timestamping
or an equivalent mechanism to provide a reference point to indicate
when a document was signed, relavtive to a point when a signer may
delcare his key compromised. While CRLs aren't perfect in this
regard, their lack of instantaneous revocation is a side effect of not
requiring realtime, continuosly available key management facilities.
In the PEM environment, the model for symmetric key management calls
for acquiring an interchange key, e.g., from a KDC, and then using it
for communication between a pair of communicants for some time, vs.
getting a new interchange key each time (also described in 1421).
This says that a recipient who already has an interchange key in place
with an originator would not normally contact a KDC to verify that the
interchange key has not been compromised by the other party. For a
KDC to provide a very rapid response to key compromise it would have
to be continuously available AND the recipients would have to contact
it frequently, e.g., upon receipt of each message. That would
certainly impose a very different realtime availability demand on KDCs
vs. certificate and CRL repositories.
The trust issue is one of degree and not of substance. In
either case there needs to be a chain of trust (or web of
trust in the non-hierarchical public case). It may be that
the public case is easier to administer, but there is no fundamental
difference in the measure of trust that CA or KDC must have
for us to believe them. Check out X9.30 if you want to see
what level of trust the bankers will require of a CA.
No, as noted above, there are qualitative, not just quantative
differences in the trust that must be accorded to KDCs vs. CAs. This
is true even if the concerns are primarily authentication and
integrity vs. confidentiality. I think the right reference for the
level of trust required of a CA is the ongoing work of the ANSI X9F1
committee on certificate management standards, rather than the X9.30
work. Irrespective of that document, all of the preceeding discussion
about what one trusts a CA to do vs. what one trusts a KDC to do, how
relatime responsive each must be, etc. are all objectively correct
observations, irrespective of the particular constraints established
any specific user community. The stringency of CA requirements
imposed in different communities may be where one encounters
quantitative vs. qualitative differences.
Steve