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