RE: New CMC Draft available

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

Hi Jim,

> ----------
> From: 	Jim Schaad (Exchange)[SMTP:jimsch@EXCHANGE.MICROSOFT.com]
> Sent: 	Monday, April 12, 1999 12:47 AM
> To: 	'Carlisle Adams'; IETF-PKIX (E-mail)
> Subject: 	RE: New CMC Draft available
> 
> 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
 
No problem.  Thanks for getting back to me, and I hope you're feeling
better.

> > -----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.
 
Backward compatibility with a large installed base may partly justify the
use of the word "need" here.  However, it has already been admitted that the
installed base is not immediately compliant with this protocol.  Can you
suggest one good reason why there is a "need" for such an interface rather
than a "desire"?  If not, please replace the word.

> > 
> > 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.
 
You say "There are no limits in the model that prevent this", but the
operational model of CMC is that this initial request gets enveloped in a
SignedData construct.  How does an entity without a signature key pair sign
this request for an encryption certificate?

> > 
> > 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.
 
With respect to your first reason, I have to wonder how many people are
using a code base identical to the one that you are using (and so whether
this is really a strong enough reason to use the hash).  As for your second
reason, it seems to me that detection and handling of transmission errors
should really have nothing whatsoever to do with this protocol (there's no
reason to mix the functionality of different layers here), and so perhaps
this is not a strong enough reason to use the hash either.

Unless there are other, better, reasons for causing implementers to do the
extra hash computation, I suggest removing it.

> > 
> > 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.
 
The section discusses POP for encryption-only keys.  How, exactly, can PKCS
#10 handle a request for an encryption-only key pair, even if it is included
as part of a full enrollment request (i.e., what goes in the "signature"
field of the PKCS #10)?

> > 
> > 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.
 
I assume what you mean by this is that the request is included by reference
*in the decryptedPOP structure*, but is included by value elsewhere in this
message.  Otherwise, the server still needs to keep state information.

 
(...key recovery stuff...)

> 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.
 
Sorry I was not able to attend the last IETF meeting due to other travel
commitments.  What was the justification for this decision?  Given that
these functions are very important for some environments, is there a good
reason to delay their inclusion in this document?  What time frame do you
envision for this separate draft?  Just curious.

I suppose it is fortuitous that this functionality is addressed in RFC 2510
for those that need it now.

> > 
> > 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.
 
You're right; I missed this.  Sorry.

> > 
> > 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.
 
It is customary to mandate one mechanism (and allow others) for
interoperability purposes, precisely when there are a number of ways that
something can be done.  There should be little reason for hesitancy with
respect to at least specifying a mechanism; such functionality was included
in RFC 2510 and received no objection whatever.

> > - 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.  
 
It seems much cleaner and simpler to me to be able to reject a certificate
before it is publicly issued than to have to go through the hassle of
issuing it and then revoking it (especially given the fact that revocation
status is still not universally checked by browsers and other
"certificate-aware" software).  I thought this might have been an important
consideration.

> > 
> > - 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.
 
Trust anchor roll-over is certainly an important problem, and I agree that
in some ways it is a separate issue.

However, CA key roll-over is not simply a matter of issuing a new
certificate and referencing it correctly.  The sort of procedure described
in RFC 2510 (OldWithNew, NewWithOld, etc.) is necessary so that certificate
paths can be constructed automatically in all circumstances (i.e., cert is
signed with new CA key but verifier has a cross-certificate for old CA key,
etc.).  This is not exclusively a trust anchor issue because it pertains to
CAs in the middle of the path as well.



Thanks again for your responses to my earlier comments!  I appreciate your
efforts to take my concerns into consideration...

Carlisle.