RE: CMC Comments?

[Luke Koops <luke.koops@xxxxxxxxxxx>]

Thanks to Carlisle for responding to many of your comments.  I will attempt
to reply to the few remaining outstanding issues.  I have deleted the
sections of the original message to which I am not responding.  Hopefully
the result is readable and fair.

-Luke Koops
luke.koops@entrust.com


> ----------
> From: 	Brian LaMacchia[SMTP:bal@microsoft.com]
> Sent: 	Wednesday, December 23, 1998 5:58 PM
> To: 	'Luke Koops'
> Cc: 	ietf-pkix@imc.org; Barb Fox (Exchange)
> Subject: 	RE: CMC Comments? 
> 
> Luke--
> 
> 	1) It is not clear what a minimally compliant implementation MUST
> support.  It
> 	seems to be:
> 
[ ...MUNCH... ]

> 	In order to be compliant with the protocol, clients just need to
> continue
> 	operating as they already do.
> 
> No, they also need to understand the Full PKI Response message.  A current
> client (that only speaks PKCS#10/7) is not CMC-compliant because it does
> not
> support a standard mechanism for returning error information.
> 
> 	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.
<Luke>I would not ascribe goals to a standard per se, and I do not claim to
know what the goals of the authors are.

<Luke>It seems to me that this protocol will promote the status quo by
embodying it within a standard.

>   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.
<Luke>Current certificate clients could participate in the CMC world with
minimal modifications (support for full response).  A certificate server
could also participate in the CMC world with minimal modifications as well
(issue full response).  But, such a server would not be CMC compliant.  The
standard has many more MUST clauses for a compliant server than it does for
a compliant client.  Your statement illustrates the confusion that will
arise when vendors tout their product as "conforming with", "interoperating
with", "complying to", or "supporting" the PKIX-CMC protocol.  It seems
likely that servers will be written to support minimally compliant clients.

> 	PKIX-CMC needs to clearly state what MUST be supported by a
> minimally
> 	compliant implementation of the client and server.
> 
> Agreed; I will suggest text to the authors for a Conformance section
> (following the table at the top of this mail).
> 
> 	2) There is duplicate information in CRMF and CMC messages.  
[ ...MUNCH... ]
> This comment is similar to the one Carlisle raised.  The intent is that
> controls should appear in the CMC control section, and not in individual
> request bodies.
<Luke>If the intent is not specified in the standard, then other behaviour
should be anticipated and addressed by the standard.
>   Putting the controls in CMC allows individual controls to
> reference/apply to multiple request bodies.  It also puts all the
> processing
> information up front, which facilitates one-pass processing.
> 
> 	3) The regInfo and respInfo controls are 'too open'.  The result is
> that a CA
> 	or RA might not be able to interoperate with two different clients
> which use
> 	regInfo differently.  A bit pattern could be a valid message from
> both types
> 	of clients, but with different semantics.  It might not be possible
> to
> 	specify a parser which can handle both requests.
> 
> 	It would be much better if regInfo and respInfo were not octet
> strings, but
> 	were defined in the following manner.
> 
> 	  ExtraInfo ::= SEQUENCE {
> 	    infoType OBJECT IDENTIFIER,
> 	    info ANY DEFINED BY infoType }
> 
> (I assume you mean responseInfo, not respInfo...)
> 
> I don't see the need to extend the definition of regInfo or responseInfo
> into a SEQUENCE of OID/ANY as you suggest.  If client and server choose to
> define particular semantics for their specific information, and there's an
> OID tagging a structure with those semantics, then that information can be
> passed at top-level as just another CMC control attribute.  It is expected
> that clients and servers that choose to define additional information
> specific to their agreements will pass this information through additional
> control attributes; there's no reason to bury it down inside a
> regInfo/responseInfo/ExtraInfo structure.
> 
> (The regInfo and responseInfo controls themselves were defined for clients
> and servers that have agreed on the semantics of that OCTET STRING through
> some out-of-band mechanism.  For example, in a Web-based enrollment
> scenario
> the server could construct the regInfo using form field values & script.) 
<Luke>This creates the possibility that it would be impossible for a server
to interoperate with the clients from several vendors that use these
controls.  My original statement remains unanswered.

[ ...MUNCH... ]

> ======================================================================
> 	Other observations (collected from other readers here):
> 
[ ...MUNCH... ]

> 	   - it is not possible to securely send the CA root key in the
> response
> 	message.  This might be a serious limitation in some environments.
> 
> What do you mean by "securely send the CA root key"?  Please expand on
> this
> remark.
<Luke>During initialization, a one time password could be used for _mutual_
authentication of the client and the server.  Then the client could rely on
the server to advise it of trusted root keys which would be used for
verifying certificates.

<Luke>In some environments this might be a preferable way to seed the client
with trusted root keys.  Rather than have the software vendor decide which
root keys are trusted, the end user would choose the trust network(s) in
which she will participate.  After making this choice, the user gets an i.d.
and a one time password.  This is all that is required to bootstrap the
client into full participation.

> Hope this answers your questions,
> 
> 					--Brian LaMacchia
> 					  bal@microsoft.com
>