ietf-smime
[Top] [All Lists]

RE: More Comments to rfc2630bis-01

2001-07-10 07:48:08

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, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Housley, Russ [mailto:rhousley(_at_)rsasecurity(_dot_)com]
Sent: Tuesday, July 10, 2001 9:24 AM
To: John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
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

<Prev in Thread] Current Thread [Next in Thread>