RE: More Comments to rfc2630bis-01
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
I would expect a change from Triple-DES to AES in the future... Given this
situation, maybe sooner is better than later.
At 05:27 PM 7/9/2001 -0400, Pawling, John wrote:
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
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
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
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
At 04:40 PM 7/5/2001 -0400, Pawling, John wrote:
>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:
>[*** NEW ***] Implementations MUST support key transport, key agreement,
>previously distributed symmetric key-encryption keys, as represented by
>ktri, kari, and kekri, respectively.
>Implementations MAY support the password-based key management as
>by pwri. Implementations MAY support any other key management technique as
>represented by ori.
>[*** 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
>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