RE: More Comments to rfc2630bis-01

John,

I am afraid I must disagree with you on this issue.

IMHO, rfc2630bis should require implementation of all of the defined
alternatives.  What we are looking at here is the toolkit side of the issue.
S/MIME can come along and require implementation of only a partial set of
the alternatives by requiring a partial set of the algorithms.

I think that toolkits that do not implement all of the different
alternatives have to state that they are only partially compliant with what
will hopefully be the CMS Standard.  This is not an issue for toolkits that
are implemented for specific protocals.  It may be that this point of view
will be modified in some way by the lack of implementations for items.  But
that is the only reason that I think one of these items should be lowered
from MUST implement to MAY implement (note that I see no benifit here for
SHOULD implement).

jim

> -----Original Message-----
> From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
> [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Pawling, 
> John
> Sent: Monday, July 09, 2001 2:28 PM
> To: SMIME WG (E-mail)
> Subject: RE: More Comments to rfc2630bis-01
>
>
>
> Russ,
>
> I agree that the "MUST implement" requirements regarding
> support of the
> alternatives within the RecipientInfo CHOICE are indirect in
> RFC 2630.  In
> my opinion, they should also be indirect in rfc2630bis.  My
> recommended text
> provides this indirection.  The "MUST implement" algorithms
> specified in
> cmsalg will indirectly mandate which alternatives within the
> RecipientInfo
> CHOICE are "MUST implement" requirements.
>
> I believe that my recommended text provides the IETF with flexibility
> regarding the separation of the protocol and the mandatory to
> implement
> algorithms.  Compliant implementations will support  the
> alternatives within
> the RecipientInfo CHOICE required to support the
> mandatory-to-implement
> algorithms stated in cmsalg.  If the IETF changes the
> mandatory-to-implement
> algorithms in cmsalg such that a different RecipientInfo
> CHOICE is required,
> then vendors will enhance their implementations to support
> the required
> RecipientInfo CHOICE in conjunction with implementing the new
> algorithm.
>
> Compliance testing is another issue with the current
> rfc2630bis-01 text.
> For example, how will a product be tested for compliance with
> the "MUST
> implement" KARI alternative in the RecipientInfo CHOICE if
> that product does
> not implement any key agreement algorithms?  Similar question
> regarding the
> KEKRI alternative?  Will vendors be forced to implement
> algorithms solely to
> test their compliance with the "MUST implement" alternatives
> within the
> RecipientInfo CHOICE?
>
> ===========================================
> John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
> Getronics Government Solutions, LLC
> ==========================================
>
>
> -----Original Message-----
> From: Housley, Russ [mailto:rhousley(_at_)rsasecurity(_dot_)com]
> Sent: Monday, July 09, 2001 4:23 PM
> To: Pawling, John
> Cc: SMIME WG (E-mail)
> Subject: Re: More Comments to rfc2630bis-01
>
>
> John:
>
> This is not quite true.  The MUST implement statements were
> indirect. They
> came from the mandatory to implement algorithms.  In order to support
> Ephemeral-Static Diffie-Helman, one must implement kari.
>
> At the last IETF meeting, we discussed the desire for
> separation of the
> protocol and the mandatory to implement algorithm.  For the
> IETF to have
> any flexibility in this area, the protocol implementation
> must support the
> major choices.
>
> Russ
>
> At 04:40 PM 7/5/2001 -0400, Pawling, John wrote:
>
> > All,
> >
> > I have the following comment to rfc2630bis-01 (in addition to those
> > submitted on 27 June):
> >
> > 1) Section 6.2, RecipientInfo description:  RFC 2630 did not
> include any
> > "MUST implement" requirements regarding support of the
> alternatives within
> > the RecipientInfo CHOICE.  I don't believe that rfc2630bis
> should include
> > any such "MUST implement" requirements either.  Please make
> the following
> > change to the third paragraph:
> >
> > OLD:
> > [*** NEW ***] Implementations MUST support key transport,
> key agreement,
> and
> > previously distributed symmetric key-encryption keys, as
> represented by
> > ktri, kari, and kekri, respectively.
> > Implementations MAY support the password-based key management as
> represented
> > by pwri.  Implementations MAY support any other key
> management technique as
> > represented by ori.
> >
> > NEW:
> > [*** NEW ***] The ktri, kari, kekri, and pwri alternatives in the
> > RecipientInfo CHOICE are used for the key transport, key agreement,
> > previously distributed symmetric key-encryption keys, and
> password-based
> key
> > management techniques, respectively.  The ori alternative in the
> > RecipientInfo CHOICE is used for any other key management technique.
> >
> > ===========================================
> > John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
> > Getronics Government Solutions, LLC
> > ===========================================