Subject: RE: More Comments to rfc2630bis-01

From: "Pawling, John" <[email-masked]>
Date: Mon, 9 Jul 2001 17:27:57 -0400

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

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
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, [email-masked]
>Getronics Government Solutions, LLC
>===========================================

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 9 Jul 2001 16:27:52 -0700

John,

I am afraid I must disagree with you on this issue.

IMHO, rfc2630bis should require implementation of all of the defined
alternatives.  What we are looking at here is the toolkit side of the issue.
S/MIME can come along and require implementation of only a partial set of
the alternatives by requiring a partial set of the algorithms.

I think that toolkits that do not implement all of the different
alternatives have to state that they are only partially compliant with what
will hopefully be the CMS Standard.  This is not an issue for toolkits that
are implemented for specific protocals.  It may be that this point of view
will be modified in some way by the lack of implementations for items.  But
that is the only reason that I think one of these items should be lowered
from MUST implement to MAY implement (note that I see no benifit here for
SHOULD implement).

jim

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Pawling, John
> Sent: Monday, July 09, 2001 2:28 PM
> To: SMIME WG (E-mail)
> Subject: RE: More Comments to rfc2630bis-01
>
>
>
> Russ,
>

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 10 Jul 2001 09:23:36 -0400

John:

In an architecture where a cryptographic API is employed, the protocol 
implementation must be able to handle any of the algorithms that might be 
offered by the cryptographic implementation behind the API.  When the 
cryptographic implementation is based on a hardware token (e.g., smart 
card), the protocol implementation can encounter a large number of 
different algorithm combinations.

I would like to see the specifications encourage support for modular 
implemntations that support hardware tokens.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 10 Jul 2001 09:15:23 -0400

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