Subject: RE: More Comments to rfc2630bis-01

From: "Pawling, John" <[email-masked]>
Date: Tue, 10 Jul 2001 10:48:18 -0400

Russ and Jim,

I see your point.  You guys have convinced me that Section 6.2 should
continue to mandate that "implementations MUST support key transport, key
agreement, and  previously distributed symmetric key-encryption keys, as
represented by ktri, kari, and kekri, respectively".  In fact, the S/MIME
Freeware Library (SFL) was developed using the same architectural principles
as discussed in your replies.  The SFL is composed of a high-level library
that implements the RFC2630 and RFC2634 specifications independently of the
crypto algorithms used to protect a specific object. The SFL high-level
library makes calls to a generic, algorithm-independent crypto API.  Using
this architecture, the high-level SFL library does not need to be modified
to support new crypto libraries, algorithms or tokens.  The SFL source code
is freely available to everyone from
<http://www.getronicsgov.com/hot/sfl_home.htm>.  

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Tuesday, July 10, 2001 9:24 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: More Comments to rfc2630bis-01

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

At 04:27 PM 7/9/2001 -0700, Jim Schaad wrote:

>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