Carlise: I believe there is a better way than saying always "no, no and no", to _actually_ open systems component technology and a world of third-party, multi-vendor "highly re-bundlable" key management technology. I want PKIX to be a useful componentware standard, not merely a pretend std for marketing closed or proprietary technology. Surely the days of the monolithic CA management systems are over; even their tiny appreciative market is going away. We now need a plug-and play CA technology world, where its the "proprietary" business rules of the using and issuing organizations which govern how functional units of a PKIX system are combined to make a specific CA certificate issuing and mgt solutions for bank A, brokerage B, institution C. This is well represented by the PKCS7 (aka layered protection and PKIX-protocol-independent mgt control framework) proposal to this WG. The notion I ventured (reflecting merely what the last meeting asserted and concensually assented to, apparently - as with the strangely missing WWW and S/MIME PKCS#10 feature whose assent was consensually indiciated on at the previous meeting, but which also failed to become realised in the PKIX-3 spec) does not require huge change to documents, nor does it require hold up of the current publication schedules. It merely requires assent of *both* authors to now go with the flow of the group and the interested parties. >From my mailbox, and having consulted the primary players, I think Carlise you are the only party not in consort with the proposal. As an author whose document we are commenting, however, I respect your judgement; so we should only do this is you too agree to move along this path. I think the commercial relevance of PKIX-3 hinges on this issue, however. Without PKIX-3, PKIX-1's profile judgements may not be really that important either. Id urge folk to respect the (expressed) will of the group to move down this layering path. Precisely which wire format specs are agreed upon, I for one dont really mind; this is not the issue for me. Id like PKCS7 as defined now _at least_ to be indicated, and for the next generation being developed in the IETF process with specifically these CA and other environment's requirements in mind to be urged, and architected into the PKIX-3 system and protocol requirements. So, Just as the Oakley key agreement spec for IPSEC asserts that use of DNS security/certs is mandatory (despite the fact that DNS security is neither agreed, fully finished/documented, nor ratified within its respective WG and the IESG security area directorate) so then, with the appropriate language, we mandate an architectural realationship to a PKCS7-like messaging service, but not required that all implementations have to realise it. just as SKIP specifies 4 cert types, not all of which need to be implemented... just as IPSEC std allows a multitude of non-interoperable security service and algoirithm profiles.... just as SSL/TLS allows an RSA client to fail to work with a DH-only SSL server... These std are real, and not pure. So PKIX-3 should be. At 11:59 AM 1/28/97 -0500, Carlisle Adams wrote: >Hi Russ, > >>---------- >>From: housley@spyrus.com[SMTP:housley@spyrus.com] >>Sent: Monday, January 27, 1997 7:08 AM >>To: ietf-pkix@tandem.com; peter@verisign.com >>Subject: Re: PKCS#7 in PKIX-3 >> >> >>I think that we are near concensus on this point. A single >>encapsulation mechanism would be ideal. PKIX Part 3 contains one >>suggestion, and PKCS #7 contains another. Carlise provided an >>analysis for the PKIX Part 3 approach. PKCS #7 has a market >>share that should not be ignored, and the specification is open >>for reivew and update. Further, RSA has agreed to work with the >>IETF on the PKCS "standards" and give configuration control to >>the IETF where standards track RFCs result. >> >>So, how does the group want to proceed? >> >>Russ > > >At the risk of sounding repetitious, let me try to state a couple of >things as clearly and succinctly as I possibly can. > >1) The PKIX-3 protocol, as currently specified, is able to handle >protection for PKIX-3 messages in all situations (i.e., when >end-entities already have public-key certificates (for various >algorithms), and when they don't (but they do have some shared secret >information with the other end)). Furthermore, it allows the option of >"no protection", so that if two parties want to take "bare" PKIX-3 >messages and wrap these using PKCS#7 (or any other mechanism) in >circumstances for which this is appropriate, they are free to do so. > >2) The PKCS#7 enveloping protocol, as currently specified, is *not* able >to handle protection for PKIX-3 messages in all situations (for reasons >discussed in my previous posts). It is perfectly adequate for *some* >situations, but not all. > > >I cannot imagine that it makes sense to make *mandatory* a mechanism >which will not work in all situations. It makes much more sense to make >such a mechanism *optional*, so that it can be used wherever >appropriate. This is exactly what the current PKIX-3 protocol does. >What is mandatory is the lowest common denominator which will work in >every situation providing perfectly good protection; PKCS#7 is >optionally allowed for any situation for which it is appropriate. > >The two statements, "PKCS#7 has a market share that should not be >ignored" and "the specification is open for update" are contradictory. >Changing PKCS#7 in any way (even if change control is given to the IETF) >*does* ignore the market share, since it requires every implementation >in the installed base to be modified. If the market share should really >not be ignored, then the current PKIX-3 makes the most sense since this >allows the installed base to be used, as is, whenever this is >appropriate. > >"How does the group want to proceed?" Good question. As I see it, >there are two options. We can keep what we have since it works in all >situations, since it is easy to understand and implement, and since it >respects the installed base by allowing code re-use wherever this can be >done. Or we can hold up progression of the PKIX management protocols >for some indeterminate time (at least months; possibly longer) until >PKCS#7 is "updated" to everyone's satisfaction. [In my opinion, we are >likely to find that the update, when finally complete, looks very much >like the protection scheme we already have.] >> >-------------------------------------- >Carlisle Adams >Entrust Technologies >cadams@entrust.com >--------------------------------------- > >
Attachment:
smime.p7s
Description: application/pkcs7-signature