RE: CMC Comments?

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

> From: Brian LaMacchia <bal@microsoft.com>
> To: "'Luke Koops'" <luke.koops@entrust.com>
> Date: Wed, 23 Dec 1998 14:58:39 -0800
> 
> 	Is there a need to lower the bar for PKIX compliance to this level?
> 
> Obviously, the long-term goal is to use Full PKI Request and Response
> messages throughout.  However, CMC also has a goal of supporting
> industry-standard PKCS#10/7 as a subset of the protocol, so that current
> clients and servers can also participate in the CMC world.


This conformance proposal sounds more like pork-barrel politics than
standardization.

We have two alternative mechanisms for accomplishing the same purpose -
one which has been in use for some time and covers 80% (or 90%, not
to quibble over numbers) of the application space, the other has
been designed to cover 99% of the application space but is less widely
implemented.  The Full Request and Response messages were created by
and agreed to by proponents of both PKCS#10 and PKIX Part 3, and they
accommodate the needs of all interested parties.

I would make an analogy to the modem world, where two functionally
similar protocols were candidates for standardization.  X2 and Flex
both provide 56K connections, but are not interoperable.  International
Standard V.90 also provides a 56K connection, but is not interoperable
with either of the earlier protocols.  Modem vendors and ISP equipment
vendors are free to include 1, 2, or all 3 of the protocols in their
equipment, as dictated by cost and market considerations.  However,
the V.90 standard DOES NOT require support for either X2 or Flex as
a condition of conformance.

That is real Standardization.  There was big money at stake, but the
competing participants still managed to agree on a single standard.

One can accept that the differences between email protocols are so
significant that the IETF is justified in standardizing two of them,
in two different working groups.  However, it is difficult to
believe that the differences between PKCS#10 and CRMF are so great
that the IETF should mandate support for both of them.
Reasonable people can disagree over whether the single IETF standard
should be the 80% or the 99% version.  But saying "each has its place,
so let's make them both MUSTs for servers" is a cop out.


> The basic idea is as follows (perhaps we should add a Conformance section to
> the draft to explicitly call this out):
> 
> A minimally-compliant CMC server:
> a) MUST accept a Full PKI Request message
> 	i) MUST accept CRMF Request Bodies within a Full PKI Request
> 	ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request
> b) MUST accept a Simple Enrollment Request message
> c) MUST be able to return a Full PKI Response.  (A Full PKI Response is
> always a valid response, but for interoperability with downlevel clients a
> compliant server SHOULD use the Simple Enrollment Response whenever
> possible.)
> 
> A minimally-complaint CMC client:
> a) MAY use either the Simple Enrollment Message or the Full PKI Request.
> 	i) clients MUST use PKCS#10 with the Simple Enrollment Message
> 	ii) clients MAY use either PKCS#10 or CRMF with the Full PKI Request
> b) MUST understand the Simple Enrollment Response.
> c) MUST understand the Full PKI Response.


That would be a fine proposal (with the MUSTs changed to lower-case
shoulds) if CMC were an Informational RFC intended to facilitate
interoperability between PKIX and PKCS#10 implementations.

But if CMC is intended to be a Standards Track RFC, it should say
simply:

   A minimally-compliant CMC server
     a) MUST accept a Full PKI Request message with a CRMF Request Body
     b) MUST be able to return a Full PKI Response

   A minimally-compliant CMC client:
     a) MUST generate a Full PKI Request with a CRMF Request Body
     b) MUST understand the Full PKI Response
     
   Compliant CMC servers and clients MAY (or SHOULD) support the following
   additional messages ...


Current [PKCS#10-based] clients and servers will be able to
participate in this CMC world as long as vendors find it useful to
support two standards in their products.