Steve> 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.
Sorry to continue this thread to such a point, however, I find the
constant attacks on Secret Key Management to be just as unfounded
as they are unending. Public Key Management has much to recommend
it. There is no need to spread incorrect calumny against Secret
Key Management to "prove" the superiority of Public Key Management.
In fact, I would be suspicious of any technique whose partisans based
their support on bad mouthing the opposition. Please don't anybody make
the assumption that I am against Public Key Management, quite the
contrary. But a bad argument in favor of a good technique is worse
than no argument at all.
- -
Steve> 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.
Correct
- -
Steve> 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).
Incorrect - Please see ANSI X9.17 or the appendix in my book "Secure
EDI" on key management. I will summarize the technique - Party A
encrypts a random value and sends it to the Key Translation Center
(CKT) which then decrypts it and reencrypts it with Party B's key.
This is then returned to Party A who can send it, together with a
message to Party B. If A & B do not share a CKT, then the infra-
structure needed to support the interchange becomes difficult to
create, but easy to operate once established; a situation not too
different from that we find now in Public Key Management.
And what about the Public Key Management - First I need to discover
a CA (operating under an appropriate PCA's policy) that will get me
party B's chain of certificates back to IPRA. Possibly I could get
this from party B, but I would still need to go to my PCA to get
the current CRL's. I certainly don't trust party B to give me the
CRL that states his certificate has been revoked. But one of the
missing pieces of PEM is the message to request the CA's from party B.
- -
Steve> So, only in the case of asymmetric cryptography could one contact a
potential communicant directly and receive the necessary set of
certificates and CRLs to enable authenticated, confidential communication.
An incorrect premise leads to an incorrect conclusion.
- -
Steve> 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.
Quite true - but let's talk about the care needed to protect the private
component of the PCA, or of any of the CA's. The risk, in dollars,
is the same regardless of the type of the management technique. It is
exactly equal to the dollar value of all the transactions that are
protected under each of the centers (either KDC or CA).
- -
Steve> 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.
This is a different story than the one you tell when the discussion
is on how to "prove" that a message was signed by a valid certificate.
As I recall your position it was: 1) the receiver must get a CRL that
was dated after the receipt of the message to be verified, 2) the
only guaranteed source of this CRL was "his" PCA, 3) he must "TRUST"
his PCA to give him the latest CRL so that he knows the certificate
was not revoked prior to signing.
- -
Steve> 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 continuously available
because they perform their operations, signing certificates and CRLs,
relatively infrequently. ..more..
This seems at odds with the PCA as the only guaranteed, trusted source
of CRL's. If I don't get a signed and dated response from the PCA, how
will I know that the CRL I have is the very latest? If I don't have
that, how do I know the message was sent with a valid certificate?
- -
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.
Steve> First, I don't understand your reference to repudiation here.
.. more on non-repudiation..
Sorry - I should have said revocation. Its just that revocation seems so
severe to me, that I class it right up there with repudiation.
- -
Steve> 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.
Right - I find that one of the advantages of Secret Key Management
and one of the disadvantages of sending unacknowledged CRL's.
- -
Steve> 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 real-time availability demand on KDCs
vs. certificate and CRL repositories.
Wrong - COMPLETE VERIFICATION of a message requires a CRL dated after
the message, hence the PCA must be continuously on-line! Or at least
the two cases must be recognized as having the same real-time
constraints.
- -
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.
Steve> No, as noted above, there are qualitative, not just quantitative
differences in the trust that must be accorded to KDCs vs. CAs.
...all of the preceding discussion
about what one trusts a CA to do vs. what one trusts a KDC to do, how
real-time responsive each must be, etc. are all objectively correct
observations, ...
Objective? Correct? - Sorry, but that's not what I see.
Peace ..Tom Jones