Mike and Warwick,
I have been following your exchanges with considerable interest and
uncharacteristic silence, having been preoccupied with some problems on the
home front. But Mike's latest contribution provides an elegant mechanism with
which to fix several long-standing problems.
The fact that the RSA algorithm can be usd for both signatures and encryption
doesn't mean that it SHOULD be so used, at least with the same key.
Your scheme would allow the use to select a new encrytion key when it seemed
desirable to do so, and yet confirm under the authority of his signature key
that it is in fact his. Very neat and simple -- much better than generating and
signing two keys, and having to revoke both at the same time. With the new
mechanism you never have to revoke an encryption key (which doesn't make much
sense in any case, if the ciphertext has already be captured), you just put out
a new one. It should also make archiving encrypteed documents somewhat easier,
although we ought to think about the mechanism that is to be used to record the
keys a litle bit more.
You mentioned using a different key for an on-line certificate revocation
function. As Sead Muftic and I have discussed at some length, for electronic
commerce and EDI, it makes much more sense to have the CA operate a certificate
and/or document VALIDATION service, rather than a certificate revokation
service.
Again, I think that we have attempted to be too economical with respect to the
use of one key for two functions, and have ended up with a system that is an
unworkable mess from the standpoint of determining whether a digitally signed
document was signed using a key that was valid at the date and time the
document was created, because of the necessity for trusted and synchronized
clocks and/or trusted third parties.
The existing certificate revocation mechanism works just fine for determining
in real time whether you wish to create an encrypted document to be sent from
Alice to Bob, i.e., if Alice wants confirmation that Bob is (still) who he
claims to be. If Bob's private key is compromised a millisecond after the
message was sent, it is too late in any case.
However, in the case of a digitally signed document, although it may be
ineresting and important to know that the originator has disavowed that
particular key at some later point in time, if he signed a binding transactioin
with that key he should not be allowed to repudiate that document just by
revoking his certificate. Otherwise we can write checks in disappearing ink, or
wait until we see which way the stock market moves before deciding whether we
really wanted to buy ro sell on a particular day.
Rather than having to have synchronized and trusted clocks or elaborate thrid
party mechanisms, it is much simpler to ask the CA to validate that the fact
that user had not revoked his certificate as of the moment (or slightly later)
that a document was created, by simply countersigning the original document
with a statement as to the certificate's validity. (That does not necessarily
make the CA liable for the transaction, only for the validity of the user's
certificate.] Since the CA issues the certificate in the first place and has to
issue the CRL, the CA can speak ex cathedra as to the validity of a certificate
at th moment in which a document arrives to be validated. This can most easily
be accomplished by having the originator of the document send it to the CA's
certification validation daemon for signature and return, and upon its return
send it to the intended recipients. With a little more trickery in the use mail
headers the CA could send it on directly, but this might undesirably entangle
the certification function with a particular email convention.
Steve Kent has opposed thie notion of an online CA in the past, raising the
valid objection that keeping the CA's validation key online was not
sufficiently secure given the available and affordable computer security
systems. But separating the certificate validation key from the CA's primary
key goes a very long way towards overcoming that objection, and placing the
function of the daemon in a separate box that is not addressable via the
network (e.g., connected via a direct serial connection) would remove most if
not all of the remaining vulnerabilities
Come to think of it, the user might like to be able to keep his digital
signature key on line for his convenienceas well, but keep his "master"
signature key off line. Wouldn't it therefore make sense for the user (not just
a CA) to have a short duration signature key that he can control, instead of
having to get a new certificate from his CA every few days or even minutes?
This would certainly please Frank Sudia and the X9F1 crowd, who would like to
authorize a key for only a short duration. and it might also be a way of
handling the delegation of authority issue and the manager/secretary problem,
but these probably deserve a little more thought.
I would like suggest that you go ahead and codify those particular uses of the
UKM that have been discussed, specifically the encryption key and the
short-term signature key, so that we will have an ASN.1 stake in the ground as
to the intended uses. In particular, I don't think that it would be wise to
allow individual users or any developer to come up with a new proposed usage
and his own encoding scheme, so these uses should be registered.
Bob
Robert R. Jueneman
Mgr., Secure Systems
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
Voice: 1-617-466-2820 (rolls over to cellular if no answer -- have patience)