Subject: RE: CMC issues

From: "David P. Kemp" <[email-masked]>
Date: Fri, 8 Sep 2000 12:54:55 -0400 (EDT)

> From: "Jim Schaad" <[email-masked]>
> 
> - It seems to me that the single round trip preference mentioned in 
> section 1 cannot come along with the industry practice of PKCS#10/PKCS#7
> 
> (mentioned in the same section). Proof of Identity may be supplied in 
> the full enrollment message (thus not using the PKCS#10 request) or 
> pending token must be returned (and having more then single round trip).
> 
> 
> <JLS>  Using the current PKCS#10/PKCS#7 resonse, there is no simple way 
> to do any proof of identity in a single round trip.  Note that you 
> cannot even return a pending token here so there is no standard way to 
> do a multiple trip proof. The Proof-of-Identity is normally done in some
> 
> external non-standard way (either entering the proof on the web 
> enrollment page or an external e-mail message are normal ways today) or 
> not at all under current industry practice.

So will CMC recommend that Proof-of-Identity be done in a non-standard
way or not at all, or will it recommend using the standard (full) way
of doing it?

CRMF was designed expressly to address the limitations of PKCS#10;
free-form web interfaces are fine for some purposes, but for others a
well-defined transaction interface with explicit data structures is
preferred.  The problem statement is "how can a client from one
vendor request a cert from a CA based on a different vendor's
product?".  I don't think suggesting that Checkpoint follow current
(non-standard) industry practice helps solve that problem.  If "the
normal ways today" are good enough, why bother writing CMC at all?

  Dave