Dear Bob:
I am writing this letter to you and via pem-dev to all those
who recently produced an "avalanche" of new ideas and
suggestions, all directed towards the "reconstruction" of
RFC14xx, i.e. PEM. I am writing this letter as the PEM
developer and I am so glad that you suggested very cautious
approach to "PEM re-engineering". My motives are mainly
based on (a) several "about to be completely finished"
current implementations and (b) all the principles and
concepts which are built in the current RFC14xx system.
First, let me comment FROM OUR EXPERIENCE on usage of E-mail
addresses INSTEAD of DNs. E-mail addresses are in principle
the _elements of CONNECTIVITY_ and serious DNs are the
_elements of AUTHENTICITY_. The two should not be mixed.
Our version 1.0 of the COST-PEM is based on usage of E-mail
addresses, as such it runs smoothly through Internet, but
still it is note widely used ! This tells, at least to me,
that the BIG SHIFT from the current RFC14xx concept (DNs) to
E-mail based concept will not help very much for a broader
usage of PEM. The best solution is combined (of course,
user transparent) usage of E-mail addresses and DNs, but
this is essentially the matter of the PEM-UA implementation
and not RFC principles.
The same is the case with self-signed certificates: if the
PEM-UA, after generating a pair of RSA keys and creating the
self-signed certificate does not submit that certificate for
CA's signature, the certificate will be self-signed. As
such, it may be used for transactions with limited assurance
and also may be submitted later for signature to a local CA
(not in the hierarchy). Top-down (strict authentication, CA
hierarchy) or bottom-up (self signed cert's, direct trust
model) to me are not the matter of alternative systems and
principles, but the matter of practical implementations and
user policies. So, again, I feel that the current CA/Cert
model is very flexible and many aspects are the matter of UA
implementation.
I am also eager to see the concept of a nice and functional
CA architecture, based on RFC14xx principles. Since it has
to reflect certain decisions which belong to security
policies, I would like to ask you again to go through our
document describing all the security policies principles.
If you find them acceptable, I will send you (if
interested!) the next document, which outlines the CA
Architecture and its smooth functioning, based on the
described policy principles.
From my short experience in the field, my impression is that
the main "problem" with PEM is that it is SECURE E-MAIL
SYSTEM. So, we are getting replies to our initiatives like:
"We have no secrets in our E-mail letters". However, the
strength in PEM is in fact very powerful and
well-engineered CA/Certification system, which, together
with the smart cards, I like to call SECURITY INFRASTRUCTURE
(digital signature/Trusted Third Parties concept). This
leads us to aspects of using PEM for secure EDI and other
security enhanced applications, which you have also
suggested recently.
I believe that the most constructive suggestions eventually
to re-engineer PEM could come as answers to the following
questions:
1.) (If you are pure PEM user) Which PEM system are you
using NOW and what are your real problems and difficulties
with it ?
2.) (If you are PEM designer) What are your real problems
with RFC14xx implementations and why ?
3.) (If you are researcher or PEM-enthusiast) Which of the
Steve's Kent principles in "Goals Overview, Anyone" are not
acceptable, why, and then, what are the alternatives ?
I would like to remind you that some time ago we have
suggested direct certificate verification, pull-down model,
arbitrated CA signatures, and some other RFC14xx
improvements and alternatives, but Steve Kent (quite
correctly) observed something like: "Boy, you first make
RFC14xx PEM working, and THEN you do whatever you like".
Therefore, I am also in favour of establishing two PEM
groups (lines of action), but in the following way:
GROUP 1, which I would like to call "Current RFC14xx PEM"
which may consist of all those who would like by all means
to push the usage/development of current PEM concept, and
GROUP 2, which may start accumulating the principles,
solutions, improvements and alternatives, for some "next
generation PEM" system.
So, dear friends (PEM Community): P L E A S E :
a. don't change RFC14xx now, and
b. use PEM, whichever is available.
Regards,
Sead Muftic
!