Re: PKCS#7 in PKIX-3

[dpkemp@xxxxxxxxxxxxxx (David P. Kemp)]

> From: Warwick Ford <wford@verisign.com>
> 
> >From observation of many prior standardization activities, I suggest that
> solutions built by incrementally advancing existing, accepted,
> well-understood solutions have been far more successful than attempts to
> define something totally new, even if the latter was technically superior.
> 
> I believe this same feeling was supported by strong concensus in the San
> Jose PKIX meeting.  If PKCS#7 satisfies requirements for many people, and
> some incremental extensions to PKCS#7 would satisfy requirements for
> everyone, then this is clearly far more likely to be accepted as a standard
> than a totally new invention such as the proposal in the December I-D.
> 
> I would hate to see us use up scarce resources on a new protocol which lacks
> broad buy-in from day one.
> 
> I would appreciate hearing opinions from other members of the list.
> 
> Warwick
> 
> >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



I concur that:
  1) a single encapsulation mechanism would be ideal, and
  2) incremental improvement of an existing mechanism is better than
       "something totally new".

However, I don't see how PKCS #7 can be incrementally extended to
"satisfy requirements for everyone" except by being incrementally
extended until it includes a subset that looks remarkably like PKIX 3.

Therefore I think the group should proceed as follows:

  1) migrate PKIX 3 towards status as an IETF Technical Standard.
  2) accept PKCS-7 as an IETF draft, and migrate it towards status
       as an IETF Technical Standard.
  3) write an Applicability Statement (such as Tim's Minimum Interoperability
       Specification) that requires servers to support both PKIX 3 and PKCS 7
       message formats, and requires clients to support at least one of the
       two.
  4) if during the IETF standardization process PKCS-7 becomes incrementally
       extended to encompass the functionality of PKIX 3, then amend the
       Applicability Statement to require conformance with just the single
       improved message format.


    dpk

(who's former boss now works for the same company as Peter and Warwick)