Dave:
What you are asking for is exactly what many of us had been trying to
achieve for a long time. We had the plan, well over a year ago, that PKIX
Part 3 should be a 2-layered protocol - a set of messages at the top layer,
and a security enveloping mechanism, which could be either PKCS#7 or an
alternative mechanism favored by Entrust, at the lower layer.
Unfortunately this was not achieved, and our extensive efforts to achieve
this at Munich proved fruitless. The problem is that the current CMP
specification simply does not reflect layer independence. The messages
described in Section 3, in particular several of the PKIHeader components,
are inherently tied to the Entrust protection mechanism.
At Munich, we asked the PKIX CMP editor if he could rearrange the
specification to make the separation of these two layers pure, but he found
this unacceptable.
I see no point in reopening this issue again now. Why would the outcome be
any different? I see no alternative to letting the CMP protocol be
published as is, meanwhile the PKCS#7-based protocol will be developed as a
fully-independent specification. The PKCS protocol should, of course, try
to reuse components of the CMP message formats where possible; in fact, I
am still hopeful we can meaningfully consider CRS to be an "interpretation"
of CMP. However, it would be unreasonable to encumber the PKCS design with
unwanted baggage.
Regards,
Warwick
At 12:37 PM 12/5/97 -0500, David P. Kemp wrote:
>
>Mike,
> With respect, I've admitted to you and others privately that I find
>the *document describing* CMP which is now in Last Call to be overly
>complex. But I fail to understand why you refuse to make your proposal
>compatible with the CMP protocol itself, which in it's minimal form,
>is not that complex.
>
>
>> There is a serious disconnect here which no amount of artful optional
>> syntax will repair and we might as well admit it.
>
>There is a disconnect in someone's understanding, perhaps mine. But
>IMHO the "artful optional syntax" is not an attempt to repair anything,
>it is the fundamental design principle which enables one to start small
>and add on later. Stripped of everything optional, CMP can be
>described in just a few lines:
>
>
> PKIMessage ::= SEQUENCE {
> header PKIHeader,
> body PKIBody }
>
> PKIHeader ::= SEQUENCE {
> pvno INTEGER,
> sender GeneralName,
> recipient GeneralName }
>
> PKIBody ::= SEQUENCE {
> p10cr [4] CertificationRequest } -- PKCS#10 certification
request*
>
>
>Are you claiming that adding one integer, two names, and a couple of
>nested SEQUENCEs to PKCS #10 is so much of a burden that S/MIME
>developers, toolkit vendors, and CAs will be unable to accomplish it
>within the next release cycle?
>
>As Blake said, if there is something wrong with this tiny bit of
>required CMP syntax, then suggest that it be fixed. Otherwise, just
>get about the business of writing your draft describing a minimal cert
>request syntax in a manner that is compatible with CMP, instead of
>insisting on a non-extensible alternative with no future growth path.
>
>
>> The issues and forces are readily apparent. If x% of the PKI-using
>> community does something other than CMP for their own internal reasons,
>> then at some value of x we must perform a reality check. I would claim the
>> current value of x far exceeds this threshold.
>
>Reality check: 100% of browser vendors do not support TLS in their
>current products. Yet I don't see that being used as an argument claiming
>that the IETF must write a Standards Track protocol that enshrines
>SSL v3.0 as a permanent parallel alternative to TLS 1.0. One Standard
>is enough - implementations are always free to support as many additional
>non-standard or de-facto standard options as business needs dictate.
>
>
>-------------
>* as an aside, I'll express my opinion that using the CMP "cr" message
> and eliminating the redundant "p10cr" message would also not be a
> major burden for developers, and would have the benefit of simplifying
> the codebase. But in the spirit of compromise, I won't
> argue for that here.
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------