--- Begin Message ---
Colleagues - I have just reviewed two contributions to the PKIX list
from Russ Housley and Peter Williams. Russ's is a model of clarity and
succinctness which needs no further explanation from me. I believe that
at the kernel of Peter's contribution are two main points:
1. Where PKIX-3 exchanges require the presence of a secure channel
(authentic and/or confidential) it should assume that the required
secure mechanism is available; provided by some other (unspecified)
means.
2. PKCS#7 is a suitable secure mechanism under some circumstances.
Taking the first point; at first glance it seems persuasive: why invent
something new when the community has already devoted a great deal of
effort to the development of sound and efficient secure communication
mechanisms that should be suitable for the present purpose? But
questions remain: should we allow ANY suitable mechanism, or should we
select just one of the available standard mechanisms (PKCS#7 perhaps)?
Peter seems to propose the former approach and Russ seems to lean
towards the latter, provided that PKCS#7 is amended in the new draft to
address the deficiencies identified by Carlisle in his recent analysis.
As Carlisle has pointed out, PKIX-3 must be capable of breaking the
vicious circle in which a secure mechanism must be available in order
that PKIX-3 can be used to establish a secure mechanism. Therefore,
PKIX-3 must include a secure mechanism in its mandatory subset. If
implementors wish to use a current or future version of PKCS#7 they may
do so, in accordance with the optional subset of the PKIX-3 provisions.
I believe the vendor and user communities expect the number of degrees
of freedom in the solution space to be significantly reduced by
standards like PKIX-3. PKIX-3 should be a code-word in the user's mind
for "a future-resistant protocol suite that addresses all my concerns
related to the management of public key infrastructure services in a
sound, efficient and a multi-vendor interoperable manner". If we
achieve this, then the issue will be removed from the table, and we can
all go on to solve the next big problem. If we allow the mechanism to
be chosen by the implementor, then interoperability will be threatened,
and the user will have to assess the suitability of the underlying
secure communication mechanism for management of the public key
certificates in his/her particular application. For example, Peter
suggests DCE as a mechanism which may be suitable under some
circumstances, but DCE was developed to satisfy the requirements of user
authentication in a distributed computing environment. It may,
therefore, be quite unsuitable for satisfying the requirements of
non-repudiation for high-value business transactions.
Russ's proposal is more attractive. And, because of the succinct, clear
and unemotional way in which it is presented, it is much more likely to
receive a sympathetic review by its readers. My one concern is for
time-scale. It is undesirable, or perhaps unacceptable, to delay the
progression of PKIX-3 in anticipation of a revision to PKCS#7 which may
or may not solve the problems that are not solved by the current
version. Before we can consider this solution, I think we need a
credible commitment by the PKCS editor, that the new version of PKCS#7
will be stable by the end of February 1997. This commitment must be
provided by the end of the first week in January 1997. However, this
time-scale seems unrealistic.
Best regards. Tim.
--- End Message ---