RE: New CMC Draft available

["Jim Schaad (Exchange)" <jimsch@xxxxxxxxxxxxxxxxxxxxxx>]

Carlisle,

Sorry about taking so long on replying to this, but the few times that I get
sick I really do a good job of getting sick.  Comments are inline

> -----Original Message-----
> From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
> Sent: Monday, March 15, 1999 3:42 PM
> To: IETF-PKIX (E-mail)
> Subject: RE: New CMC Draft available
> 
> Abstract:  there is not a *need* for an interface to PK certification
> products and services based on [CMS] and [PKCS10]; there is a 
> *desire* for
> such an interface.  Nothing *needs* to be based on CMS and PKCS10
> (especially since, as noted in the conformance section, 
> existing deployed
> software is not immediately compliant with this 
> specification).  However,
> there is great *desire* to base the protocols on CMS and 
> PKCS10, since these
> are familiar.  Please change "need" in bullet 1 to "desire" 
> (and change
> "immediate needs" in the opening sentence to "immediate concerns", or
> similar).

I don't really know what to say on this point.  One person's desires are
another person's needs.

> 
> Section 2, Section 2.1, and elsewhere:  the document sometimes uses
> "certificate authority", sometimes uses "certification 
> authority", sometimes
> uses "Certification Authority", and so on.  Please be 
> consistent throughout.
> [Note that "Certification Authority" is the official term in various
> Standards.]

Done
--- Brian -- we need to decide on certificate request or certification
request and use this consistantly as well.

> 
> Section 2:  this may be obvious to many, but I think that stating the
> following underlying operational assumption will help to clarify the
> operational model for this protocol.  "Underlying assumption: 
>  every PKI
> entity will have a signing key pair and will request a verification
> certificate in its initialization message (i.e., an entity 
> will never ask
> for an encryption certificate _only_ in its initialization 
> message)."  [The
> reason that it might help to clarify this is that RFC 2510 
> does not have
> this restriction.]

I am not sure that I agree with this statment.  I believe that it is
possible in this model to obtain just an encryption certificate.  There are
no limits in the model that prevent this.  The one-time shared secret can be
used to identify the end user to the CA, and the request could just be for
an encryption certificate.  There would be no way to renew such a situation
as no proof of identity could easily be offered with just an encryption
certificate, but the initial request could easily be made.

> 
> Section 3.3.3.1:  "D-H private keys cannot always be used..." 
> -- note that
> is may also be true for RSA keys that are held in a 
> decrypt-only device, so
> you need not restrict this section to D-H.

You are quite correct, and we will modify the text to address this problem.

> 
> Also, "NoSignatureValue contains the hash of the 
> certification request." --
> why force the implementer to do an extra hash here for no 
> purpose?  Why not
> say that NoSignatureValue "contains the value 1234", or similar?

This could easily be a constant value, I put the hash in for two reasons.
First, the code base that I was using computed the hash anyway so there were
no reasons not to use it.  Second, by including the hash the most obious of
transmissions errors could potentially be found.  Unless there are other who
support using a constant value, I do not plan to change this.

> 
> Section 5.2 (second paragraph):  "Servers SHOULD provide this 
> method or have
> a bilateral method..." -- I would prefer the following for 
> interoperability
> reasons:  "Servers MUST provide this method and MAY also have 
> a bilateral
> method...".

We have made this change.

> 
> Section 5.7:  should note in first paragraph that PKCS10 
> cannot be used to
> provide this functionality.

This is not correct.  The correct statement, which I will pass by the other
authors, is that simple enrollment messages cannot provide this
functionality.  There is no reason that a PKCS10 included as part of a full
enrollment request cannot provide the functionality needed.

> 
> Also, it appears (from the text in bullet 4a and the text in 
> the second-last
> sentence of the section) that the DecryptedPOP structure 
> should contain
> "request    TaggedRequest" rather than "bodyPartID    
> BodyPartID".  That is,
> the decrypted POP needs to contain the actual request itself 
> (not just an
> ID).

I have changed the language on this slightly.  What is placed here is the
body part id of the request.  The request is included by reference and the
text now states this.

> 
> Section 5.9 (last paragraph):  "the server responds with a 
> Key Recovery
> Response containing the newly generated key." -- it doesn't 
> really make any
> sense semantically to use a key recovery response to 
> implement off-client
> key generation (since off-client key generation is not key 
> recovery).  Why
> not simply define a new message ("OffClientKeyGenRep") with 
> the same syntax
> as Key Recovery Response?

> 
> Also, "The details of the request control statement not 
> covered in this
> document...".  This will limit the use of this protocol in 
> some environments
> (those that mandate central key gen.).  A request message needs to be
> defined for this purpose.
> 
> Section 5.9.3:  "The ContentInfo contains the requested private key
> material." -- does it also contain the newly-created 
> recipient (i.e., EE)
> certificate?  If not, how can this response be used for off-client key
> generation?  [Note that according to CMS, it is not clear 
> that it's legal
> for a CA to put the EE certificate in this construct....]
> 
> Sections 5.9.4.1, 5.9.4.2, 5.9.4.3:  in each section you need 
> to say that
> the private key (DH-PrivateKey, DSA-PrivateKey, or RSAPrivateKey) must
> subsequently be re-encoded as an OCTET STRING (in order to 
> fit within the
> structure defined in Section 5.9.4).

