Re: FW: PKCS#7 in PKIX-3

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

From: Peter Williams <peter@verisign.com>
>
> Carlise,
>
> Much of the analysis here seem highly prescriptive (you seem to have
> decided you dont like the proposal, then constructed an argument
> against it), whereas what we need is internet PKI components with
> feature flexibility in order to satisfy the actual market demand for
> multi-vendor PKI product/service interworking, and the buildup of a
> unified infrastructure involving many parties.

It is not possible for an external observer to know which of the
following thought processes were used:

 1) consider the problem as deeply as possible, and formulate a
    proposal which best addresses the issues as understood by the
    author, or

 2) arbitrarily pick a position, and then come up with a set of
    rationalizations to support that position. This latter technique
    is used in debate training, where participants are told what
    positions to defend, and are judged on the quality of their
    defense. It is also used in the U.S. legal system, where lawyers
    are obligated to represent their client's interests without
    regard for their own personal opinion of the merits.

But regardless of whether Carlisle is at heart an engineer or a
lawyer, the arguments he presents are concrete, in writing. They
can be considered by all observers, and they will succeed or fail
based on their technical merit, assuming that this audience (the
IETF) is interested in good engineering.



From: Peter Williams <peter@verisign.com>
>
> Tim,
>
> You seem, say I, to attack my style of writing and argument, rather
> than the issues I raise.

To this observer, the ad-hominem attacks have come from neither
Carlisle nor Tim.  Let's hope that in the future all participants
will confine themselves to the issues, to wit:


 1) PKIX-3 will be used to establish credentials where none currently
    exist, therefore it must include its own protection mechanism which
    is mandatory to implement.  It may also optionally rely on external
    protection mechanisms, but that is beside the point.

 2) The purpose of all standards, including this one, is to reduce
    the degrees of freedom available to developers and consumers. PKIX-3
    must be capable of addressing today's requirements and flexible enough
    to accommodate what we currently understand of future requirements,
    but should not define or require more than the necessary and sufficient
    capability.

I recently re-read RFC 2026, "The Internet Standards Process". It
makes a useful and enlightening distinction between Applicability
Statements (AS) and Technical Standards (TS).  A TS defines a particular
protocol. An AS applies to a particular environment/application area, and
specifies one or more TSs to be used in that environment, along with
the requirement level (mandatory, recommended, optional) for each TS.

PKIX-3 is a TS.  If it is useful to specify the applicability of
{PKCS-7, S/MIME, PKCS-10, PGP, PEM, MOSS, MSP, MMP, SSL, IPSEC,
ActiveX, Java, ...} to the Certificate Management environment, the
proper way to do so is to write an AS, not re-write PKIX-3 to include
any or all other protocols/message formats that might be involved in a
Certificate Management system.

To me, the logic behind Carlisle's and Tim's positions on the above
two issues appears both sound and technically motivated. And, for the
record, I agree with those positions.

But the purpose of this working group is to achieve (at a minimum)
rough consensus. Let's attempt to arrive at that consensus as
harmoniously as possible, without over-analyzing the motivations
of the participants.