Re: PKIX and PKCS7/10

["Rich Ankney" <rankney@xxxxxxxxx>]

I understand where you're coming from.  OTOH, there are quite a few of us
who have big investments in PKCS-7/10.  I'd like to treat the two
alternatives as separate but equal, but ONLY if PKCS-7/10 can be tweaked to
do EVERYTHING that PKIX-3 does (this is not at all obvious).  CertCo's
motivation in all of this is that PKCS-7 lets us "append" stuff (which must
remain nameless right now) to the original message.  This is demonstrated
really well in the Myers draft, where the whole PKIX header is conveyed as
authenticated attributes...

Regards,
Rich

----------
> From: David Kurn <kurn_david@tandem.com>
> To: IETF-PKIX@tandem.com
> Subject: PKIX and PKCS7/10 
> Date: Wednesday, August 13, 1997 7:02 PM
> 
> Folks
> 
> We at Tandem Computers Inc (Cupertino California) have been watching the
> recent discussions on the PKIX mail-list, dealing with an alternate
> proposal for the material covered in PKIX-Part3.  We have observed the
> technical pros-and-cons, and need a bit more time to really understand
them.
> 
> However, we are quite bothered by several non-technical aspects of the
> proposal (at least non-crypto-technical):
>  
> The current PKIX work is the result of a lot of hard work by very skilled
> people for the past two years.  It has been done in the best traditions
of
> the IETF - through open discussion and evolution.  Many contrary ideas
have
> been suggested, some accepted, some modified, and some rejected.  But, on
> the whole, the work has been co-operative AND open.  It may not be the
best
> solution possible, but does satisfy the principle of "rough-consensus",
and
> is a good place to stop, document, implement, and think of evolutionary
> changes for the future.  There will always be proposals that are better,
> but if we wait to absorb all of them, we won't make any progress.
> 
> The newly submited alternatives, by Meyers, Deacon and Liu, involving
PKCS7
> and PKCS10 appear to have few of the usual properties that make the IETF
> work.  The work (and clearly there was quite a bit) was done in a closed
> manner, or at least, not in a manner that was visible to the community.
> The work relies upon proprietary algorithms.  There has been little or no
> chance for the community to absorb it, consider its implications, and
> contribute feedback.  And, it was submitted not to the working-group for
> discussion and debate, but intead as an document, but as an Internet
Draft
> whose title page flags it as a submission from the PKIX working group.
> 
> Working implementations of PKIX protocols exist today.  We believe that
> Entrust Technologies Inc is currently shipping a version of their
software
> that employs PKIX protocols (you should check with the Entrust folks for
> details).  We at Tandem intend to ship products using PKIX protocols
shortly.
> 
> In raising this objection, we agree with the position advocated by
Carlisle
> and his associates that this newly submitted proposal should not cause
any
> delay in the advancement of the PKIX documents (in particular, Part 3) as
> they stand today, through the normal IETF progression.
> 
> David Kurn
> Tandem Computers Inc
> Email: dkurn@tandem.com
> 
> Kent Salmond
> Tandem Computers Inc
> Email: salmond_kent@tandem.com