FW: PKCS#7 in PKIX-3

[Peter Williams <peter@xxxxxxxxxxxx>]

Tim,

You seem, say I, to attack my style of writing and argument, rather than
the issues I raise. This is becoming uniform and commonplace in certain US govt-related
circles, its my perception (conspiracy followup to alt.privacy, perhaps). But, lets
address technical issues, and consider how best the document should evolve
to represent an determinable concensus.

I find it bogus that one forces a given model of certification management object 
protection upon the free-wheeling Internet (with its mix
of interanet, internet, and extranet functional and physical distirbution modes), 
whilst arguing for a priori interworking  benefits, when
there can be no assumption that two parties, using a priori "unknown" implementations,
will use the same algorithms, or use the same profile of a given popular
algorithm as to key lengths, exponents etc. One cannot know they will support the same set of
attributes for naming, or they can handle given size of encodings. One cannot
know, given the document as-is that a given CA solution will support any one of the listed
operational protocols (I.3-4) or that all the service will be enforced/provided by a CA service of
product ( e.g. mandatory key escrow for all foreigners).  
 
I dont intend my contributions in this thread to be any different to the intent of
one from the I-D  "this document defines a profile to promote .. development
of   application tools; and interoperability determined by policy, as
opposed to syntax." ok, this applied to cert contents, but it goes
for management protocols also, it seems.

its policy freedom - at the protection layer - during the management
activity that Im calling for in the framework, and is the sentiment epxressed at the WG, I learned
from the minutes posted to the the list.

PKIX-1 goes on to say:

"Some communities will need to supplement, or possibly replace, this
 profile in order to meet the requirements of specialized application"

I suggest that supporting a certifcate management service is precisely just one such
specialised management application - by virtue of its inherent needs for adressing
local threats and objectives for control procedures Enrollment and management activities
of router-based certs, versus consumer certs, versus CA certs are
all turning out to have quite different dynamics, requirements and
needs for localization based on such practical matters as available
memory in a device. Furthermore, as some enviornments use short-life
certs (1 day, and even use-once) whereas others use long-life certs,
the protection requiremnets for rollover and reissuance are
not such that one can at this stage in the industry standardize
their requirements of services. It would be nice, however, if they could use
std syntaxes from PKIX for the information objects so promote
reuse of std modules and multi-vendor componentware which can be profesionally
built for integration into solution environments by third parties. At least this
should be denied!

PKIX-3 says "9. PKI management protocols must be usable over a variety of "transport" 
mechanisms, specifically including mail, http, TCP/IP and ftp." yet it
goes on to define specific peer-peer request-response layer protocol at a socket ports.
Is this mandatory? Is the document contradictory? If all the transports
are wholly equivalent, and non-specalised, they do no need standardizing
here, especially as support seem not to be mandatory and may well
conflict with corporate security policies for transport channels, firewall configurations,
and require duplicate management/configuration etc. If I do not implement
this optional socket protocol, will the Nortel and VerISign products not fail to interwork?!

It seems evident that general internet-wide system-level interoperability is thus
not sensibly mandated in PKIX scope; PKIX should  agree the nature of the information objects
and indiciate the flows system one should expect to participate it.

Its on account of the inherent nature of the problem of certifcation system's requiring
a high degree of environmental specialization that I comment thus. PKIX is not PEM - a
solution; PKIX seems limitied to being able to standardize componentware so solutions
can be constructed. At most it is a framework standard, and to to pretend
more is not realisitic. I suggest the framework be structured to separate
protection, and information objects, merely, and exploit layering encapsulation.

There is an emerging alternative perspective to the current PKIX-3 notion - that on each
hop of message flow between principals in the certification system, one can realistically
expect a *local* control system to be deployed to assure some property of the overall
system required by the prevailing security policy, which will need to be tuned to
both local threats and local requirements for control laid down
in said security policy document. Often this will satisfy commercial threats
of information disclosure as much as technical threats to system integrity.
 
It is highly likely that corporate users will base such management
control systems upon the existing features of corporate security policy - exploiting
reliance on *encapsulating" secure physical networks, networking level encryption, closed
user groups, global distributed system security, secure email networks - in which
they have invested heavily, and have developed the complementary
risk/personnel/audit management control systems which assure those technology
deployments, and their adequacy for use in a key management scenario.

On controlling a new procedures, such as an ORA's activity in
authentication management, we have found that those with
wel-managed, comemrcial-grade corporate security systems, e.g. Entrust-protected
email, sometimes wish to exploit that technology as part of the
control system for certificate management, rather than invent
anew. They have significant non-technical resources already
invested in that control systems apparatus, including specialization of such
as an Entrust email channel to the specific purpose of supporting
authentication management function of a certification system.

My observation that an *unbundled* protection envelope (which encapulates
std information objects, rather than protects inner types) be the basis
of the design is founded on such observation of the success of the
above approach in which componentware from multiple sources were
bunded by the customers without third-party invention, yet
all parties in a staticaly configured certification system could agree the
actual basis for technical interworking and system msg flow with minimal effort,
complete control over local security policy maintained in the hands
of the procurer, and selection from muliple sources of equivalent
product/toolkit/protction technology based on price, availability,
and other value-adds  etc.
 
The minutes from the meeting clearly epxressed that a sentiment
had been heard from the floor that a PKCS7-like relationship
should be addressed. I.e. some form of unbundling. I have deduced that the
underlying message was one of unbunding the protection mechanism from the information
types used to construct the certiifcation system, so reuse
of component and controls is a feature, not an after-thought. Its not clear
to me from the minutes whether the notion is to use a PKCS7
as one of the "algoirhtms" within the current msg format, else
use PKCS7 as one of the whole-msg encapsulation technologies
allowing for control of msg flow to thus be enforced by configuration of
std corporate infrastructure components (Entrust, S/MIME, Hannah.
IPSEC tunnels etc), versus reinventing control system enforcement
mechanism when performing the task of cert enrollment and management.

Before we discuss the pros and cons of a solution with PKCS7 syntax
or otherwise, perhaps we can address the design concept
of unbundling the mechanism ,and using encapulating technolgies
to ensure std control practices, and ensure concensus of concept. This
is after all a benefit of a well-managed I-D and RFC process.

It seems shame that a protocol of this importance should receive so
little comment, and thatm and a community polls which are volunteered to
the WG authors is so apparantly disparaged. Concensus
by default will likely lead to another MOSS scenario. What we
need is active concensus.

Peter.

----------
From: 	Tim Moses
Sent: 	Friday, December 20, 1996 7:46 AM
To: 	'ietf-pkix@tandem.com'
Subject: 	PKCS#7 in PKIX-3

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.