Subject: More Comments to rfc2630bis-01

From: "Pawling, John" <[email-masked]>
Date: Thu, 5 Jul 2001 16:40:18 -0400

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 09 Jul 2001 16:22:37 -0400

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