RE: PKCS#7 in PKIX-3

[Carlisle Adams <Cadams@xxxxxxxxxxx>]

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