RE: resolution

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

Hi,

>----------
>From: 	Peter Williams[SMTP:peter@verisign.com]
>Sent: 	Thursday, August 28, 1997 1:27 PM
>To: 	ietf-pkix@tandem.com
>Subject: 	resolution
>
>I have heard noone support centralised key generation as a mandatory option,
>except the author and David Kemp. David would allow sites to not-install
>this feature; this defeats the only disclosed purpose, however, of
>Carlisle's/Steven's
>rationale for requiring mandatory support - to engender universal service
>to any requesting user.

Peter, is it really that difficult for you to state something without
publicly attempting to tarnish someone's motives?  If you remove the
word "disclosed" from the above, I agree with you.




>I have heard at least 5 different, and I believe uncoordinated parties
>call for the downgrading of the capability to optional. The calls
>criticise both centralisation per se, and its mandatory imposition.

Agreed.




>I have  heard a competent and supported position lead by Bob Jueneman
>to address the fallout of removing the mandatory nature of centralised
>key generation by CAs. I also support Bob's general direction for
>both keygen and the KRI. I have noone object to his proposal
>which represnts a number of technical and policy compromises.

I mostly agree...  I am reluctant to remove the option of a request for
central key generation completely from the cert. request message (which
was Bob's preference for reasons of "parsimony").  If an EE knows that
the CA will generate its encryption key pair (which will be the case in
many large organizations), I see no reason why the standard should
mandate that two separate message exchanges be used for this.

Given that the cert. request message is already a SEQUENCE of
FullCertTemplate, there is no extra effort for the EE or the CA to
understand the format of this combined request (the Appendix B profile
simply says that the first FullCertTemplate is to be used for an
EE-generated key pair and the second FullCertTemplate, if used, is for a
centrally-generated key pair).  I therefore see no simplification in
removing this optional request and, on the contrary, see removal as
being more cumbersome (i.e., more messages to support, more code to
implement) for the environments where this will be needed.

Other than that, as I have said, I agree to Bob's proposal.




>I am willing to aid Bob in the writing task for his proposed I-D
>as a secondary author.

It will be wonderful to see your name in the list of authors on an
Internet Draft.




>The co-chairs could perhaps now call for final arguments, and
>then decide the concensus position, and the actions.

Given that over a week has gone by since you sent your message, and
given that not a single response has been submitted, I would guess that
we already have consensus:

- CA key generation will be downgraded from mandatory to optional (which
means that EE key generation will be upgraded from optional to
mandatory, although this may be accomplished as described next);

- Bob and Peter will submit an I-D (separate from PKIX-3) specifying a
request/response (possibly request/response/confirm) protocol for key
generation.  This protocol may be supported by EEs, CAs, RAs, or any
other entity in the PKI.

Peter, Bob, Steve/Warwick, Everyone-Else:  does this sound reasonable?
Can I make the relevant changes in PKIX-3 and submit it for Last Call?


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