Reading PEM RFC1114 (E) brought a number of questions and suggestions
(staying within the PEM framework) to mind. My contribution to your
document is however only limited to suggesting that the solution is
also specified, or else such (seemingly reasonable) questions footnoted
as negated due to their false assumptions X, Y, Z.
My only other contribution is to state my general impresssion that
having read the document, I am left feeling some positive justification
of the secureness of the scheme is required. "Why should I believe it
works?", asks the layman. Perhaps it is necessary to state or reference
the design certification procedures, formal proofs, you are using, etc.
Referencing X.509 is surely not enough.
Peter Williams.
-------------
PEM RFC1114e specifies a mechanism whereby the uniqueness of DNs of
PCAs, CAs and Users can be denied by requesting the service of a
(presumably) centralized data server. Without such a guarantee, and
some (unspecified) trusted method whereby PCA Human administrators can
resolve any identified conflict, the protection services of
authentication and non-repudiation of PEM fall apart.
The database query protocol of Appendix B wasn't available to me.
Presumably its security policy requires that it uses peer-entity strong
authentication procedures of strength greater or equal to that offered
by PEM data authentication services - given the risks associated with
erroneous certification of naming uniqueness. Otherwise PEM fails due
to the threat of masquerade of the database server, and consequent
compromise of the name certification procedures.
Is a non-replicated, centralized minimal name service really suitable
given the query load for the user class to be realistically expected?
Or are PEM services limited to pilot status (being but temporarily
supported by the minimal name-server) pending widespread adoption of
strongly-authenticating and fully interworking Directory technologies
throughout the Internet?
Futhermore, how are the strong credentials securely created for the
database client? Who signs them? What guarantee do I have of the
uniqueness of the CA name?...
Providing users are willing to accept the risks, a solution is possible
by removing the requirement of using strong authentication of the
database query protocol. 2-way simple password authentication might
then be used. An R&D user community would be willing to accept this,
I venture.