[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: PKCS 7 + PKCS 10 Proposal
At 03:00 PM 8/6/97 -0400, Carlisle Adams wrote:
>
>I have a number of major concerns with the proposal that was submitted
>to these lists recently, along with several serious, but less critical,
>concerns. I'll only mention the major ones here.
Thank you, Carlisle for this analysis.
>
>The draft does not simply promote the notion that one need only have a
>single key. Rather, it fundamentally relies on that notion. [See, for
>example, the first sentence of Section 5.1.1.2 which says, "Because the
>response is encrypted with the user's public key.... This is the
>response to the certification request, which (being a PKCS #10 request)
>was signed with the user's private key. One key pair for both signing
>and encryption. Didn't I hear a (loud) call from the group recently
>saying that DSA should be mandatory for the PKIX protocols and that RSA
>should be optional?]
In an environment where there is operationally only a need for an identity
key (Oakley RSA Sig), is putting a requirement that there be an encrypting
key to be used only for the 'registering' of the identity key valuable?
Of course, this focuses my mind on the construct of Oakley RSA encrypt and
the new Oakley enhanced RSA encrypt. Is its design based on a single
key-pair RSA environment? And if so, what would a duo-key-pair RSA encrypt
exchange look like?
BTW, for systems that have an operational need for public key encryption
(EMail as one), my position is that duo-key-pair is the right model, and
single key-pair is fatally, legally flawed.
>>2. It provides no means to certify a D-H key. Recognizing that the WG
>>has received a proposal to do so using PKCS 10 constructs, there still
>>remains a problem of coordinating parameters between the client and the
>>CA.
This is facinating and needs to be addressed. When will it impact IPsec?
>>3. It does not adequately address the subscriber bootstrapping
>>problem.
>
>"Does not adequately address" is a little understated. It does not
>address this problem at all. In other words, there is no
>(cryptographically secure) way for a brand-new end entity to get
Important for scaling, as you point out. Better than current method of
sending Email. Is leap-frogging possible within 3 months?
>an IPKI. Considering that this work has already been done in PKIX-3,
>and that it is ready to go to Working Group Last Call, it seems to me
>that the proposal given here may be suitable as a (standardized or
>proprietary) protocol in some other context, but not within the stated
>scope of the PKIX Working Group.
Is PKIX-3 (showing my lack of energy to cover it too) codeable? Are there
any implimentations out there that we can see in action? When can we
schedule an interoperablity workshop (is one needed?)?
I've got some cars to build.
Thank you all for the on-going education.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
References: