RE: Comments on

["Arsenault, Al W." <awarsen@xxxxxxxxxxxxxx>]

Responding to Charles Moore, Carlisle Adams wrote:

>Hi Charles,

<large snip>

>>ADD to 3.1.2 PKI Message Body
>>Add an additional  branch be added to the CHOICE.  The
>>additional branch would be:
>>
>>   other [48] SEQUENCE {
>>             oid  OBJECT IDENTIFIER,
>>             value     ANY DEFINED BY oid  }
>>
>>The tag number does not concern me.
>>
>>RATIONAL: Missed in update

>I didn't mean to overlay too much semantic intent on my choice of the
>name "GenReq" in this submission; I simply meant "request" to represent
>any unsolicited message going out from an entity ("response", on the
>other hand, was a solicited message, a reply to a message that was
>received).

>In any case, I can see why this might not be clear, so I'm willing to
>add another branch to CHOICE.  Can I make it perfectly general and
>specify it as a SET OF {OID,value} pairs (as was added to PKIHeader)?

For what it's worth, I agree with the suggestions from Charles and Russ.
I'm in the process of trying to plan a migration of my hierarchy  from an 
existing "custom" certificate management protocol to PKIX-CMP.  My current 
protocol has (and my users will continue to need) a variety of messages 
dealing with things like firmware updates for hardware tokens, special 
"lists" of compromised keys, etc.  These are almost certainly of no interest 
to most PKIX-CMP users.  However, from my somewhat selfish viewpoint, it's a 
heck of a lot easier to implement PKIX-CMP, plus a few locally-defined 
"other" message, than it is to implement PKIX-CMP, and then add an extra 
protocol to do the rest of the stuff.  I believe that the format that 
Charles and Russ suggested is the best/easiest/clearest way to do this.

Re:  SET OF {OID, value} pairs:  I don't care about this.  I'm going to 
implement as "one PKIX-CMP-extended message at a time".  If you want to have 
the ability to send "multiple locally-defined messages at a single time", 
fine.  I don't see any need for it, but others might.

>By the way, one comment from your posting yesterday.  You said "The
>requested extension had the ability to define the symantics of the
>operation, such as a distribution message that was not a request or
>response."  Note that PKIX-CMP is inherently a point-to-point protocol
>for the explicit purpose of doing certificate management functions; I
>don't think that distribution messages fit within this framework.

This may be a matter of semantics, but we'll see.  I believe that there is a 
need for a CA, RA, other entity to send out "unsolicited response" messages. 
 That is, a CA may want to send a CRLannounce message to users, even though 
users have not asked for them, because local policy dictates that you push a 
new CRL out whenever a key has been determined to be compromised.  If one 
regards such messages to be "response" messages, then the current PKIX-CMP 
is acceptable.  If one regards such a message to be a "distribution message 
that was not a request or response", then that concept needs to be 
supported.

>>REPLACE
>>CertificateValidityDate ::= CHOICE {
>>      utcTime        UTCTime,
>>      generalTime    GeneralizedTime
>>  }
>>
>>WITH
>>CertificateValidityDate ::= GeneralizedTime
>>
>>RATIONAL: There is no need to support the legacy UTCTime in the request.

>This is only used in the certificate template and it's only there
>because that's the way certificates are currently specified.  In other
>words, it was specified that way so that the template could be
>constructed to look exactly like the requester wanted the certificate to
>look.

>I believe someone on the list requested this.

If nobody has previously requested this, I'll make such a request now.   I 
want to support the operational scenario where a new user creates his own 
to-be-signed-certificate, in the exact format (to include the user-generated 
public key :-) that the user desires the end product to look like - the only 
thing missing would be the CA's signature.  The CA will then examine the 
certificate, determine that it is acceptable, sign it, and send it back.  If 
the CA has to do a time-format change, that's an unnecessary burden that 
just slows down processing.


                    Al Arsenault

     - speaking only for myself.