Dear Mr. Jueneman:
Your recent letter to PEM-DEV concerning CRL solutions in
current PEM RFCs was music for my ears and my heart. Just
to remind you: COST International Corporation has posted our
PCA PEM Policy in January 1993. It is available on-line and
I would suggest you to retrieve it and read it again, by
sending the E-mail letter to our COST-PEM PCA server:
To: cost-pem(_at_)cost(_dot_)dsv(_dot_)su(_dot_)se
Subject: PEM Policy Request
The policy definitely needs refinments (suggested by mr. R.
Shirey), what we will do soon, but one small section of it
DOES SAY:
" ... Contrary to the PEM RFCs specifications, the CRLs
WILL NOT BE DISTRIBUTED through the hierarchy. They will be
kept by CAs as the local CRL database. The CRLs will be
used TO REPLY TO USER REQUESTS for distribution or
verification of particular certificates.
The use of the CRLs will be based on various types of PEM
letters, those defined by the RFC 1424 document and some
ADDITIONAL LETTERS, needed to support all types of CRL
management functions. ... "
Based on that quote I was bitterly attacked by gentlemen
from the BBN who gave me "the lecture" that if we don't
implement CRLs exactly as described in RFCs, then
(a) our COST-PEM will not function properly,
will not be interoperable with other PEM
implementations, and
(b) we are not qualified for PEM discussions, since
we in fact didn't understand the essence of PEM !
That was all the reaction to my "mild" statement that in our
current COST-PEM version we didn't implement CRLs since "we
feel that they are not well worked out". In fact, I agree
with your opinion that "current CRL system is a snakepit of
problems masquerading as solutions" and "current system is a
bit clumsy" is really an understatement.
(I appologize to all of you reading this letter for all the
discussion above, but I just have to recover some of my
"burns" from various BBN flamethrowers).
And now let me turn to a more constructive discussion, to
some suggestions and to potential solutions for some of the
problems that you raised. As I said, I agree with
everything what you said about the requirements for CRLs,
user (sender and receiver) expectations and all the problems
in the current PEM version. But I don't agree with your
proposed solution: the DISTRIBUTION OF NONREVOCATION
STATEMENTS. With some simple analysis it is not difficult
to conclude not only that your solution of distributing
statements of nonrevocation is not feasible, but that indeed
causes all the problems and questions you asked yourself.
My proposal is exactly as quoted from our PCA policy:
" ... Contrary to the PEM RFCs specifications, the CRLs
WILL NOT BE DISTRIBUTED through the hierarchy. They will be
kept by CAs as the local CRL database. The CRLs will be
used TO REPLY TO USER REQUESTS for DISTRIBUTION or
VERIFICATION of particular certificates. ... "
How this in fact suppose to function, you may see in detail
from our COST-PEM Electronic Presentation (if you have
retrieved it). I appologize, but I think that your main
"mistake" is that you accepted the proposal of the RFCs that
CAs send and archive their CRLs to their PCAs. In current
RFCs solutions, PCAs are in fact the godfathers of the PEM
(and therefore CRL) system. In practice, we are sure, that
it won't be so.
We believe that THE MAIN SUBJECTS FOR CERTIFICATES AND CRL
MANAGEMENT WILL BE THOSE WHO ISSUE THEM AND WHO MAY BE
AFFECTED BY THEIR MISSUSE. These are presumably banks,
business companies, hospitals, etc., i.e. in the PEM
terminology: the lowest (or close to the bottom of the
hierarchy) CAs. You may call this "inverted" PEM model.
Let me give you one small example: COST runs PCA today. We
sell CA software to some Corporation, they establish their
top level CA, signed by us. After that, they establish many
companies' CAs, signed by the top level CA, and further
establish branch offices CAs, finally, say, Departmental
CAs, presumably to sign users' (human) certificates. The
lowest, human certificates will be issued to persons as
"Financial Director" and if his/her certificate (or private
component) is missused, THAT DEPARTMENT (AND NOBODY ELSE)
WILL HAVE SERIOUS CONSEQUENCES. So, what do we (as PCA far
"above" that Department) have to do with the responsibility
of their certificate management and how can we (by keeping
CRLs) guarantee to ALL their customers that each certificate
of that Department is still valid. (Nonsense !). (How can
Patent and Registration Office, who register new companies
in Sweden, be responsible for invalid order of Ericsson
Corporation, Radio Systems Company, Department for Loud
Speakers, mr. X, financial officer of that Department !)
So, when you as the receiver receive the signed PEM order
from someone (claiming the authority on behalf of some
Company-Department), you will "ask" immediately, before
accepting the order as valid, that Company's CA if the
sender's certificate is valid. For serious business
transactions you will probably do that for every order,
regardless whether you DO have the certificate of the sender
in your local database. When you want to send (a serious
business ENCRYPTED PEM transaction letter), you will also
retrive the certificate of that receiver, regardless of the
same certificate sitting in your local database.
In such a way, if user's certificate is revoked 12:00
o'clock and the remote request comes 12:01, the requester
will always receive the most current certificate. In case
that you want to verify today someones PEM letter created a
week ago, you will send to his/her CA the certificate CRL
request like: "Please send Mr. so-and-so certificate which
was valid on Sept 11th, at 12:05". In that case the CA may
need the local CRL.
This "distributed CRLs" solution, I believe, solves many of
your concerns: there will be thousands of small CRLs, each
with the CA responsible for its own certificates and CRLs,
so that
(a) network implications may not be so serious,
(b) If California slides, only 2% of PEM CRLs will dissapear,
(c) current PEM architecture is perfect, but CRLs
solutions and roles of PCAs are not,
(d) there are not so many eggs in several (PCA)
baskets.
In conclusion, I would like to emphasize that:
(a) our current implementation of COST-PEM stores CRLs
locally at CAs, but mechanisms (PEM letters) are not yet
available for their usage,
(b) the system may be slightly improved with CAs having
"agreement" with the most frequent customers to distribute
them immediately revoked certificate notifications,
(c) the system may be improved by creating "batches" of
received transactions and then requesting once the valid
certificate for the whole "batch",
(d) CA CRLs may be duplicated at higher level CAs
(for reliability, availability, denial of service, etc),
as is the case in our current implementation with
users' certificates,
(e) some improvements (modifications) in RFCs are needed,
(f) usage of smart cards may also improve our solutions.
I hope that the analysis of our existing PEM PCA policy and
suggested solutions in our COST-PEM Electronic Presentation
concerning "distributed CRL system" will bring us all to
some initial agreements, which we (as eager implementors)
would like to implement and test as soon as possible.
I am convinced that our future practical implementations and
cooperation with many of our current PEM customers and users
will prove the outlined suggestions feasible and efficient,
especially for serious business electronic transactions and
I hope that all eventual PEM-DEV comments will help us to
make these solutions even better.
I have applied with a paper to the Internet Conference (Feb
1994) and if accepted I will explain the details and
experiences with our PEM solutions and their applicability
for privacy E-mail and electronic business transactions.
Regards,
Sead Muftic Tel: +46-8-16 16 92
COST Computer Security Technologies Fax: +46-8-739-1839
Stockholm, Sweden E-mail:
sead(_at_)dsv(_dot_)su(_dot_)se
!
!