RE: Comments on

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

Hi Charles,

>----------
>From: 	Charles Moore[SMTP:cmoore@signet.org.au]
>Sent: 	Thursday, September 18, 1997 5:11 PM
>To: 	ietf-pkix@tandem.com
>Subject: 	Comments on 
>
>REPLACE:
>2.2.2 Mandatory schemes
>
>The criteria above allow for a large number of initial registration / 
>certification schemes. This specification mandates that conforming CA 
>equipment, RA equipment, and EE equipment must support the second 
>scheme listed below. Any entity may additionally support other schemes,
>if desired.
>
>WITH
>The criteria above allow for a number of initial registration / 
>certification schemes. This specification does not mandate a particular
>scheme, but describes two schemes in the following sections. Any entity
>may support these or other schemes, if desired.
>A future PKIX specification will support key generation protocol
>requirements.
>
>RATIONAL: Document agreements.

This is analogous to the discussions on algorithms heard so often in
various IETF Working Groups, and the reasoning here is identical.  There
must be at least one mandatory method otherwise you lose guaranteed
interoperability.  Just like every WG has had to pick a particular
algorithm and say "you can support a million algs if you want, but you
MUST support this one", I think we have to do the same with
initialization schemes.




>REPLACE
>2.2.2.1 Centralized scheme
>
>In terms of the classification above, this scheme is, in some ways, 
>the simplest possible, where:
>
>- initiation occurs at the certifying CA;
>- no on-line message authentication is required;
>- "key generation" occurs at the certifying CA (see Section 2.2.1.3);
>- no confirmation message is required.
>
>WITH
>2.2.2.1 Centralized scheme
>
>In this scheme:
>
>- initiation occurs at the CA or RA entity;
>- no on-line message authentication is required;
>- "key generation" occurs at the RA or CA entity;
>- no confirmation message is required.
>
>RATIONAL: Changes to align with stated requirements in previous sections
>to allow generation at the RA.

This scheme is chosen to represent the "simplest possible" scheme, where
only one PKIMessage is sent in the initialization process.  As soon as
you expand it to allow an RA, you break this and go back to at least 3
(possibly 4) messages.  Previous sections of course talk about key
generation at the RA (or elsewhere), but this particular scheme, like
the basic authenticate scheme, is one specific configuration out of all
the ones that could have been chosen.




>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)?

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.




>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.



--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------