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