We will look at the comments on this section for a new draft.  As I anounced
at the IETF meeting we are pulling out all of the archiving text and placing
it into a seperate draft.  That draft will address both the archiving and
server side key generation issues.

> 
> Section 5.10:  "low-end IP router that does not retain its 
> own certificate
> in non-volatile memory".  I might prefer "low-end IP router 
> that does not
> retain in non-volatile memory the certificates of those 
> entities with whom
> it needs to communicate".  Entities certainly need to get the 
> certificates
> of others in order to talk with them; do they really need to 
> keep their own
> certificates for most of their activities?

The original text on this issue is actually correct.  THe problem is that
router does not keep its own certificate during events such as power cycles.
After obtaining its own certificate from some type of directory service,
that certificate is presented as part of protocal to talk to the next
router.  Thus each router needs to get it's own certificate from a
centeralized location, but gets the other router's certificate from the
other router.

> 
> Section 5.11:  "The fields in a GetCRL have the following 
> meanings:  --
> issuerName is the value of the Issuer DN in the subject 
> certificate."  This
> will not work for Indirect CRLs.  Perhaps this field should 
> hold the name of
> the CRL issuer instead...

done

> 
> Section 5.12:  "it is impossible to produce a reliable 
> digital signature."
> -- this should be clarified to "it is impossible to produce a reliable
> digital signature (prior to the certification of a new 
> signature key pair)."

We have a couple of different suggestions for cleaning up this wording and
we will do so.

> 
> Section 5.14:  "The query pending attribute allows for a 
> client to query a
> server about the state..." -- how does the client know when 
> to do this?  Is
> there a time-to-check-back value included somewhere in the server's
> response?

This value is in the CMCStatusInfo structure.  We will include a text
reference here to that fact.

> 
> Section 6.1:  "The request is placed in the cmsSequence if it 
> is a full pki
> message and the reqSequence field for a simple enrollment 
> message." -- in
> the latter case, is this still a nested message?  (I.e., what is the
> difference between a "non-nested" message with a PKCS10 in 
> the reqSequence
> and a "nested" message with a simple enrollment message in 
> the reqSequence?)

There are a couple of different opinions on this amoung the author's.  We
will argue this out and put in clarification text on this issue

> 
> Sections 7.2, 7.3:  replace "BER" with "DER" since signatures are
> involved...

What is being referenced here is a CMS SignedData object (since we are
looking at full requests).  CMS explicity states these may be BER encoded
objects.

> 
> Section 12:  update the CRMF reference to RFC 2511 and the PKIXCERT
> reference to RFC 2459.  Also, was DH-SIG not updated to some 
> other draft
> recently?

In progress.  

> 
> 
> Finally, there is some  functionality missing in this 
> specification that
> will be very important for some environments.
> 
> - there is currently no way for a CA/RA to provide a trust 
> anchor (public
> key or self-signed cert) to the client during initialization.
> 

Given the number of ways that this can be done, and the impliciations about
the fact that clients are going to start automatically accepting such
certificates as trust anchors, the author's are hesitant to include this
fucntionality.  Please place on the list as a seperate topic of discussion
to see how much support exists for this.

> - there is no confirmation message from the client to the 
> CA/RA (thus, there
> is no way for a client to reject a certificate that it does 
> not want (e.g.,
> in the case where the CA has modified some of the fields in 
> the request)).

There is a simple way for a client to reject a certificate, it simply puts
in a revocation request on the certificates it just received.  I don't know
of any reason for the oppositite to be required in a general protocal.  That
is the client must positively accept a certificate.  

> 
> - cross-certification is not described.  (It appears to be 
> possible to do
> this with the existing messages, but without a prescribed method
> interoperability is unlikely.)

I don't understand why you think that interopability is a problem.  If a CA
generates a certificate request then it can get a cross-certificate.  The
real problem of interopability here is far more in the question of the
procedures required to accept such a request not in the request itself.

> 
> - as mentioned above, off-client key generation needs to be 
> specified (both
> request and response).  It would also be nice to be able to 
> ask for this as
> part of the Full PKI Request message, rather than having to 
> use separate
> req/rep messages.

Will be addressed in a seperate draft.

> 
> - CA key rollover is not described.  (This might be considered to be
> out-of-scope of the current document, but it is very much 
> in-scope for a
> specification on how to do comprehensive certificate 
> management, which is
> what the title of this document suggests.)

There are really two different points that need to be addressed here and
they are seperate problems.  The problem of rolling over a CA key is not
really a big issue from what I can tell.  All you do is issue the new CA
certificate and start referencing it correctly using AIA and CDP extensions.
I think the problem you really want to address here is the question of trust
anchor roll-over.  Before we addressed this we would need to address the
question of doing trust anchor issues at all.

> 
> 
> 
> That's all.  Aside from a few other typos, etc., the document 
> looks great!
> 
> Carlisle.
> 

Jim Schaad