RE: More Comments to rfc2630bis-01

John:

The problem is that the advice that we are getting from the IESG says that 
we cannot proceed in a completely modular fashion.  If the protocol 
specification depends on the algorithm specification, then they must 
proceed from proposed o Draft to Full Standard together.  A change to the 
algorithm specification will cause both documents to return to Proposed 
Standard!
I would expect a change from Triple-DES to AES in the future...  Given this 
situation, maybe sooner is better than later.
Russ

At 05:27 PM 7/9/2001 -0400, Pawling, John wrote:

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