Date: Tue, 15 Jun 93 14:27 EDT
From: TCJones(_at_)dockmaster(_dot_)ncsc(_dot_)mil
Subject: CRL's triage
To: tis(_at_)dockmaster(_dot_)ncsc(_dot_)mil, pem-dev(_at_)tis(_dot_)com
Cc: peace(_at_)bix(_dot_)com
Message-Id: <930615182738(_dot_)233020(_at_)DOCKMASTER(_dot_)NCSC(_dot_)MIL>
2. I wonder, if you don't trust some CA to send you CURRENTLY > >>
VALID certificates in the path of your partner, how can > >> you trust
the same CA to send you the CRL, when both > >> messages are THE SAME
TYPE of the PEM letter (MIC-ONLY).
Please note that CRLs are signed objects and are validated by the
user. > Also, I don't have to ask the CA for certificates, they are
signed > objects. They can be supplied to me from anyone, including the
originator > and I can validate them at my leisure with no direct
interaction with > the originator's CA at all !
Steve just indicated that, for non-repudiation, the CRL's must be
obtained after the receipt of the message. Doesn't the above statement
violate non- repudiation? I seems to me that I must have "direct
interaction" not only with the originator's CA, but EVERY CA, PCA, etc.
throughout the entire hierarchy after the receipt of every single
message for which non-repudiation is desired.
A careful reading of Steve's message shows that he makes the distinction
between users willing to accept the current CRL for message origin
authentication v. providing a non-repudiation service which does require
the next CRL. The "above statement" is discussing not the service applied
to the message but the mechanism establishing validity of the certificate.
In any event, it makes no reference to whether the CRL being evaluated is
current or next and does not state the service being established.
The last sentence is partially true; you must have the "next" CRL of
each CA in the hierarchy to support non-repudiation. However, it does not
follow that obtaining the "next" CRL need be onerous, time consuming, or
require direct interaction. I could easily imagine a local directory (small d)
which is periodically updated by daemon software which obtains the current CA
certificates and CRLs for the "1000 most active hierarchies". This could be
a site wide cache. It would seem that there is ample room for creative
solutions to solve this need.
(As an aside, I think the term user should be avoided in favor of
originator or recipient.)
Please note that often the terms "originator" and "recipient" are too
specific. The requirement to validate certificates falls on both.
Perhaps we could use Originator/Recipient ? (X.400 joke :-) )
Tom Jones - ViaCrypt div. of Lemcom Sys
John Lowry