[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: PKCS 7 + PKCS 10 Proposal
> > From: mmyers@verisign.com[SMTP:mmyers@verisign.com]
> >
> >To the last point, I would observe that the draft is intended to address
> >only the most essential elements of a PKI service, with the thought in
> >mind that additional work would be needed to expand upon these basic
> >services.
What would this additional work entail?
* The addition of features not currently addressed by the draft which
are already addressed by the existing PKIX-3?
* Modification of the protocol to track development of PKCS #7?
I note that the draft (section 3.6) uses the signedData and envelopedData
constructs, so it is apparently based on version 1.5 of PKCS7.
PKCS7 version 2.0 combines these and several other constructs into two
generic items - IntegrityProtectionInfo and EncryptionInfo.
Will your proposal stick with the old PKCS7 to allow the installed base
of code to continue to be used, or will it use current PKCS7, maintaining
synchronism with S/MIME but requiring new code development?
If new code is required, why shouldn't it be based on PKIX-3?
> From: Carlisle Adams <Cadams@entrust.com>
>
> In other words, the plan seems to be to essentially re-do everything
> that has already been done in the past 1-1/2 to 2 years with PKIX-3.
> Mike has repeatedly said to me that a lot of effort and thinking has
> gone into PKIX-3 to construct a secure, general set of protocols for
> certificate management. Does it make sense to do this all again for
> this new proposal (and wait another 1-1/2 to 2 years to get something
> that is strong enough and general enough to be useful)? My personal
> feeling is, "No".
>
> Ultimately, what PKIX is all about is the definition and standardization
> of a Public-Key Infrastructure for the Internet. The proposal given
> here cannot (and does not) claim to build such an infrastructure. It
> may provide *some* of the necessary functionality for *some*
> environments (although I still worry about not being able to securely
> initialize entities), but this limited focus is clearly inadequate for
> 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.
I agree completely with this summary. It is perfectly reasonable
for PKI providers to continue to use and support a suboptimal but
working legacy protocol for as long as there is a market for it.
This doesn't require any action by the IETF - just do it.
But it is not reasonable for PKIX to devote resources to standardizing
a partial solution when a well-specified complete solution has already
gone through the long process and is ready to proceed to Proposed Standard.
> From: Robert Moskowitz <rgm3@chrysler.com>
>
> 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?
It is certainly codeable. PKIX-3 bears a striking resemblance to the
MISSI Management Protocol (MMP), which provides certificate and key
life-cycle support, audit, and additional Government-specific
functionality related to the initialization of Fortezza(R) cards. MMP is
running today (and has been for several years) in BBN (GTE) and
Motorola products - if you stripped out all the non-certificate-related
messages you would have something that looks pretty similar to PKIX-3.