[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CRL format revision -Reply -Reply
> From bjueneman@novell.com Fri Aug 9 01:34 EST 1996
>
>> The whole point of public key cryptography is to remove the need for on-line
>> services which mediate the establishment of secure communications. By
>> requiring a trusted directory service (or validation or whatever you want to
>> call it) to be available you would defeating any advantages of public key.
>
> Hmmh. I'll grant that there is a certain amount of truth to your argument, but
> I think this may be going too far. For example, why did X.500 provide
> for strong authentication via X.509, since the directory was obviously on-line?
While the Directory is on-line, it is possible that the DSA which contains the
user's entry (and therefore certificate) may not be contactable. Besides, I think
the authentication protocols of X.509 are FAR more general than just for the Directory.
> Well, I happen to be rather pro-X.500, but there are some differences.
Good to hear...
> Even if you have a trusted X.500 directory, there may be differences
> in the domain of trust. Although having the CA withdraw the certificate
> from the directory wold be an excellent practice, it may not happen,
> and conceivably the directory operator could put it back! You clearly
> can't sign a now-absent certificate, so we need a stronger, more
> positive revocation mechanism.
The question of domains of trust are more concerned with how you administer
the Directory, rather than any lack of functionality in either X.500 or the
CRLs. It is quite feasible for the CA to administer it's own part of the
Directory tree, and so have complete control over lodging and removing
certificates or CRLs.
> checking behavior accordingly. Getting the CRLs on CD would allow
> me to validate his identity without even accessing the directory.
This is a fundamental property which has to be allowed. For many applications
availability will be far more important than "security" (in the sense of
authentication). You don't want to require a single point of failure in
a system just because there is a slight chance that a certificate has been
revoked.
> >Now about this wheel thingy... how about if we make it square... it would be
> easier to implement that way....
>
> Too many joints. I can mathematically prove that three joints are
> both necessary and sufficient, and so obviously your wheel thingy should
> be triangular. :-)
I know we can have STISW (Simple To Implement Square Wheel) and the MJTW
(Minimal Joint Triangular Wheel) and let the market decide. That round
ISO wheel will never catch on ! Too complex !
Cheers,
Michael Warner
Telstra Research Labs