13 December 2000 S/MIME WG Minutes

["Pawling, John" <[e-mail]>]

This message includes the minutes of the IETF S/MIME Working 
Group (WG) meeting held on 13 December 2000 in San Diego, 
California. Briefing slides will be available from
<ftp://ftp.ietf.org/ietf/smime/>.  These minutes include comments
from the briefing presenters.  Reported by John Pawling.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Introductions - Russ Housley
 
Russ reviewed the agenda as follows.  Nobody commented on the agenda.

Introductions				Russ Housley
Working Group Status			Russ Housley
Interoperability Matrix 		Jim Schaad
CMS and ESS Examples			Paul Hoffman
Security Policies and Labels		Weston Nicolls
Symmetric Key Distribution		Sean Turner
Domain Security (DOMSEC)		Bill Ottaway
X.400 and CMS				Chris Bonatti
Reuse of Content Encryption Keys	Steve Farrell
Advanced Encryption Standard		Jim Schaad
RSA-OAEP and RSA-PSS			John Linn 
RSA as a MUST implement			Blake Ramsdell
E-Signature Formats using CMS		John Ross
E-Signature Formats using XML		Denis Pinkas
S/MIME Freeware Library 		John Pawling
Wrap up					Russ Housley

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Working Group Status - Russ Housley

Russ outlined the strategy for advancing the following RFCs from
Internet Proposed Standards to Internet Draft Standards:
RFC 2630 Cryptographic Message Syntax (CMS), R. Housley, June 1999
RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999
RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the
          Diffie-Hellman Key Agreement Method for S/MIME, 
          R. Zuccherato, March 2000. [Informational]
RFC 2876 Use of the KEA and SKIPJACK Algorithms in CMS, J. Pawling,
          July 2000. [Informational]            
RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS, C. Adams,
	    October 2000

The aforementioned documents must meet the following requirements to
advance to Draft Standards:
1) Meet requirements documented in RFC 2026
2) Stable, mature, and useful specification
3) At least two independent and interoperable implementations
   from different code bases
4) Draft Standards cannot reference Proposed Standard RFCs or 
   Experimental RFCs, so the aforementioned RFCs are blocked
   until the PKIX Certificate and CRL Profile "Son-of-RFC 2459"
   Internet-Draft (I-D) (draft-ietf-pkix-new-part1-03.txt) 
   progresses to Draft Standard. 

Russ stated that Jim Schaad has developed an interoperability matrix
for RFCs 2630 through 2634. The interoperability matrix is posted at
<http://www.imc.org/ietf-smime/interop-matrix.html>.  The matrix 
indicates which features have and have not been successfully tested.
So far, Jim Schaad and Getronics Government Solutions have provided
input to the interoperability matrix.  Jim has provided input
regarding the capabilities of the Microsoft S/MIME v3 implementation.
Getronics has provided input regarding the capabilities of the
S/MIME Freeware Library (SFL) including interoperability testing 
conducted with Microsoft.  

Russ noted that Paul Hoffman (IMC) has offered to coordinate 
interoperability testing and to enhance the "Examples of S/MIME 
Messages" I-D.  He asked that other organizations that have
developed S/MIME v3 capabilities should please participate.

Russ said he would submit that proposal to the S/MIME WG mail list.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Interoperability Matrix - Jim Schaad

Jim discussed the interoperability matrix for RFCs 2630 through 2634.
He has documented the successful completion of two-way interoperability
testing for the following number of clauses in each RFC.  He has not
completely updated the results based on all interop testing performed:

   RFC       Clauses Tested
  =========================
   2630        49 of 96
   2631         0 of 13
   2632        16 of 21
   2633        17 of 61
   2634        27 of 81

More details regarding RFC 2630 testing:
Signed Data - 24 of 25
Enveloped Data - 11 of 25
Digested Data - 0 of 4
Encrypted Data - 0 of 4
Authenticated Data - 0 of 16
Other MUST Implement Requirements - 15 of 25
TOTAL - 49 of 96

More details regarding RFC 2634 testing:
Triple Wrap - 3 of 5
Signed Receipts - 19 of 41
Security Labels - 5 of 11
Equivalent Labels - 0 of 12
Mail List - 0 of 12
TOTAL - 27 of 81

Jim asked for others to submit input to him at [e-mail].

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Examples of S/MIME Messages - Paul Hoffman

Paul stated that he had distributed a new release of the "Examples of
S/MIME Messages" I-D <draft-ietf-smime-examples-05.txt>, November 
2000, that includes additional sample data generated by Getronics
using the SFL.  He stated that the document needs further input and 
testing.  He noted that Jim Schaad is testing all of the samples
included in the document.  John Pawling recommended that a triple-
wrapped sample message should be added to the document.  Jim 
has already generated several triple-wrapped messages and will
provide them to Paul for inclusion in the document. 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Mapping Company Classification Policy to the S/MIME Security Label - 
Weston Nicolls

Weston stated that he had distributed a new release of the 
"Implementing Company Classification Policy with the S/MIME
Security Label" I-D, <draft-ietf-smime-seclabel-02.txt>, October 2000.
He noted that his goal is for the document to become an Informational
RFC.  It provides examples of how the RFC 2634 ESSSecurityLabel 
feature can be used to support an organization's security policy. The
document includes classification policies and example security
labels for the Amoco, Caterpillar and Whirlpool corporations.
It includes an example security category syntax and samples.
It also includes Clearance attribute examples that include a
subject's authorizations.

Russ Housley proposed that Last Call for this document should be
completed by January 2001.  Nobody objected.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Symmetric Key Distribution - Sean Turner

Sean stated that he had distributed a new release of the S/MIME
Symmetric Key Distribution I-D, <draft-ietf-smime-symkeydist-02.txt>, 
October 2000.  Sean noted that Jim Schaad provided significant 
comments to the symkeydist-01 I-D that Sean incorporated into the 
symkeydist-02 I-D.  

Sean stated that two messages were added: GLProvideCert and
GLUpdateCert.  The GLDistributionMethod message was removed.
The GLInfo, GLOwner, and GLMember syntaxes were modified to
include "address" information.  There were many changes made
to more closely align with RFC 2797 Certificate Management
Messages over CMS.  He added text to explain how many and
when rekey messages are distributed.  The rekey defaults 
were fixed.

Sean stated that he still needed to add a conformance clause
and an Abstract Syntax Notation One (ASN.1) module.  He also
needs to verify correctness of RFC 2797 error behavior.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

DOMSEC Draft Discussion - Bill Ottaway

Bill presented a briefing regarding the "Domain Security Services Using
S/MIME" I-D <draft-ietf-smime-domsec-07.txt>, November 2000.  He made
several minor changes as a result of e-mail exchanges with Jim Schaad
on the S/MIME WG mail list.  

He added a section regarding Mail List Agents (MLA) that addresses
the situation in which an MLA will remove the 'domain signature' when
the signature encapsulates a mlExpansionHistory attribute and/or a 
envelopedData type.  He briefed the solution to this problem which
is documented in domsec-07 in Section 5, "Applying a Domain Signature
when Mail List Agents are present".  He stated that the he believes
that the outstanding issues have been resolved and that the DOMSEC 
I-D should be submitted for last call.  

Russ Housley proposed that the DOMSEC document is ready for S/MIME WG
Last Call.  The intent is for this document to be published as an
Experimental RFC.  Russ proposed that the S/MIME WG Last Call should
close on 10 January 2001.  Nobody objected.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

X.400 and CMS - Chris Bonatti

Chris presented a briefing regarding the "Transporting S/MIME Objects
in X.400" I-D, <draft-ietf-smime-x400transport-01.txt> and "Securing
X.400 Content with S/MIME" I-D, <draft-ietf-smime-x400wrap-01.txt> 
both distributed in November 2000.  The x400wrap I-D specifies how
to protect X.400 content with CMS objects.  It is roughly analogous
to RFC 2633 and refers to RFC 2633 when applicable.  It minimizes 
the use of MIME encodings to reduce overhead.  He briefed the 
proposed wrapping strategy.  He discussed the object identifiers
used, MIME heading parameters and detached signature form.  He
has already incorporated comments submitted by Bill Ottaway and
Graeme Lunt.

Chris noted that products generally do not support encapsulating 
content types other than data (such as signed-data or enveloped-data).
Jim Schaad challenged that statement and noted that the Microsoft,
SFL and Peter Gutmann's cryptlib S/MIME v3 implementations do 
support encapsulating content types other than data.

The x400transport I-D specifies how to package CMS objects for 
transport by X.400 Message Transfer Agents (MTA).  It discusses 
the scenario in which the CMS encapsulated content is an RFC 822
MIME message.  It states that the outer MIME wrapper is not generally
necessary in X.400.  It also states that circumstances may exist when
the outer MIME wrapper is desirable such as when a gateway into an 
SMTP transport is part of the architecture.  Chris discussed the
object identifiers used, packaging the CMS object in the X.400 
content and that messages that only contain certificates are not
supported.  He has incorporated comments submitted by Bill Ottaway.

Blake Ramsdell asked about support for messages that only contain
certificates.  Chris responded that messages that only contain
certificates are supported, but they can't be identified as such 
in the wrapper.  

Chris recommended that these I-Ds be placed on the standards track
and asked for feedback from the WG.  Russ Housley and Jeff Schiller
agreed with Chris' recommendation.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Reuse of Content Encryption Keys - Steve Farrell

Steve presented a briefing regarding the "Reuse of CMS Content
Encryption Keys" I-D, <draft-ietf-smime-rcek-00.txt>, September 2000.
The rcek I-D specifies how to set up a shared secret key using 
asymmetric crypto (using EnvelopedData object) and then to re-use 
the content encryption key (CEK) to derive the Key Encryption Key (KEK)
of the next message.  It defines attributes for inclusion in 
EnvelopedData objects that indicates that the CEK is to be re-used 
and the maximum number of times that it can be re-used. 

Steve noted that the I-D specifies a key derivation scheme for the 
re-use of CEKs when the KEK and CEK algorithms must be different. 
The I-D defines a new attribute for this case.  It also documents a
new key derivation function with the property that it only requires
the use of the CEK encryption algorithm.  The function is documented
in the rcek I-D, "Using different CEK and KEK algorithms" section.  
Blake Ramsdell recommended that Steve examine the Public Key 
Cryptography Standard (PKCS) #5 v2 key derivation function as an
alternative to defining a new function.
 
Steve stated that the outstanding issues are how much to specify 
failure cases and the proposed key derivation scheme.  He would like
to do one more version and then submit it to WG last call.  He 
recommended that this I-D be placed on the standards track.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Advanced Encryption Standard (AES) in CMS - Jim Schaad

Jim presented a briefing regarding the "Use of the Advanced 
Encryption Algorithm in CMS" I-D, <draft-ietf-smime-aes-alg-00.txt>,
November 2000.  The aes-alg I-D specifies how to incorporate AES 
into CMS as an additional algorithm for symmetric encryption.  Jim
briefed that the proposed AES parameters are as follows:
  Block Size - Fixed at 16 bytes
  Key Size - 128, 192 or 256 bits
  Proposed MUSTs 128 and 256 bits

Jim noted that the aes-alg I-D does not include an AES key wrap 
algorithm.  He proposes to include 256-bit key wrap algorithm as
the only MUST-implement requirement.  Paul Hoffman asked if Jim
knew the difference in performance between using 256-bit versus 
128-bit keys.  Jim responded that the 256-bit key wrap takes a
longer amount of time, but he didn't know the exact difference.

Regarding key management, the I-D specifies that compliant 
implementations MUST support key transport using the PKCS #1 v2.0
Optimal Asymmetric Encryption Padding (RSA with OAEP) technique. 
It also specifies that compliant implementations MAY support key 
agreement using Ephemeral-Static (E-S) Diffie-Hellman (D-H) with 
modifications.  It also specifies that compliant implementations 
MAY support symmetric key-encryption key management.   

Paul Hoffman commented that he believes that if the S/MIME WG 
specifies the use of both 128- and 256-bit keys, then customers
will always demand 256-bit keys to achieve maximum security.  
He is concerned that the use of 256-bit keys will be a significant
performance hit.  For example, he believes that using 256-bit keys
will drastically impact the performance of secure mail lists.  He 
asked if the WG should consider only specifying the use of 128-bit 
keys.

Jim responded that the certificate processing required to obtain a 
recipient's valid public key far exceeds the performance difference 
between using 128- and 256-bit keys.

An attendee pointed out that companies couldn't sell 128-bit 
implementations because they have already been advertising the use
of larger key sizes with Triple-DES.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

RSA-OAEP and RSA-PSS - John Linn 

John presented a briefing regarding the potential use of RSA-based 
encryption and signature algorithms in conjunction with CMS and
S/MIME.  He stated that many S/MIME products currently use the PKCS
#1 v1.5 (RFC 2313) RSA algorithm that defines encryption and 
signature algorithms using ad hoc padding.  PKCS #1 v1.5 RSA is 
specified as an optional algorithm in RFC 2630 (CMS).  John described
the PKCS #1 v1.5 padding formats and usage (his briefing slides 
provide details).  He then described the Bleichenbacher adaptive 
chosen cipher text attack on PKCS #1 v1.5 encryption padding.  The
attack requires information from hundreds of thousands of decryptions,
indicating whether correct padding resulted.  A successful attack
yields the result of a specific decryption.  It does not yield the
originator's private RSA key.  Countermeasures include protocol-level
means to ensure that information on decryptions is not available to
attackers (constraints on returned information; randomize key, 
continue upon detected pad error) and improved, plaintext-aware 
padding (OAEP) in the cryptographic layer.  More details are 
available in RSA Laboratories Bulletin #7 in
<http://www.rsalabs.com/bulletins>.

PKCS #1 v2.0 (RFC 2437) defends against encryption padding attacks
using OAEP in conjunction with the RSA algorithm.  It can be used
with CMS as described in the "Use of the RSAES-OAEP Key Transport 
Algorithm in CMS" I-D, <draft-ietf-smime-cms-rsaes-oaep-02.txt>.  
John stated that recent theoretical results on strengths and 
assumptions of OAEP proofs have been discussed in the cryptographic
research community, and have reinforced the conclusion that the 
OAEP properties remain strong for use with RSA.  He pointed out 
that OAEP offers attractive properties in a random oracle model. 
It is provably secure and provides a level of security that is 
directly related to the strength of the RSA function.  He also 
highlighted the fact that OAEP is plaintext-aware.  When OAEP is
used, it is impossible to generate valid cipher text without 
knowing the plaintext; thereby, effectively guarding against 
chosen-cipher text attacks.  He briefed the RSAES-OAEP steps
(his briefing slides provide further details).

PKCS #1 v2.1 (draft, September 1999; 2nd draft in preparation) 
defends against potential signature attacks using the Probabilistic
Signature Scheme (PSS).  John noted that like OAEP, PSS offers a
provably secure design.  He briefed the proposed PSS encoding 
operation (his briefing slides provides further details).

John stated that he does not know of any patents regarding the use
of OAEP technique as proposed for S/MIME.  The PSS encoding method
is patent pending by the University of California (UC).  UC agreed
to waive licensing on PSS for signatures with message recovery 
(PSS-R variant) if adopted in an IEEE standard.  

John briefed that OAEP is stable and is being included in the PKCS #1
v2.0, IEEE P1363 and ANSI X9.44 specifications.  He stated that 
standardization of PSS is being pursued in several forums and will 
be included in the IEEE P1363a and PKCS #1 v2.1 specifications.  He 
stated that there is intent in ANSI X9F1 to reopen X9.31 to 
incorporate PSS.  There is a revision in progress to include PSS-R 
in ISO 9796-2.

John proposed that for the short term the S/MIME v3 documents should 
specify PKCS #1 v1.5 as a "MUST implement" requirement and PKCS #1 
v2.0 RSA with OAEP as a "SHOULD implement" requirement.  He recommended
that the WG should specify RSA with OAEP as a "MUST implement" 
requirement for interactive CMS-based applications.  John proposed that
PSS signatures should be adopted as a long term solution along with 
the AES algorithm and new hash functions.

An attendee stated that multiple "MUST implement" requirements may be
tough to support on constrained platforms such as smart cards or palm
devices.

Jim Schaad pointed out that the format of the RSA public key is
identical for PKCS #1 v1.5 and PKCS #1 v2.0 RSA with OAEP.  He asked 
how an application was supposed to determine, based solely on the 
recipient's certificate, which algorithm to use as the key transport 
algorithm when encrypting data.  This would be a problem if both 
algorithms are "MUST implement" requirements.  Jim asked if RSA has
considered defining a new object identifier to identify public keys 
for subjects that use PKCS #1 v2.0 RSA.  Russ Housley replied that 
RSA decided to use the same object identifier to support both
algorithms. 

John Pawling pointed out that the SMIMECapabilities attribute could 
be used to identify an entity's preferred key management algorithm.
Jim replied that many products are not capable of processing the 
SMIMECapabilities attribute.  He also stated that an application may 
support multiple key management algorithms, so there is a question
regarding which algorithms will be advertised in the SMIMECapabilities
attribute.  Russ Housley stated that applications should offer a menu
that allows the user to select a combination of algorithms.  He
suggested that this topic should be discussed further on the S/MIME
WG mail list.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

RSA As a Must Implement - Blake Ramsdell

Blake proposed that RFC 2630 be changed to specify the PKCS #1 v1.5
RSA public key algorithm as the "MUST implement" key management and 
signature algorithm since the RSA patent has expired.  

Blake stated that the majority of the July 2000 S/MIME WG meeting 
attendees stated their preference that both the PKCS #1 v1.5 RSA and 
DSA algorithms be the "MUST implement" signature algorithms.  He
stated that messages sent to the S/MIME WG mail list questioned if
vendors would actually implement both algorithms if both were 
specified as "MUST implement".  Others asked if there was a valid set
of requirements justifying that both algorithms be specified as "MUST
implement".  Blake stated that PKCS #1 v1.5 RSA algorithm should be
the "MUST implement" signature algorithm and that DSA should be the 
"MAY implement"  signature algorithm.  Blake said that PKCS #1 v2.0 
RSA with OAEP should be discussed.  

Paul Hoffman raised the issue of the definition of "MUST implement"
requirements.  He described three definitions that various folks 
support: 1) describe current usage; 2) force a specific future 
solution; and 3) provide optimal security solution.  He recommended
that those that are interested in this issue should conduct a 
sidebar meeting to write a position paper that would then be sent
to the S/MIME WG mail list.

Russ Housley stated that the three definitions described by Paul 
point to different algorithm sets.  He stated that he would talk to
the security area director about this issue.  He was surprised by 
the characterization of the arguments.

Russ stated that if PKCS #1 v1.5 RSA is approved as the "MUST 
implement" requirement, then the S/MIME WG must document the 
safeguards that should be taken.

Russ conducted a straw poll of the meeting attendees to obtain 
their opinion regarding the following options for the "MUST
implement" signature algorithm: 
1) PKCS#1 v1.5 RSA 
2) DSA
3) Both
The meeting attendees were evenly divided between options 1 and 3.
Only one attendee voted for the "DSA" option.

Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the following options for the "MUST
implement" key management algorithm: 
1) PKCS#1 v1.5 RSA
2) PKCS#1 v2.0 RSA with OAEP 
3) E-S D-H
The meeting attendees were evenly divided between options 1 and 2.
Only one attendee voted for the "E-S D-H" option.

Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the definition of the "MUST
implement" requirement: 
1) force a specific future solution
2) describe current usage
3) provide optimal security solution. 
Not many attendees voted in this straw poll.  Two attendees voted 
for option 1, four voted for option 2 and one voted for option 3.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Electronic Signature Formats - John Ross

John briefed regarding the "Electronic Signature Formats for long term
electronic signatures" I-D.  The esformats I-D is based on the European
Telecommunications Standardization Institute (ETSI) Electronic Signature
Infrastructure Standardization and defines a process to provide proof of
the validity of a signature to be used if repudiation is attempted.  The 
esformats-02.txt was based on ETSI ES 201 733.  The new version, 
esformats-03.txt, is based on ETSI TS 101 733.  All of  the versions 
are based on RFC 2630.  John stated that the changes in the esformats-03
I-D include extensions to the previous version including: verifier
conformance options (Timestamping, Secure records); Signature policy 
options (Explicit by object identifier, Implied by signed content/
signature environment); and Content encoding indication (Content hints).  

John proposed that esformats-03 I-D is ready to become an Informational
RFC.  The planned work is: ETSI Implementation Trials; XML signature
formats; and more work on signature policies.

John then briefed regarding the "Electronic Signature Policies" I-D,
<draft-ietf-smime-espolicies-00.txt> that defines signature policies
for electronic signatures. He proposed that the espolicies-00 I-D 
is ready to become an Experimental RFC. 

Russ Housley proposed that the Electronic Signature Formats document
is ready for S/MIME WG Last Call.  The intent is for this document to
be published as an Informational RFC.  Russ proposed that the S/MIME 
WG Last Call should close on 10 January 2001.  Nobody objected.

Russ Housley proposed that the Signature Policies document is ready
for S/MIME WG Last Call.  The intent is for this document to be 
published as an Experimental RFC.  Russ proposed that the S/MIME WG 
Last Call will close on 10 January 2001.  Nobody objected.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

E-Signature Formats using XML - Denis Pinkas

Denis briefed that ETSI is defining new XML types to contain 
equivalent electronic signatures information to those ASN.1 types 
defined in the esformats I-D.  These new XML types would include 
additions to the Signature XML element as defined by the W3C/IETF.
He pointed out that there is not a one-to-one mapping from ASN.1
to XML because some of the ASN.1 structures (such as the 
MessageDigest signed attribute) have been incorporated into the XML
digital signature core syntax.  Denis listed the new XML types
defined (his briefing slides provide further details).  He stated 
that new encapsulating XML type(s) need to contain ASN.1-encoded 
data generated by PKI agents such as time stamp agents that 
implement ASN.1 protocols.  He discussed several proposals for
accomplishing this goal.  

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Freeware Library (SFL) - John Pawling

John briefed regarding the SFL which is a freeware implementation
of RFCs 2630 and 2634 developed by Getronics Government Solutions.
The SFL can be used with the Crypto++ freeware library to implement
RFC 2631.  The SFL provides functions to support use of RFCs 2632 
and 2633.  It has been tested on the RedHat Linux, Windows NT/98/00 
and Solaris 2.7 operating systems.  The SFL maximizes crypto 
algorithm independence.  It has been used with the RSA BSAFE v4.2,
Crypto++ v3.2, Fortezza CI and SPYRUS SPEX/ libraries.  Getronics
has developed the capability for the SFL to use any security
library that provides a PKCS #11 interface.

Getronics has used the SFL to perform a significant amount of S/MIME
v3 interop testing.  Getronics tested the majority of features
in RFCs 2630, 2631 and 2634 as well as some of the features in RFCs
2632 and 2633.  Getronics used the SFL to successfully process and
produce the majority of features documented in "Examples of S/MIME
Messages".  SFL-generated data was included in the Examples-05 I-D
such as: signed receipts, countersignatures, security labels, 
equivalent security labels, mail list information and signing 
certificate attributes.

S/MIME v3 interoperability testing between the SFL and Microsoft 
successfully tested almost all CMS/ESS features using mandatory,
RSA and Fortezza algorithm suites.  For example, successful signed
receipt interoperability testing was performed between the SFL 
and Microsoft.  Getronics verified that the SFL can produce and 
process the majority of features documented in Jim Schaad's 
S/MIME v3 interoperability matrix.  Complete test drivers and test
data are available with the SFL.

Getronics is planning to deliver a new release of the SFL in January
2001 that will include improved PKCS #11 capabilities (tested with 
GemPlus, DataKey and Litronic PKCS #11 libraries).  It will also
include AES content encryption (as per aes-alg-00) and key wrap 
(128, 192, 256 bit keys; based on CMS Triple-DES key wrap algorithm).
It will also include an Enhanced SNACC library that increases 
performance and decreases memory usage.  

John also provided information regarding the Certificate Management 
Library (CML) that is a freeware implementation of X.509 version 3
certification path verification as specified in the 1997 X.509
Recommendation (except Delta CRLs are not implemented).  
The CML: validates X.509 certification paths and CRLs; provides
local certificate/CRL storage functions; and provides remote
directory retrieval via LDAP.  The CML complies with the majority 
of the RFC 2459 requirements.  Getronics is enhancing the CML to
support the 2000 X.509 certificate policy processing requirements.

John also provided information regarding the Getronics-developed 
Access Control Library that provides Rule Based Access Control 
using security labels and authorizations conveyed in either 
X.509 Attribute or public key certificates.  He also discussed the
Getronics Enhanced SNACC ASN.1 library that implements the 
Distinguished Encoding Rules (DER). 

For all of the Getronics freeware libraries, unencumbered source
code is freely available to all from <http://www.GetronicsGov.com/>.  
Getronics freeware can be used as part of applications without 
paying any royalties or licensing fees.  There is a public 
license associated with each Getronics freeware library.

The Internet Mail Consortium (IMC) has established SFL, CML and
Enhanced SNACC mail lists.  John pointed out that SFL/CML/Enhanced
SNACC messages should be sent to the IMC lists and should not be
sent to the IETF mail lists.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Wrap Up - Russ Housley

Russ asked if there were any other issues to discuss.  The meeting
attendees were silent.

Meeting adjourned.




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA11318 for ietf-smime-bks; Thu, 28 Dec 2000 07:40:38 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11308 for <[e-mail]>; Thu, 28 Dec 2000 07:40:36 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <Z2A4PZ00>; Thu, 28 Dec 2000 10:45:43 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: 13 December 2000 S/MIME WG Minutes
Date: Thu, 28 Dec 2000 10:44:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message includes the minutes of the IETF S/MIME Working 
Group (WG) meeting held on 13 December 2000 in San Diego, 
California. Briefing slides will be available from
<ftp://ftp.ietf.org/ietf/smime/>.  These minutes include comments
from the briefing presenters.  Reported by John Pawling.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Introductions - Russ Housley
 
Russ reviewed the agenda as follows.  Nobody commented on the agenda.

Introductions				Russ Housley
Working Group Status			Russ Housley
Interoperability Matrix 		Jim Schaad
CMS and ESS Examples			Paul Hoffman
Security Policies and Labels		Weston Nicolls
Symmetric Key Distribution		Sean Turner
Domain Security (DOMSEC)		Bill Ottaway
X.400 and CMS				Chris Bonatti
Reuse of Content Encryption Keys	Steve Farrell
Advanced Encryption Standard		Jim Schaad
RSA-OAEP and RSA-PSS			John Linn 
RSA as a MUST implement			Blake Ramsdell
E-Signature Formats using CMS		John Ross
E-Signature Formats using XML		Denis Pinkas
S/MIME Freeware Library 		John Pawling
Wrap up					Russ Housley

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Working Group Status - Russ Housley

Russ outlined the strategy for advancing the following RFCs from
Internet Proposed Standards to Internet Draft Standards:
RFC 2630 Cryptographic Message Syntax (CMS), R. Housley, June 1999
RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999
RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the
          Diffie-Hellman Key Agreement Method for S/MIME, 
          R. Zuccherato, March 2000. [Informational]
RFC 2876 Use of the KEA and SKIPJACK Algorithms in CMS, J. Pawling,
          July 2000. [Informational]            
RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS, C. Adams,
	    October 2000

The aforementioned documents must meet the following requirements to
advance to Draft Standards:
1) Meet requirements documented in RFC 2026
2) Stable, mature, and useful specification
3) At least two independent and interoperable implementations
   from different code bases
4) Draft Standards cannot reference Proposed Standard RFCs or 
   Experimental RFCs, so the aforementioned RFCs are blocked
   until the PKIX Certificate and CRL Profile "Son-of-RFC 2459"
   Internet-Draft (I-D) (draft-ietf-pkix-new-part1-03.txt) 
   progresses to Draft Standard. 

Russ stated that Jim Schaad has developed an interoperability matrix
for RFCs 2630 through 2634. The interoperability matrix is posted at
<http://www.imc.org/ietf-smime/interop-matrix.html>.  The matrix 
indicates which features have and have not been successfully tested.
So far, Jim Schaad and Getronics Government Solutions have provided
input to the interoperability matrix.  Jim has provided input
regarding the capabilities of the Microsoft S/MIME v3 implementation.
Getronics has provided input regarding the capabilities of the
S/MIME Freeware Library (SFL) including interoperability testing 
conducted with Microsoft.  

Russ noted that Paul Hoffman (IMC) has offered to coordinate 
interoperability testing and to enhance the "Examples of S/MIME 
Messages" I-D.  He asked that other organizations that have
developed S/MIME v3 capabilities should please participate.

Russ said he would submit that proposal to the S/MIME WG mail list.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Interoperability Matrix - Jim Schaad

Jim discussed the interoperability matrix for RFCs 2630 through 2634.
He has documented the successful completion of two-way interoperability
testing for the following number of clauses in each RFC.  He has not
completely updated the results based on all interop testing performed:

   RFC       Clauses Tested
  =========================
   2630        49 of 96
   2631         0 of 13
   2632        16 of 21
   2633        17 of 61
   2634        27 of 81

More details regarding RFC 2630 testing:
Signed Data - 24 of 25
Enveloped Data - 11 of 25
Digested Data - 0 of 4
Encrypted Data - 0 of 4
Authenticated Data - 0 of 16
Other MUST Implement Requirements - 15 of 25
TOTAL - 49 of 96

More details regarding RFC 2634 testing:
Triple Wrap - 3 of 5
Signed Receipts - 19 of 41
Security Labels - 5 of 11
Equivalent Labels - 0 of 12
Mail List - 0 of 12
TOTAL - 27 of 81

Jim asked for others to submit input to him at [e-mail].

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Examples of S/MIME Messages - Paul Hoffman

Paul stated that he had distributed a new release of the "Examples of
S/MIME Messages" I-D <draft-ietf-smime-examples-05.txt>, November 
2000, that includes additional sample data generated by Getronics
using the SFL.  He stated that the document needs further input and 
testing.  He noted that Jim Schaad is testing all of the samples
included in the document.  John Pawling recommended that a triple-
wrapped sample message should be added to the document.  Jim 
has already generated several triple-wrapped messages and will
provide them to Paul for inclusion in the document. 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Mapping Company Classification Policy to the S/MIME Security Label - 
Weston Nicolls

Weston stated that he had distributed a new release of the 
"Implementing Company Classification Policy with the S/MIME
Security Label" I-D, <draft-ietf-smime-seclabel-02.txt>, October 2000.
He noted that his goal is for the document to become an Informational
RFC.  It provides examples of how the RFC 2634 ESSSecurityLabel 
feature can be used to support an organization's security policy. The
document includes classification policies and example security
labels for the Amoco, Caterpillar and Whirlpool corporations.
It includes an example security category syntax and samples.
It also includes Clearance attribute examples that include a
subject's authorizations.

Russ Housley proposed that Last Call for this document should be
completed by January 2001.  Nobody objected.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Symmetric Key Distribution - Sean Turner

Sean stated that he had distributed a new release of the S/MIME
Symmetric Key Distribution I-D, <draft-ietf-smime-symkeydist-02.txt>, 
October 2000.  Sean noted that Jim Schaad provided significant 
comments to the symkeydist-01 I-D that Sean incorporated into the 
symkeydist-02 I-D.  

Sean stated that two messages were added: GLProvideCert and
GLUpdateCert.  The GLDistributionMethod message was removed.
The GLInfo, GLOwner, and GLMember syntaxes were modified to
include "address" information.  There were many changes made
to more closely align with RFC 2797 Certificate Management
Messages over CMS.  He added text to explain how many and
when rekey messages are distributed.  The rekey defaults 
were fixed.

Sean stated that he still needed to add a conformance clause
and an Abstract Syntax Notation One (ASN.1) module.  He also
needs to verify correctness of RFC 2797 error behavior.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

DOMSEC Draft Discussion - Bill Ottaway

Bill presented a briefing regarding the "Domain Security Services Using
S/MIME" I-D <draft-ietf-smime-domsec-07.txt>, November 2000.  He made
several minor changes as a result of e-mail exchanges with Jim Schaad
on the S/MIME WG mail list.  

He added a section regarding Mail List Agents (MLA) that addresses
the situation in which an MLA will remove the 'domain signature' when
the signature encapsulates a mlExpansionHistory attribute and/or a 
envelopedData type.  He briefed the solution to this problem which
is documented in domsec-07 in Section 5, "Applying a Domain Signature
when Mail List Agents are present".  He stated that the he believes
that the outstanding issues have been resolved and that the DOMSEC 
I-D should be submitted for last call.  

Russ Housley proposed that the DOMSEC document is ready for S/MIME WG
Last Call.  The intent is for this document to be published as an
Experimental RFC.  Russ proposed that the S/MIME WG Last Call should
close on 10 January 2001.  Nobody objected.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

X.400 and CMS - Chris Bonatti

Chris presented a briefing regarding the "Transporting S/MIME Objects
in X.400" I-D, <draft-ietf-smime-x400transport-01.txt> and "Securing
X.400 Content with S/MIME" I-D, <draft-ietf-smime-x400wrap-01.txt> 
both distributed in November 2000.  The x400wrap I-D specifies how
to protect X.400 content with CMS objects.  It is roughly analogous
to RFC 2633 and refers to RFC 2633 when applicable.  It minimizes 
the use of MIME encodings to reduce overhead.  He briefed the 
proposed wrapping strategy.  He discussed the object identifiers
used, MIME heading parameters and detached signature form.  He
has already incorporated comments submitted by Bill Ottaway and
Graeme Lunt.

Chris noted that products generally do not support encapsulating 
content types other than data (such as signed-data or enveloped-data).
Jim Schaad challenged that statement and noted that the Microsoft,
SFL and Peter Gutmann's cryptlib S/MIME v3 implementations do 
support encapsulating content types other than data.

The x400transport I-D specifies how to package CMS objects for 
transport by X.400 Message Transfer Agents (MTA).  It discusses 
the scenario in which the CMS encapsulated content is an RFC 822
MIME message.  It states that the outer MIME wrapper is not generally
necessary in X.400.  It also states that circumstances may exist when
the outer MIME wrapper is desirable such as when a gateway into an 
SMTP transport is part of the architecture.  Chris discussed the
object identifiers used, packaging the CMS object in the X.400 
content and that messages that only contain certificates are not
supported.  He has incorporated comments submitted by Bill Ottaway.

Blake Ramsdell asked about support for messages that only contain
certificates.  Chris responded that messages that only contain
certificates are supported, but they can't be identified as such 
in the wrapper.  

Chris recommended that these I-Ds be placed on the standards track
and asked for feedback from the WG.  Russ Housley and Jeff Schiller
agreed with Chris' recommendation.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Reuse of Content Encryption Keys - Steve Farrell

Steve presented a briefing regarding the "Reuse of CMS Content
Encryption Keys" I-D, <draft-ietf-smime-rcek-00.txt>, September 2000.
The rcek I-D specifies how to set up a shared secret key using 
asymmetric crypto (using EnvelopedData object) and then to re-use 
the content encryption key (CEK) to derive the Key Encryption Key (KEK)
of the next message.  It defines attributes for inclusion in 
EnvelopedData objects that indicates that the CEK is to be re-used 
and the maximum number of times that it can be re-used. 

Steve noted that the I-D specifies a key derivation scheme for the 
re-use of CEKs when the KEK and CEK algorithms must be different. 
The I-D defines a new attribute for this case.  It also documents a
new key derivation function with the property that it only requires
the use of the CEK encryption algorithm.  The function is documented
in the rcek I-D, "Using different CEK and KEK algorithms" section.  
Blake Ramsdell recommended that Steve examine the Public Key 
Cryptography Standard (PKCS) #5 v2 key derivation function as an
alternative to defining a new function.
 
Steve stated that the outstanding issues are how much to specify 
failure cases and the proposed key derivation scheme.  He would like
to do one more version and then submit it to WG last call.  He 
recommended that this I-D be placed on the standards track.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Advanced Encryption Standard (AES) in CMS - Jim Schaad

Jim presented a briefing regarding the "Use of the Advanced 
Encryption Algorithm in CMS" I-D, <draft-ietf-smime-aes-alg-00.txt>,
November 2000.  The aes-alg I-D specifies how to incorporate AES 
into CMS as an additional algorithm for symmetric encryption.  Jim
briefed that the proposed AES parameters are as follows:
  Block Size - Fixed at 16 bytes
  Key Size - 128, 192 or 256 bits
  Proposed MUSTs 128 and 256 bits

Jim noted that the aes-alg I-D does not include an AES key wrap 
algorithm.  He proposes to include 256-bit key wrap algorithm as
the only MUST-implement requirement.  Paul Hoffman asked if Jim
knew the difference in performance between using 256-bit versus 
128-bit keys.  Jim responded that the 256-bit key wrap takes a
longer amount of time, but he didn't know the exact difference.

Regarding key management, the I-D specifies that compliant 
implementations MUST support key transport using the PKCS #1 v2.0
Optimal Asymmetric Encryption Padding (RSA with OAEP) technique. 
It also specifies that compliant implementations MAY support key 
agreement using Ephemeral-Static (E-S) Diffie-Hellman (D-H) with 
modifications.  It also specifies that compliant implementations 
MAY support symmetric key-encryption key management.   

Paul Hoffman commented that he believes that if the S/MIME WG 
specifies the use of both 128- and 256-bit keys, then customers
will always demand 256-bit keys to achieve maximum security.  
He is concerned that the use of 256-bit keys will be a significant
performance hit.  For example, he believes that using 256-bit keys
will drastically impact the performance of secure mail lists.  He 
asked if the WG should consider only specifying the use of 128-bit 
keys.

Jim responded that the certificate processing required to obtain a 
recipient's valid public key far exceeds the performance difference 
between using 128- and 256-bit keys.

An attendee pointed out that companies couldn't sell 128-bit 
implementations because they have already been advertising the use
of larger key sizes with Triple-DES.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

RSA-OAEP and RSA-PSS - John Linn 

John presented a briefing regarding the potential use of RSA-based 
encryption and signature algorithms in conjunction with CMS and
S/MIME.  He stated that many S/MIME products currently use the PKCS
#1 v1.5 (RFC 2313) RSA algorithm that defines encryption and 
signature algorithms using ad hoc padding.  PKCS #1 v1.5 RSA is 
specified as an optional algorithm in RFC 2630 (CMS).  John described
the PKCS #1 v1.5 padding formats and usage (his briefing slides 
provide details).  He then described the Bleichenbacher adaptive 
chosen cipher text attack on PKCS #1 v1.5 encryption padding.  The
attack requires information from hundreds of thousands of decryptions,
indicating whether correct padding resulted.  A successful attack
yields the result of a specific decryption.  It does not yield the
originator's private RSA key.  Countermeasures include protocol-level
means to ensure that information on decryptions is not available to
attackers (constraints on returned information; randomize key, 
continue upon detected pad error) and improved, plaintext-aware 
padding (OAEP) in the cryptographic layer.  More details are 
available in RSA Laboratories Bulletin #7 in
<http://www.rsalabs.com/bulletins>.

PKCS #1 v2.0 (RFC 2437) defends against encryption padding attacks
using OAEP in conjunction with the RSA algorithm.  It can be used
with CMS as described in the "Use of the RSAES-OAEP Key Transport 
Algorithm in CMS" I-D, <draft-ietf-smime-cms-rsaes-oaep-02.txt>.  
John stated that recent theoretical results on strengths and 
assumptions of OAEP proofs have been discussed in the cryptographic
research community, and have reinforced the conclusion that the 
OAEP properties remain strong for use with RSA.  He pointed out 
that OAEP offers attractive properties in a random oracle model. 
It is provably secure and provides a level of security that is 
directly related to the strength of the RSA function.  He also 
highlighted the fact that OAEP is plaintext-aware.  When OAEP is
used, it is impossible to generate valid cipher text without 
knowing the plaintext; thereby, effectively guarding against 
chosen-cipher text attacks.  He briefed the RSAES-OAEP steps
(his briefing slides provide further details).

PKCS #1 v2.1 (draft, September 1999; 2nd draft in preparation) 
defends against potential signature attacks using the Probabilistic
Signature Scheme (PSS).  John noted that like OAEP, PSS offers a
provably secure design.  He briefed the proposed PSS encoding 
operation (his briefing slides provides further details).

John stated that he does not know of any patents regarding the use
of OAEP technique as proposed for S/MIME.  The PSS encoding method
is patent pending by the University of California (UC).  UC agreed
to waive licensing on PSS for signatures with message recovery 
(PSS-R variant) if adopted in an IEEE standard.  

John briefed that OAEP is stable and is being included in the PKCS #1
v2.0, IEEE P1363 and ANSI X9.44 specifications.  He stated that 
standardization of PSS is being pursued in several forums and will 
be included in the IEEE P1363a and PKCS #1 v2.1 specifications.  He 
stated that there is intent in ANSI X9F1 to reopen X9.31 to 
incorporate PSS.  There is a revision in progress to include PSS-R 
in ISO 9796-2.

John proposed that for the short term the S/MIME v3 documents should 
specify PKCS #1 v1.5 as a "MUST implement" requirement and PKCS #1 
v2.0 RSA with OAEP as a "SHOULD implement" requirement.  He recommended
that the WG should specify RSA with OAEP as a "MUST implement" 
requirement for interactive CMS-based applications.  John proposed that
PSS signatures should be adopted as a long term solution along with 
the AES algorithm and new hash functions.

An attendee stated that multiple "MUST implement" requirements may be
tough to support on constrained platforms such as smart cards or palm
devices.

Jim Schaad pointed out that the format of the RSA public key is
identical for PKCS #1 v1.5 and PKCS #1 v2.0 RSA with OAEP.  He asked 
how an application was supposed to determine, based solely on the 
recipient's certificate, which algorithm to use as the key transport 
algorithm when encrypting data.  This would be a problem if both 
algorithms are "MUST implement" requirements.  Jim asked if RSA has
considered defining a new object identifier to identify public keys 
for subjects that use PKCS #1 v2.0 RSA.  Russ Housley replied that 
RSA decided to use the same object identifier to support both
algorithms. 

John Pawling pointed out that the SMIMECapabilities attribute could 
be used to identify an entity's preferred key management algorithm.
Jim replied that many products are not capable of processing the 
SMIMECapabilities attribute.  He also stated that an application may 
support multiple key management algorithms, so there is a question
regarding which algorithms will be advertised in the SMIMECapabilities
attribute.  Russ Housley stated that applications should offer a menu
that allows the user to select a combination of algorithms.  He
suggested that this topic should be discussed further on the S/MIME
WG mail list.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

RSA As a Must Implement - Blake Ramsdell

Blake proposed that RFC 2630 be changed to specify the PKCS #1 v1.5
RSA public key algorithm as the "MUST implement" key management and 
signature algorithm since the RSA patent has expired.  

Blake stated that the majority of the July 2000 S/MIME WG meeting 
attendees stated their preference that both the PKCS #1 v1.5 RSA and 
DSA algorithms be the "MUST implement" signature algorithms.  He
stated that messages sent to the S/MIME WG mail list questioned if
vendors would actually implement both algorithms if both were 
specified as "MUST implement".  Others asked if there was a valid set
of requirements justifying that both algorithms be specified as "MUST
implement".  Blake stated that PKCS #1 v1.5 RSA algorithm should be
the "MUST implement" signature algorithm and that DSA should be the 
"MAY implement"  signature algorithm.  Blake said that PKCS #1 v2.0 
RSA with OAEP should be discussed.  

Paul Hoffman raised the issue of the definition of "MUST implement"
requirements.  He described three definitions that various folks 
support: 1) describe current usage; 2) force a specific future 
solution; and 3) provide optimal security solution.  He recommended
that those that are interested in this issue should conduct a 
sidebar meeting to write a position paper that would then be sent
to the S/MIME WG mail list.

Russ Housley stated that the three definitions described by Paul 
point to different algorithm sets.  He stated that he would talk to
the security area director about this issue.  He was surprised by 
the characterization of the arguments.

Russ stated that if PKCS #1 v1.5 RSA is approved as the "MUST 
implement" requirement, then the S/MIME WG must document the 
safeguards that should be taken.

Russ conducted a straw poll of the meeting attendees to obtain 
their opinion regarding the following options for the "MUST
implement" signature algorithm: 
1) PKCS#1 v1.5 RSA 
2) DSA
3) Both
The meeting attendees were evenly divided between options 1 and 3.
Only one attendee voted for the "DSA" option.

Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the following options for the "MUST
implement" key management algorithm: 
1) PKCS#1 v1.5 RSA
2) PKCS#1 v2.0 RSA with OAEP 
3) E-S D-H
The meeting attendees were evenly divided between options 1 and 2.
Only one attendee voted for the "E-S D-H" option.

Russ conducted a straw poll of the meeting attendees to obtain
their opinion regarding the definition of the "MUST
implement" requirement: 
1) force a specific future solution
2) describe current usage
3) provide optimal security solution. 
Not many attendees voted in this straw poll.  Two attendees voted 
for option 1, four voted for option 2 and one voted for option 3.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Electronic Signature Formats - John Ross

John briefed regarding the "Electronic Signature Formats for long term
electronic signatures" I-D.  The esformats I-D is based on the European
Telecommunications Standardization Institute (ETSI) Electronic Signature
Infrastructure Standardization and defines a process to provide proof of
the validity of a signature to be used if repudiation is attempted.  The 
esformats-02.txt was based on ETSI ES 201 733.  The new version, 
esformats-03.txt, is based on ETSI TS 101 733.  All of  the versions 
are based on RFC 2630.  John stated that the changes in the esformats-03
I-D include extensions to the previous version including: verifier
conformance options (Timestamping, Secure records); Signature policy 
options (Explicit by object identifier, Implied by signed content/
signature environment); and Content encoding indication (Content hints).  

John proposed that esformats-03 I-D is ready to become an Informational
RFC.  The planned work is: ETSI Implementation Trials; XML signature
formats; and more work on signature policies.

John then briefed regarding the "Electronic Signature Policies" I-D,
<draft-ietf-smime-espolicies-00.txt> that defines signature policies
for electronic signatures. He proposed that the espolicies-00 I-D 
is ready to become an Experimental RFC. 

Russ Housley proposed that the Electronic Signature Formats document
is ready for S/MIME WG Last Call.  The intent is for this document to
be published as an Informational RFC.  Russ proposed that the S/MIME 
WG Last Call should close on 10 January 2001.  Nobody objected.

Russ Housley proposed that the Signature Policies document is ready
for S/MIME WG Last Call.  The intent is for this document to be 
published as an Experimental RFC.  Russ proposed that the S/MIME WG 
Last Call will close on 10 January 2001.  Nobody objected.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

E-Signature Formats using XML - Denis Pinkas

Denis briefed that ETSI is defining new XML types to contain 
equivalent electronic signatures information to those ASN.1 types 
defined in the esformats I-D.  These new XML types would include 
additions to the Signature XML element as defined by the W3C/IETF.
He pointed out that there is not a one-to-one mapping from ASN.1
to XML because some of the ASN.1 structures (such as the 
MessageDigest signed attribute) have been incorporated into the XML
digital signature core syntax.  Denis listed the new XML types
defined (his briefing slides provide further details).  He stated 
that new encapsulating XML type(s) need to contain ASN.1-encoded 
data generated by PKI agents such as time stamp agents that 
implement ASN.1 protocols.  He discussed several proposals for
accomplishing this goal.  

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Freeware Library (SFL) - John Pawling

John briefed regarding the SFL which is a freeware implementation
of RFCs 2630 and 2634 developed by Getronics Government Solutions.
The SFL can be used with the Crypto++ freeware library to implement
RFC 2631.  The SFL provides functions to support use of RFCs 2632 
and 2633.  It has been tested on the RedHat Linux, Windows NT/98/00 
and Solaris 2.7 operating systems.  The SFL maximizes crypto 
algorithm independence.  It has been used with the RSA BSAFE v4.2,
Crypto++ v3.2, Fortezza CI and SPYRUS SPEX/ libraries.  Getronics
has developed the capability for the SFL to use any security
library that provides a PKCS #11 interface.

Getronics has used the SFL to perform a significant amount of S/MIME
v3 interop testing.  Getronics tested the majority of features
in RFCs 2630, 2631 and 2634 as well as some of the features in RFCs
2632 and 2633.  Getronics used the SFL to successfully process and
produce the majority of features documented in "Examples of S/MIME
Messages".  SFL-generated data was included in the Examples-05 I-D
such as: signed receipts, countersignatures, security labels, 
equivalent security labels, mail list information and signing 
certificate attributes.

S/MIME v3 interoperability testing between the SFL and Microsoft 
successfully tested almost all CMS/ESS features using mandatory,
RSA and Fortezza algorithm suites.  For example, successful signed
receipt interoperability testing was performed between the SFL 
and Microsoft.  Getronics verified that the SFL can produce and 
process the majority of features documented in Jim Schaad's 
S/MIME v3 interoperability matrix.  Complete test drivers and test
data are available with the SFL.

Getronics is planning to deliver a new release of the SFL in January
2001 that will include improved PKCS #11 capabilities (tested with 
GemPlus, DataKey and Litronic PKCS #11 libraries).  It will also
include AES content encryption (as per aes-alg-00) and key wrap 
(128, 192, 256 bit keys; based on CMS Triple-DES key wrap algorithm).
It will also include an Enhanced SNACC library that increases 
performance and decreases memory usage.  

John also provided information regarding the Certificate Management 
Library (CML) that is a freeware implementation of X.509 version 3
certification path verification as specified in the 1997 X.509
Recommendation (except Delta CRLs are not implemented).  
The CML: validates X.509 certification paths and CRLs; provides
local certificate/CRL storage functions; and provides remote
directory retrieval via LDAP.  The CML complies with the majority 
of the RFC 2459 requirements.  Getronics is enhancing the CML to
support the 2000 X.509 certificate policy processing requirements.

John also provided information regarding the Getronics-developed 
Access Control Library that provides Rule Based Access Control 
using security labels and authorizations conveyed in either 
X.509 Attribute or public key certificates.  He also discussed the
Getronics Enhanced SNACC ASN.1 library that implements the 
Distinguished Encoding Rules (DER). 

For all of the Getronics freeware libraries, unencumbered source
code is freely available to all from <http://www.GetronicsGov.com/>.  
Getronics freeware can be used as part of applications without 
paying any royalties or licensing fees.  There is a public 
license associated with each Getronics freeware library.

The Internet Mail Consortium (IMC) has established SFL, CML and
Enhanced SNACC mail lists.  John pointed out that SFL/CML/Enhanced
SNACC messages should be sent to the IMC lists and should not be
sent to the IETF mail lists.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Wrap Up - Russ Housley

Russ asked if there were any other issues to discuss.  The meeting
attendees were silent.

Meeting adjourned.



Received: by ns.secondary.com (8.9.3/8.9.3) id IAA03320 for ietf-smime-bks; Fri, 22 Dec 2000 08:30:42 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA03313 for <[e-mail]>; Fri, 22 Dec 2000 08:30:40 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA25594 for <[e-mail]>; Fri, 22 Dec 2000 08:33:34 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 22 Dec 2000 11:34:43 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Interoperability Testing
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Implementors:

Jim Schaad has developed an interoperability matrix for RFCs 2630 through 
2634. The interoperability matrix is posted at 
http://www.imc.org/ietf-smime/interop-matrix.html.  The matrix presently 
includes features which have been successfully tested.  So far, Jim Schaad 
(using the Microsoft implementation) and Getronics Government Solutions 
(using the S/MIME Freeware Library) have provided input to the 
interoperability matrix.  I solicit input from other implementors.  Please 
provide the information to Jim ([e-mail])

Paul Hoffman has offered to coordinate interoperability testing.  Paul 
hopes that such testing will yield additional messages to be included in 
the "Examples of S/MIME
Messages" I-D.  Please contact Paul ([e-mail]) if you are an 
implementor and you are interested in participating in interoperability 
testing or you are interested in providing messages for the I-D.

Russ



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA00659 for ietf-smime-bks; Fri, 22 Dec 2000 07:59:51 -0800 (PST)
Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00655 for <[e-mail]>; Fri, 22 Dec 2000 07:59:50 -0800 (PST)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA02015; Fri, 22 Dec 2000 07:58:42 -0800 (PST)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <ZG65C048>; Fri, 22 Dec 2000 08:03:01 -0800
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Ozan Gonenc'" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: Does Hotmail support S/MIME?
Date: Fri, 22 Dec 2000 08:02:52 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I believe this is a valid question for this mailing group.  
> It would be nice
> to know where web mail fits into the S/MIME picture (if not, will it
> ever?...) and if there will be any future use of encryption 
> services for
> this type of internet messaging.  At least I myself am interested.

S/MIME is not incompatible with Web mail. It is purely an implementation
issue for the Web mail providers.

It is not a topic for this group unless Web mail providers discover
some specific feature that is essential or highly desirable for
Web mail support and want to raise it.

	Phill 


Received: by ns.secondary.com (8.9.3/8.9.3) id GAA22270 for ietf-smime-bks; Fri, 22 Dec 2000 06:13:55 -0800 (PST)
Received: from luc.ab.org (mail.ab.org [209.112.11.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22266 for <[e-mail]>; Fri, 22 Dec 2000 06:13:53 -0800 (PST)
Received: from D00425 ([206.222.76.33]) by luc.ab.org (Netscape Messaging Server 3.6)  with SMTP id AAAFA105; Fri, 22 Dec 2000 09:23:38 -0500
From: "Ozan Gonenc" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Does Hotmail support S/MIME?
Date: Fri, 22 Dec 2000 09:15:13 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I believe this is a valid question for this mailing group.  It would be nice
to know where web mail fits into the S/MIME picture (if not, will it
ever?...) and if there will be any future use of encryption services for
this type of internet messaging.  At least I myself am interested.

______________________________

Ozan Gonenc
IT Security Consultant

AEPOS Technologies Corporation
Tel: [phone]
Fax: [phone]
www.aepos.com

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> [e-mail]
> Sent: December 21, 2000 23:35
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Does Hotmail support S/MIME?
>
>
> Hi,
>
> 	I think you should post this email to Hotmail support,
> this mailing list are use for discuss technical questions about
> S/MIME... :-)
>
>
>
> > From: "Wai Shang Ye" <[e-mail]>
> > Date: Fri, 22 Dec 2000 10:50:00 +0800
> > Content-Type: text/plain;
> > 	charset="iso-8859-1"
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> > Sender: [e-mail]
> > Precedence: bulk
> > List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
> > List-ID: <ietf-smime.imc.org>
> > List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
> > X-Status:
> > X-Keywords:
> > X-UID: 4
> >
> > Newbie here. Does Hotmail support S/MIME? Thx in advance.
> >
>
> --
> Best Regards,
> Shell Hung
>
> emacs is the best !
>



Received: by ns.secondary.com (8.9.3/8.9.3) id UAA05057 for ietf-smime-bks; Thu, 21 Dec 2000 20:26:41 -0800 (PST)
Received: from linux.org.hk ([202.181.234.40]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA05052 for <[e-mail]>; Thu, 21 Dec 2000 20:26:29 -0800 (PST)
Received: (from shellhung@localhost) by linux.org.hk (8.9.3/8.9.3) id MAA19358; Fri, 22 Dec 2000 12:34:37 +0800
Date: Fri, 22 Dec 2000 12:34:37 +0800
Message-Id: <[e-mail]>
X-Authentication-Warning: www.linux.org.hk: shellhung set sender to [e-mail] using -f
From: [e-mail], Shell <[e-mail]>
To: [e-mail]
CC: [e-mail]
In-reply-to: <039701c06bc1$e0e50720$[e-mail]> ([e-mail])
Subject: Re: Does Hotmail support S/MIME?
References:  <039701c06bc1$e0e50720$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

	I think you should post this email to Hotmail support, 
this mailing list are use for discuss technical questions about
S/MIME... :-)



> From: "Wai Shang Ye" <[e-mail]>
> Date: Fri, 22 Dec 2000 10:50:00 +0800
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> Sender: [e-mail]
> Precedence: bulk
> List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
> List-ID: <ietf-smime.imc.org>
> List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
> X-Status: 
> X-Keywords:                  
> X-UID: 4
> 
> Newbie here. Does Hotmail support S/MIME? Thx in advance.
> 

-- 
Best Regards,
Shell Hung

emacs is the best !



Received: by ns.secondary.com (8.9.3/8.9.3) id SAA03646 for ietf-smime-bks; Thu, 21 Dec 2000 18:58:08 -0800 (PST)
Received: from ew.mimos.my (ew.mimos.my [192.228.129.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA03641 for <[e-mail]>; Thu, 21 Dec 2000 18:58:06 -0800 (PST)
From: [e-mail]
Received: from SYWAI (ivylps.mimos.my [192.228.133.34]) by ew.mimos.my (8.9.3/8.9.3) with SMTP id LAA00221 for <[e-mail]>; Fri, 22 Dec 2000 11:00:59 +0800 (MYT)
Message-ID: <03bb01c06bc4$48b72ca0$[e-mail]>
To: "SMIME - IETF" <[e-mail]>
Subject: Can't read mail
Date: Fri, 22 Dec 2000 11:07:14 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I forwarded the mail inside my Hotmail inbox to my another office account. I
got this msg: This is a multipart MIME msg ..... I got to read nothing.
Actually what does it mean? What should I do to read that mail? Something to
do with S/MIIME?

Kindly help, thx



Received: by ns.secondary.com (8.9.3/8.9.3) id SAA03371 for ietf-smime-bks; Thu, 21 Dec 2000 18:40:53 -0800 (PST)
Received: from ew.mimos.my (ew.mimos.my [192.228.129.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA03367 for <[e-mail]>; Thu, 21 Dec 2000 18:40:51 -0800 (PST)
Received: from SYWAI (ivylps.mimos.my [192.228.133.34]) by ew.mimos.my (8.9.3/8.9.3) with SMTP id KAA21848 for <[e-mail]>; Fri, 22 Dec 2000 10:43:43 +0800 (MYT)
Message-ID: <039701c06bc1$e0e50720$[e-mail]>
From: "Wai Shang Ye" <[e-mail]>
To: <[e-mail]>
Subject: Does Hotmail support S/MIME?
Date: Fri, 22 Dec 2000 10:50:00 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Newbie here. Does Hotmail support S/MIME? Thx in advance.



Received: by ns.secondary.com (8.9.3/8.9.3) id NAA25016 for ietf-smime-bks; Thu, 21 Dec 2000 13:31:26 -0800 (PST)
Received: from mp.a-phys.eng.osaka-cu.ac.jp ([160.193.160.180]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA24986; Thu, 21 Dec 2000 13:31:11 -0800 (PST)
From: [e-mail]
Received: by mp.a-phys.eng.osaka-cu.ac.jp id AA31402; Fri, 22 Dec 2000 06:24:25 +0900
Date: 21 Dec 00 1:39:28 PM
Message-Id: <7T79fg019847isE1p0>
Subject: Improve your stepfamily life
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Apparently-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Does your stepfamily life resemble a soap opera more than it does the Brady
Bunch?

The Stepfamily Association of America invites you to participate in THE
NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans
Marriott Hotel.

This is an opportunity, designed by knowledgeable professionals, in
stepfamilies themselves, to help you:
* Make your remarriage a success
* Create bonds with your stepchildren
* Help your children adjust emotionally
* Manage money matters unique to your family
* Get more help from legal, financial, psychological advisors
* Overcome stepfather and stepmother stereotypes
* Elicit cooperation from your children's schools
* Bring more harmony into family life

Complete conference details at http://www.edupr.com
REGISTER ONLINE!

Attend, and also enjoy Mardi Gras week in New Orleans!

Special discounts for couples, students, groups.

HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND
AIRLINE SEATS FILL Special rates for conference attendees. Visit
http://www.edupr.com for discounts. Childcare available through a bonded
local service.

Up to 17 professional development credits available if you are an 			
educator, clinician, financial planner, social worker.

Questions? Email [e-mail]

If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA23457 for ietf-smime-bks; Wed, 20 Dec 2000 11:48:37 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23452 for <[e-mail]>; Wed, 20 Dec 2000 11:48:36 -0800 (PST)
Received: from ieca.com (mva-aa-112.capu.net [207.226.159.112]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id OAA17953; Wed, 20 Dec 2000 14:51:44 -0500
Message-ID: <[e-mail]>
Date: Wed, 20 Dec 2000 14:51:39 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Proposed amendment to the Compressed data Content type for S/MIME
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:

> A number of users of my code are doing streaming S/MIME (email gateways and the
> like) where they really have no idea how large a message is, and where they
> can't afford to buffer more than a few hundred kB (I'm not trying to say here
> that everyone should do X just because I see a need for it, just pointing out
> that there is real use of streaming going on out there, in fact I've made
> several changes to my code in the last year or so specifically to handle one-
> pass streaming operations).  Perhaps the dominant scenario for end-user-based
> S/MIME is all-at-once send/receive, but for things like S/MIME gateways I'd say
> there's a fair amount of streaming with one-pass processing constraints because
> the average gateway can't handle the 1000 20MB Powerpoint files the salesdroids
> just sent out in main memory.
>

Peter,

    I take all this at face value.  I like the term "salesdroids".


>
> Having said that I don't want to discount the option, but it'd need some
> thought as to how you're going to manage interoperability - the receiver would
> need to publish some sort of S/MIME capability info to say "I need to be sent
> uncompressed size info".
>

    The way I imagined this, it would not necessarily be an "I need", but an "I can
use".  The receiving agent can always reconstruct this information.  It just takes
time.

Bertrand,

    Can you elaborate the scenario for how this would be used?  Is this something
that your receiving agent would NEED, or just an advisory field?  Have you done any
implementation or testing with this field?


>
> >The real problem with this is the timing.  I thought this completed WG Last
> >Call back in November.  Can we still influence this?
>
> Not at the current state AFAIK and it doesn't seem like a terribly critical
> change, however it shouldn't be too hard to do a short RFC which defines an
> additional OID for foo-with-size-info if there's a real demand for it and if
> the potential interop issues can be resolved (note that the current draft is
> just a framework for doing compression with one standardised algorithm defined
> to provide interoperability, there's nothing to stop anyone else from defining
> their own algorithms and dropping those in alongside the existing one just like
> you can do for the other content types).
>

    This seems like an awful lot of bother for a piece of advisory information to
me.  However, this is an interesting thought.  If I understand you correctly, this
means packing the uncompressed size value into the 'eContent' field after the
compression.  It strikes me that you could also pack such data into the algorithm
ID parameters.  Either way, I think these complicate interoperability.  Instead of
an option field that can be easily ignored by receiving implementations that don't
choose to support it, identifying these mechanisms through the algorithm OID
creates a separate algorithm space that has to be supported to achieve the same
level of interoperability even if the parameter is ignored.

Chris





Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02519 for ietf-smime-bks; Mon, 18 Dec 2000 15:19:22 -0800 (PST)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02515 for <[e-mail]>; Mon, 18 Dec 2000 15:19:19 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id MAA10000; Tue, 19 Dec 2000 12:22:18 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97718173809795>; Tue, 19 Dec 2000 12:22:18 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Proposed amendment to the Compressed data Content type for S/MIME
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 19 Dec 2000 12:22:18 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Bonatti, Chris" <[e-mail]> writes:

>I have a bit of a soft spot for "useful options".  If they aren't implemented,
>they'll die on their own.  We never innovate if we don't strive, and all that.
>A lot of proprietary compression structures DO store this value, so it seems
>like there is some weight on the side of it being practical.  I don't think
>there are actually that many streaming scenarios in S/MIME.  The dominant
>scenario is still that of e-mail.

A number of users of my code are doing streaming S/MIME (email gateways and the
like) where they really have no idea how large a message is, and where they
can't afford to buffer more than a few hundred kB (I'm not trying to say here
that everyone should do X just because I see a need for it, just pointing out
that there is real use of streaming going on out there, in fact I've made
several changes to my code in the last year or so specifically to handle one-
pass streaming operations).  Perhaps the dominant scenario for end-user-based
S/MIME is all-at-once send/receive, but for things like S/MIME gateways I'd say
there's a fair amount of streaming with one-pass processing constraints because
the average gateway can't handle the 1000 20MB Powerpoint files the salesdroids
just sent out in main memory.

Having said that I don't want to discount the option, but it'd need some
thought as to how you're going to manage interoperability - the receiver would
need to publish some sort of S/MIME capability info to say "I need to be sent
uncompressed size info".

>The real problem with this is the timing.  I thought this completed WG Last
>Call back in November.  Can we still influence this?

Not at the current state AFAIK and it doesn't seem like a terribly critical
change, however it shouldn't be too hard to do a short RFC which defines an
additional OID for foo-with-size-info if there's a real demand for it and if
the potential interop issues can be resolved (note that the current draft is
just a framework for doing compression with one standardised algorithm defined
to provide interoperability, there's nothing to stop anyone else from defining
their own algorithms and dropping those in alongside the existing one just like
you can do for the other content types).

Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id MAA25577 for ietf-smime-bks; Mon, 18 Dec 2000 12:21:02 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25573 for <[e-mail]>; Mon, 18 Dec 2000 12:21:00 -0800 (PST)
Received: from ieca.com (mva-aa-108.capu.net [207.226.159.108]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id PAA04559; Mon, 18 Dec 2000 15:23:55 -0500
Message-ID: <[e-mail]>
Date: Mon, 18 Dec 2000 15:23:51 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Proposed amendment to the Compressed data Content type for S/MIME
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:

> The problem which arises in conjunction with that is that if you can't
> guarantee there'll be an uncompressed size indicator present, you can't build
> an application which requires it because it's then guaranteed to break if it
> isn't there.  A corollary to that is that your application must be able to
> function without the uncompressed-size-indicator, in which case its presence
> becomes unnecessary.
>

Peter,

    Of course, since the 'CompressedData' wrapper itself is an option I guess we
needn't bother with the whole draft.   ;-)   Sorry, I couldn't resist.

    I have a bit of a soft spot for "useful options".  If they aren't implemented,
they'll die on their own.  We never innovate if we don't strive, and all that.  A
lot of proprietary compression structures DO store this value, so it seems like
there is some weight on the side of it being practical.  I don't think there are
actually that many streaming scenarios in S/MIME.  The dominant scenario is still
that of e-mail.

    The real problem with this is the timing.  I thought this completed WG Last
Call back in November.  Can we still influence this?

Chris B.







Received: by ns.secondary.com (8.9.3/8.9.3) id IAA10530 for ietf-smime-bks; Mon, 18 Dec 2000 08:13:08 -0800 (PST)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10524 for <[e-mail]>; Mon, 18 Dec 2000 08:13:06 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA32612; Tue, 19 Dec 2000 05:15:41 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97715614105328>; Tue, 19 Dec 2000 05:15:41 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re:  Proposed amendment to the Compressed data Content type for S/MIME
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 19 Dec 2000 05:15:41 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Bertrand BOUTELOUP" <[e-mail]> writes:

>Can we add as an optional field the "SizeUncomp" field in the The compressed-
>data type. SizeUncomp will be the size of non compressed data.

I can see some problems with this, it assumes you know in advance how long the
data stream will be which isn't always the case.  Adding an INTEGER OPTIONAL
somewhere is feasible, but you can't mandate its use because it'll cause
problems for any streaming implementations (for example one of the uses I
mentioned ages ago was for securing EDI messages which can be ~100MB long,
there's no way to tell in advance just how long they'll be because the systems
processing the data can't afford to spool 100MB of data to disk while they wait
for the end to appear).

The problem which arises in conjunction with that is that if you can't
guarantee there'll be an uncompressed size indicator present, you can't build
an application which requires it because it's then guaranteed to break if it
isn't there.  A corollary to that is that your application must be able to
function without the uncompressed-size-indicator, in which case its presence
becomes unnecessary.

Peter.



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA28303 for ietf-smime-bks; Thu, 14 Dec 2000 22:08:24 -0800 (PST)
Received: from dns.miharujoho.co.jp ([210.163.92.146]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA28296 for <[e-mail]>; Thu, 14 Dec 2000 22:08:12 -0800 (PST)
Received: from host (unverified [216.214.173.192]) by dns.miharujoho.co.jp (EMWAC SMTPRS 0.83) with SMTP id <[e-mail]>; Fri, 15 Dec 2000 15:01:43 +0900
Message-ID: <[e-mail]>
From: "Darren Hill" <[e-mail]>
Subject: Your Listing #3FB9
To: open39d
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Thu, 14 Dec 2000 23:38:42 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

***** This is an HTML Message ! *****


------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4=2E0
 transitional//en">
 <html>
 <head>
    
    <title>Executive Guild Membership
 ApplicationResponse-O-Matic Form</title>
 </head>
 <body text=3D"#808080" bgcolor=3D"#F6F6CC"
 link=3D"#800040" vlink=3D"#FF0000" alink=3D"#8080C0">
 <p><font color=3D"#000000">Dear Professional,<br>
 <br>
 You have been selected as a potential candidate for biographical<br>
 inclusion in the 2000 - 2001 Edition of the International Executive<br>
 Guild Registry=2E<br>
 <br>
 Please accept our congratulations for this coveted honor=2E<br>
 <br>
 As this edition is so important in view of the new millennium, the<br>
 International Executive Guild Registry will be published in two<br>
 different formats; the searchable CD-ROM and the Online Registry=2E<br>
 <br>
 Since inclusion can be considered recognition of your career position<br>=

 and professionalism, each candidate is evaluated in keeping with high<br>=

 standards of individual achievement=2E In light of this, the Internationa=
l<br>
 Executive Guild thinks that you may make an interesting biographical<br>
 subject=2E<br>
 <br>
 We look forward to your inclusion and appearance in the International<br>=

 Executive Guild's Registry=2E Best wishes for your continued success=2E<b=
r>
 <br>
 International Executive Guild<br>
 Listing Dept=2E<br>
 <br>
 P=2ES=2E There is no cost or obligation to be included in the Internation=
al<br>
 Executive Guild Registry=2E For accuracy and publication purposes, we ask=
<br>
 you to fill in the brief bit of information in the registration form<br>
 below=2E</font></p>
 <p>
 <hr WIDTH=3D"100%">
 <p align=3D"center"><b><i><font color=3D"#000000">If you
 wish to be removed from our list, please submit
 your request</font></i></b>
 <br><b><i><font face=3D"Times New
 Roman,Times"><font color=3D"#000000">at the
 bottom of this email=2E</font></font></i></b>
 </p>
 <hr WIDTH=3D"100%">
 <table WIDTH=3D"695" >
 <caption><script language=3D"JavaScript">
 
 <!--
 function validate_form() {
   validity =3D true; // assume valid
   if (!check_empty(document=2Eform=2Ebusphone=2Evalue))
         { validity =3D false; alert('Day Time
 Phone field is empty!'); }
     if (validity)
         alert ("Thank you for your registration!
 "
                 + "Your form is now being passed
 to your browser's "
                 + "Mail Delivery Sub-System for
 NORMAL"
                 + " NON-ENCRYPTED email
 delivery=2E"
                 + "  All email addresses are
 removed from our system"
                 + " upon registration=2E  Please
 click OK to proceed");
   return validity;
 }

 function check_empty(text) {
   return (text=2Elength > 0); // returns false if
 empty
 }
 
 // -->
 
 </script>
 
 
 <!-- CHANGE EMAIL ADDRESS IN ACTION OF FORM -->
 
 <form name=3D"form"
  method=3D"post"
  action=3D"mailto:rkt52@verizonmail=2Ecom?SUBJECT=3DInternet Lead"
  enctype=3D"text/plain"
  
 <tr>
 <td></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2">
 <center><b><i><font color=3D"#000000"><font
 size=3D+3>International Executive Guild</font></font></i></b>
 <br><b><font color=3D"#000000"><font
 size=3D+2>Registration Form</font></font></b>
 <br><b><font color=3D"#000000">(US and Canada
 Only)</font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 </td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2"><i><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D+0>Please
 fill out this form if you would like to be
 included on The International
 Executive Guild, For accuracy and
 publication purposes, please
 complete and send this form at the earliest
 opportunity=2E There is </font>no
 charge or obligation<font size=3D+0> to be listed
 on The International Executive Guild=2E</font></font></font></i>
 <br>
 <hr WIDTH=3D"100%"></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Name</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"Name"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Company</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Company"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Title</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Title"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Address</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Address"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>City</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"City"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>State
 or Province</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"12" maxlength=3D"50" name=3D"State"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Country</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><select
 NAME=3D"Country" Size=3D"1"><option SELECTED><font
 color=3D"#000000">USA<option
 SELECTED>Canada</font></select></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>ZIP/Postal
 Code</font></font></font></b></td>
 
 <td ALIGN=3DLEFT VALIGN=3DCENTER WIDTH=3D"300"><input
 type=3D"text" value size=3D"12" maxlength=3D"50"
 name=3D"Zip"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Day
 Time Telephone</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"22" maxlength=3D"50"
 name=3D"busphone"></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-1>Home
 Phone</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"22"
 maxlength=3D"50" name=3D"homephone"><b><font
 color=3D"#000000"><font size=3D-2>(Not
 To Be Published)</font></font></b></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Email</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"50"
 maxlength=3D"100" name=3D"Email"></td>
 </tr>
 
 <tr>
 <td></td>
 
 <td></td>
 </tr>
 </table>
 
 <center>
 <p>
 <hr WIDTH=3D"100%"><b><font
 face=3D"ARIAL,HELVETICA"><font
 color=3D"#000000"><font size=3D-1>TO
 HELP US IN CONSIDERING YOUR APPLICATION, PLEASE
 TELL US A LITTLE ABOUT
 YOURSELF=2E=2E=2E</font></font></font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 
 <center><table WIDTH=3D"81%" >
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Business</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value
 size=3D"50" maxlength=3D"200"
 name=3D"business"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Financial
 Svcs, Banking, Computer Hardware, Software, Professional Svcs,
 Chemicals,
 Apparel, Aerospace, Food, Government, Utility,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Type
 of Organization</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"Orgtype"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(M=
fg,
 Dist/Wholesaler, Retailer, Law Firm,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Investment
 Bank, Commercial Bank, University,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Financial
 Consultants, Ad Agency, Contractor, Broker,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP WIDTH=3D"300">
 <div align=3Dright><b><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Your
 Business Expertise</font></font></font></b></div>
 </td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"expertise"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Corp=2EMgmt,
 Marketing, Civil Engineering,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-=
1>Tax
 
 Law, Nuclear Physics, Database Development, Operations, Pathologist,
 Mortgage
 Banking, etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Major
 Product Line</font></font></font></b></td>

 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"product"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Integrated
 Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components,
 
 Snack Foods, etc=2E)</font></font></font></td>
 </tr>
 </table></center>
 
 <center>
 <p><input NAME=3D"submit" TYPE=3D"submit" VALUE=3D" Submit By E-Mail "><i=
nput
 NAME=3D"reset" TYPE=3D"reset" VALUE=3D" Clear Form "></form>
 <br><b><font color=3D"#000000"><font size=3D-1>Note: Submitting this form=

 will
 be made by email, not by use of&nbsp; www=2E&nbsp; Confirmation of its de=
livery
 is made by browsing your outgoing mail=2E</font></font></b>
 <br>
 <hr WIDTH=3D"100%"><b><i><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Thank
 you for filling in this form, we will contact you with more
 information=2E</font></font></font></i></b>
 <br>
 <hr WIDTH=3D"100%">
 <br><b><font size=3D+1>List
 Removal</font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:gmmq@charmedmail=2Ecom?subject=3Dremove">Click
 Here</a></font></font></b></center>
 
 </body>
 </html>

------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--





Received: by ns.secondary.com (8.9.3/8.9.3) id VAA27120 for ietf-smime-bks; Thu, 14 Dec 2000 21:13:16 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA27107 for <[e-mail]>; Thu, 14 Dec 2000 21:13:13 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com (ietf.207.137.71.200.tx.verio.net [207.137.71.200]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id VAA00650; Thu, 14 Dec 2000 21:15:30 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 14 Dec 2000 19:14:18 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: WG Last Call: draft-ietf-smime-espolicies-00.txt
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

S/MIME WG Members:

The Signature Policies document is ready for S/MIME WG Last Call.  The 
intent is for this document to be published as an Experimental RFC.  S/MIME 
WG Last Call will close on 10 January 2001.

Russ 



Received: by ns.secondary.com (8.9.3/8.9.3) id VAA27122 for ietf-smime-bks; Thu, 14 Dec 2000 21:13:16 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA27115 for <[e-mail]>; Thu, 14 Dec 2000 21:13:15 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com (ietf.207.137.71.200.tx.verio.net [207.137.71.200]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id VAA00656; Thu, 14 Dec 2000 21:15:31 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 14 Dec 2000 19:14:59 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: WG Last Call: draft-ietf-smime-domsec-07.txt
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

S/MIME WG Members:

The DOMSEC document is ready for S/MIME WG Last Call.  The intent is for 
this document to be published as an Experimental RFC.  S/MIME WG Last Call 
will close on 10 January 2001.

Russ 



Received: by ns.secondary.com (8.9.3/8.9.3) id VAA27121 for ietf-smime-bks; Thu, 14 Dec 2000 21:13:16 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA27111 for <[e-mail]>; Thu, 14 Dec 2000 21:13:14 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com (ietf.207.137.71.200.tx.verio.net [207.137.71.200]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id VAA00653; Thu, 14 Dec 2000 21:15:31 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 14 Dec 2000 19:17:52 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: WG Last Call: draft-ietf-smime-esformats-03.txt
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

S/MIME WG Members:

The Electronic Signature Formats document is ready for S/MIME WG Last 
Call.  The intent is for this document to be published as an Informational 
RFC.  S/MIME WG Last Call will close on 10 January 2001.

Russ 



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA04518 for ietf-smime-bks; Thu, 14 Dec 2000 10:01:19 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA02888; Thu, 14 Dec 2000 09:52:24 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 14 Dec 2000 10:54:38 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Thu, 14 Dec 2000 10:54:34 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: New Time and Space Based Key Size Equivalents for RSA and Diffie-Hellman
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_2C77224E.31502339"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_2C77224E.31502339
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Francois,

I haven't followed the latest thinking on breaking algorithms such as RSA, =
so I'll take your word for the fact that the Number Field Sieve is =
currently the most efficient algorithm.  But isn't it at least possible =
that there might be other methods that although  less efficient than the =
NFS on a single machine, might be more well-suited to a distributed =
attack?  Likewise, would other algorithms be less constrained by a 64-bit =
addressing limitation?

Interesting point, though, in any case.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.


>>> <[e-mail]> 12/13/00 10:36PM >>>

I am sorry for the multiple postings, but I thought this particular =
subject, although probably quite controversial, might be of interest to =
the many peoples following these mailing lists, especially because of the =
upcoming adoption of the AES algorithm by many IETF protocols.
As symmetric keys grow, they can be attacked by more processors without a =
change in processor technology since the memory requirements for breaking =
symmetric keys remain trivial.  However, for the Number Field Sieve (NFS) =
algorithm, which is currently the most efficient method to break RSA keys, =
this is not true.  Based on this premise, the "time and space" based RSA =
key size equivalents previously published in the RSA Labs Bulletin #13 of =
April 2000 by Robert Silverman (http://www.rsalabs.com/bulletins/) have =
recently been extended to cover all the AES symmetric key sizes in the =
latest draft of ANSI X9.44, which will eventually become the ANSI standard =
for RSA key transport:
                        Time and Space=20
Symmetric               Equivalent=20
Key Size                RSA Key Size=20
(in bits)               (in bits)=20
64                      450=20
128                     1620=20
192                     2500=20
256                     4200=20
These "time and space" based key sizes equivalents assume that both time =
and memory are binding constraints in order to break RSA keys.  This same =
draft also indicates that beyond RSA key sizes of 768 bits one can no =
longer effectively utilize 32-bit processors with the NFS algorithm =
because the required memory exceeds what can be addressed in 32 bits; one =
is forced to use 64-bit machines.  Beyond RSA key sizes of about 2500 =
bits, the memory requirements for the NFS algorithm exceed what can be =
addressed even on 64 bit machines.
For your information, here are also the estimated "time" only based RSA =
key size equivalents for solving the NFS problem from the same ANSI draft:
                        Time Only=20
Symmetric               Equivalent=20
Key Size                RSA Key Size=20
(in bits)               (in bits)=20
64                      512=20
128                     2550=20
192                     6700=20
256                     13500=20
Note that either of these sets of RSA key size equivalents could be used =
with Diffie-Hellman for solving the value of "p" since the NFS algorithm =
is also the most efficient method to break Diffie-Hellman algorithm today. =
 Note also that these time only equivalents numbers are slightly smaller =
than those from ANSI X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 =
bits, 6700 vs 7680 for 192 bits and 13500 vs 15360 for 256 bits) and the =
numbers in Hilarie Orman's Internet Draft (i.e. draft-orman-public-key-leng=
ths-01.txt).
Shouldn't IETF standards mention these new "time and space" based key size =
equivalents in addition to existing "time" only based key size equivalents,=
 and possibly even suggest that "time and space" based key size equivalents=
 be used for RSA and Diffie-Hellman?  Why mandate larger equivalent key =
sizes when smaller equivalent key sizes can probably suffice?
Food for thought!=20
Cheers,=20
Francois=20
___________________________________=20
Francois Rousseau=20
Director of Standards and Conformance=20
Chrysalis-ITS=20
1688 Woodward Drive=20
Ottawa, Ontario, CANADA, K2C 3R7=20
[e-mail]      Tel. [phone] ext. 419=20
http://www.chrysalis-its.com     Fax. [phone]=20

--=_2C77224E.31502339
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN-TOP: 2px; FONT: 8pt MS Sans Serif; MARGIN-LEFT: =
2px">
<DIV><FONT size=3D2>Francois,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I haven't followed the latest thinking on breaking =
algorithms=20
such as RSA, so I'll take your word for the fact that the Number Field =
Sieve is=20
currently the most efficient algorithm.&nbsp; But isn't it at least =
possible=20
that there might be other methods that although&nbsp; less efficient than =
the=20
NFS on a single machine, might be more well-suited to a distributed=20
attack?&nbsp; Likewise, would other algorithms be less constrained by a =
64-bit=20
addressing limitation?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Interesting point, though, in any case.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Regards,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Bob</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Robert R. Jueneman</FONT></DIV>
<DIV><FONT size=3D2>Security Architect</FONT></DIV>
<DIV><FONT size=3D2>Novell, Inc.</FONT></DIV>
<DIV><BR><BR>&gt;&gt;&gt; &lt;[e-mail]&gt; 12/13/00 =
10:36PM=20
&gt;&gt;&gt;<BR></DIV>
<P><FONT size=3D2>I am sorry for the multiple postings, but I thought =
this=20
particular subject, although probably quite controversial, might be of =
interest=20
to the many peoples following these mailing lists, especially because of =
the=20
upcoming adoption of the AES algorithm by many IETF protocols.</FONT></P>
<P><FONT size=3D2>As symmetric keys grow, they can be attacked by more =
processors=20
without a change in processor technology since the memory requirements =
for=20
breaking symmetric keys remain trivial.&nbsp; However, for the Number =
Field=20
Sieve (NFS) algorithm, which is currently the most efficient method to =
break RSA=20
keys, this is not true.&nbsp; Based on this premise, the "time and space" =
based=20
RSA key size equivalents previously published in the RSA Labs Bulletin #13 =
of=20
April 2000 by Robert Silverman (<A target=3D_blank=20
href=3D"http://www.rsalabs.com/bulletins/">http://www.rsalabs.com/bulletins=
/</A>)=20
have recently been extended to cover all the AES symmetric key sizes in =
the=20
latest draft of ANSI X9.44, which will eventually become the ANSI standard =
for=20
RSA key transport:</FONT></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D2>Time and =
Space</FONT>=20
<BR><FONT size=3D2>Symmetric&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Equivalent</FONT> <BR><FONT=20
size=3D2>Key Size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RSA Key Size</FONT> <BR><FONT=20=

size=3D2>(in bits)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (in bits)</FONT> </P>
<P><FONT size=3D2>64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 450</FONT> <BR><FONT=20
size=3D2>128&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1620</FONT> <BR><FONT=20
size=3D2>192&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2500</FONT> <BR><FONT=20
size=3D2>256&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4200</FONT> </P>
<P><FONT size=3D2>These "time and space" based key sizes equivalents =
assume that=20
both time and memory are binding constraints in order to break RSA =
keys.&nbsp;=20
This same draft also indicates that beyond RSA key sizes of 768 bits one =
can no=20
longer effectively utilize 32-bit processors with the NFS algorithm =
because the=20
required memory exceeds what can be addressed in 32 bits; one is forced to =
use=20
64-bit machines.&nbsp; Beyond RSA key sizes of about 2500 bits, the =
memory=20
requirements for the NFS algorithm exceed what can be addressed even on 64 =
bit=20
machines.</FONT></P>
<P><FONT size=3D2>For your information, here are also the estimated "time" =
only=20
based RSA key size equivalents for solving the NFS problem from the same =
ANSI=20
draft:</FONT></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D2>Time Only</FONT>=
=20
<BR><FONT size=3D2>Symmetric&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Equivalent</FONT> <BR><FONT=20
size=3D2>Key Size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RSA Key Size</FONT> <BR><FONT=20=

size=3D2>(in bits)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (in bits)</FONT> </P>
<P><FONT size=3D2>64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 512</FONT> <BR><FONT=20
size=3D2>128&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2550</FONT> <BR><FONT=20
size=3D2>192&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6700</FONT> <BR><FONT=20
size=3D2>256&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 13500</FONT> </P>
<P><FONT size=3D2>Note that either of these sets of RSA key size equivalent=
s could=20
be used with Diffie-Hellman for solving the value of "p" since the NFS =
algorithm=20
is also the most efficient method to break Diffie-Hellman algorithm =
today.&nbsp;=20
Note also that these time only equivalents numbers are slightly smaller =
than=20
those from ANSI X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 bits, =
6700=20
vs 7680 for 192 bits and 13500 vs 15360 for 256 bits) and the numbers in =
Hilarie=20
Orman's Internet Draft (i.e. draft-orman-public-key-lengths-01.txt).</FONT>=
</P>
<P><FONT size=3D2>Shouldn't IETF standards mention these new "time and =
space"=20
based key size equivalents in addition to existing "time" only based key =
size=20
equivalents, and possibly even suggest that "time and space" based key =
size=20
equivalents be used for RSA and Diffie-Hellman?&nbsp; Why mandate =
larger=20
equivalent key sizes when smaller equivalent key sizes can probably=20
suffice?</FONT></P>
<P><FONT size=3D2>Food for thought!</FONT> </P>
<P><FONT size=3D2>Cheers,</FONT> </P>
<P><FONT size=3D2>Francois</FONT> <BR><FONT=20
size=3D2>___________________________________</FONT> <BR><FONT size=3D2>Fran=
cois=20
Rousseau</FONT> <BR><FONT size=3D2>Director of Standards and Conformance</F=
ONT>=20
<BR><FONT size=3D2>Chrysalis-ITS</FONT> <BR><FONT size=3D2>1688 Woodward=20=

Drive</FONT> <BR><FONT size=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT> =
<BR><FONT=20
size=3D2>[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613)=20
723-5076 ext. 419</FONT> <BR><FONT size=3D2><A target=3D_blank=20
href=3D"http://www.chrysalis-its.com">http://www.chrysalis-its.com</A>&nbsp=
;&nbsp;&nbsp;&nbsp;=20
Fax. [phone]</FONT> </P></BODY></HTML>

--=_2C77224E.31502339--


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA08335 for ietf-smime-bks; Wed, 13 Dec 2000 21:34:03 -0800 (PST)
Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA08330; Wed, 13 Dec 2000 21:34:01 -0800 (PST)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <XXCGYLMZ>; Thu, 14 Dec 2000 00:36:44 -0500
Message-ID: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Subject: New Time and Space Based Key Size Equivalents for RSA and Diffie- Hellman
Date: Thu, 14 Dec 2000 00:36:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0658F.D7D4218A"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0658F.D7D4218A
Content-Type: text/plain;
	charset="iso-8859-1"

I am sorry for the multiple postings, but I thought this particular subject,
although probably quite controversial, might be of interest to the many
peoples following these mailing lists, especially because of the upcoming
adoption of the AES algorithm by many IETF protocols.

As symmetric keys grow, they can be attacked by more processors without a
change in processor technology since the memory requirements for breaking
symmetric keys remain trivial.  However, for the Number Field Sieve (NFS)
algorithm, which is currently the most efficient method to break RSA keys,
this is not true.  Based on this premise, the "time and space" based RSA key
size equivalents previously published in the RSA Labs Bulletin #13 of April
2000 by Robert Silverman (http://www.rsalabs.com/bulletins/) have recently
been extended to cover all the AES symmetric key sizes in the latest draft
of ANSI X9.44, which will eventually become the ANSI standard for RSA key
transport:

			Time and Space
Symmetric		Equivalent
Key Size		RSA Key Size
(in bits)		(in bits)

64			450
128			1620
192			2500
256			4200

These "time and space" based key sizes equivalents assume that both time and
memory are binding constraints in order to break RSA keys.  This same draft
also indicates that beyond RSA key sizes of 768 bits one can no longer
effectively utilize 32-bit processors with the NFS algorithm because the
required memory exceeds what can be addressed in 32 bits; one is forced to
use 64-bit machines.  Beyond RSA key sizes of about 2500 bits, the memory
requirements for the NFS algorithm exceed what can be addressed even on 64
bit machines.

For your information, here are also the estimated "time" only based RSA key
size equivalents for solving the NFS problem from the same ANSI draft:

			Time Only
Symmetric		Equivalent
Key Size		RSA Key Size
(in bits)		(in bits)

64			512
128			2550
192			6700
256			13500

Note that either of these sets of RSA key size equivalents could be used
with Diffie-Hellman for solving the value of "p" since the NFS algorithm is
also the most efficient method to break Diffie-Hellman algorithm today.
Note also that these time only equivalents numbers are slightly smaller than
those from ANSI X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 bits,
6700 vs 7680 for 192 bits and 13500 vs 15360 for 256 bits) and the numbers
in Hilarie Orman's Internet Draft (i.e.
draft-orman-public-key-lengths-01.txt).

Shouldn't IETF standards mention these new "time and space" based key size
equivalents in addition to existing "time" only based key size equivalents,
and possibly even suggest that "time and space" based key size equivalents
be used for RSA and Diffie-Hellman?  Why mandate larger equivalent key sizes
when smaller equivalent key sizes can probably suffice?

Food for thought!

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]

------_=_NextPart_001_01C0658F.D7D4218A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>New Time and Space Based Key Size Equivalents for RSA and =
Diffie-Hellman</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I am sorry for the multiple postings, but I thought =
this particular subject, although probably quite controversial, might =
be of interest to the many peoples following these mailing lists, =
especially because of the upcoming adoption of the AES algorithm by =
many IETF protocols.</FONT></P>

<P><FONT SIZE=3D2>As symmetric keys grow, they can be attacked by more =
processors without a change in processor technology since the memory =
requirements for breaking symmetric keys remain trivial.&nbsp; However, =
for the Number Field Sieve (NFS) algorithm, which is currently the most =
efficient method to break RSA keys, this is not true.&nbsp; Based on =
this premise, the &quot;time and space&quot; based RSA key size =
equivalents previously published in the RSA Labs Bulletin #13 of April =
2000 by Robert Silverman (<A HREF=3D"http://www.rsalabs.com/bulletins/" =
TARGET=3D"_blank">http://www.rsalabs.com/bulletins/</A>) have recently =
been extended to cover all the AES symmetric key sizes in the latest =
draft of ANSI X9.44, which will eventually become the ANSI standard for =
RSA key transport:</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Time and =
Space</FONT>
<BR><FONT SIZE=3D2>Symmetric&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Equivalent</FONT>
<BR><FONT SIZE=3D2>Key Size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RSA Key Size</FONT>
<BR><FONT SIZE=3D2>(in bits)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (in bits)</FONT>
</P>

<P><FONT SIZE=3D2>64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 450</FONT>
<BR><FONT SIZE=3D2>128&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1620</FONT>
<BR><FONT SIZE=3D2>192&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2500</FONT>
<BR><FONT SIZE=3D2>256&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4200</FONT>
</P>

<P><FONT SIZE=3D2>These &quot;time and space&quot; based key sizes =
equivalents assume that both time and memory are binding constraints in =
order to break RSA keys.&nbsp; This same draft also indicates that =
beyond RSA key sizes of 768 bits one can no longer effectively utilize =
32-bit processors with the NFS algorithm because the required memory =
exceeds what can be addressed in 32 bits; one is forced to use 64-bit =
machines.&nbsp; Beyond RSA key sizes of about 2500 bits, the memory =
requirements for the NFS algorithm exceed what can be addressed even on =
64 bit machines.</FONT></P>

<P><FONT SIZE=3D2>For your information, here are also the estimated =
&quot;time&quot; only based RSA key size equivalents for solving the =
NFS problem from the same ANSI draft:</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Time =
Only</FONT>
<BR><FONT SIZE=3D2>Symmetric&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Equivalent</FONT>
<BR><FONT SIZE=3D2>Key Size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RSA Key Size</FONT>
<BR><FONT SIZE=3D2>(in bits)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (in bits)</FONT>
</P>

<P><FONT SIZE=3D2>64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 512</FONT>
<BR><FONT SIZE=3D2>128&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2550</FONT>
<BR><FONT SIZE=3D2>192&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6700</FONT>
<BR><FONT SIZE=3D2>256&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 13500</FONT>
</P>

<P><FONT SIZE=3D2>Note that either of these sets of RSA key size =
equivalents could be used with Diffie-Hellman for solving the value of =
&quot;p&quot; since the NFS algorithm is also the most efficient method =
to break Diffie-Hellman algorithm today.&nbsp; Note also that these =
time only equivalents numbers are slightly smaller than those from ANSI =
X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 bits, 6700 vs 7680 =
for 192 bits and 13500 vs 15360 for 256 bits) and the numbers in =
Hilarie Orman's Internet Draft (i.e. =
draft-orman-public-key-lengths-01.txt).</FONT></P>

<P><FONT SIZE=3D2>Shouldn't IETF standards mention these new &quot;time =
and space&quot; based key size equivalents in addition to existing =
&quot;time&quot; only based key size equivalents, and possibly even =
suggest that &quot;time and space&quot; based key size equivalents be =
used for RSA and Diffie-Hellman?&nbsp; Why mandate larger equivalent =
key sizes when smaller equivalent key sizes can probably =
suffice?</FONT></P>

<P><FONT SIZE=3D2>Food for thought!</FONT>
</P>

<P><FONT SIZE=3D2>Cheers,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
[phone] ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0658F.D7D4218A--


Received: by ns.secondary.com (8.9.3/8.9.3) id JAA05656 for ietf-smime-bks; Wed, 13 Dec 2000 09:16:35 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05650 for <[e-mail]>; Wed, 13 Dec 2000 09:16:34 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com (ietf.207.137.71.200.tx.verio.net [207.137.71.200]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA00313; Wed, 13 Dec 2000 09:18:36 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 12 Dec 2000 12:36:27 -0500
To: "Ahmed Bhamjee" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: UKM size in the SMIME Freeware Library v1.8
Cc: <[e-mail]>
In-Reply-To: <000101c0642d$3a55a090$[e-mail]>
References: <000001c05b95$02aef8d0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

RFC  2631 says:

    partyAInfo is a random string provided by the sender. In CMS, it is
      provided as a parameter in the UserKeyingMaterial field (encoded as
      an OCTET STRING). If provided, partyAInfo MUST contain 512 bits.

I do not see any ambiguity here...

Russ

At 11:18 AM 12/12/2000 +0000, Ahmed Bhamjee wrote:
>I have been testing our product with the latest SFL version. More
>specifically, I have performed tests using the Diffie-Hellman key agreement
>method. From the RFC (2631), the size of partyAInfo contained in the
>OtherInfo sequence must be 512 bits in size. However, the SFL produces
>keying material with partyAInfo set to 128 bytes. Should this not be 64
>bytes? Perhaps I am missing something.
>
>Thanks
>Ahmed



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA08598 for ietf-smime-bks; Wed, 13 Dec 2000 03:22:08 -0800 (PST)
Received: from gw.capgemini.fr (gw.capgemini.fr [194.3.247.254]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08591 for <[e-mail]>; Wed, 13 Dec 2000 03:22:06 -0800 (PST)
Received: from prenoms.capgemini.fr (capmail.capgemini.fr [194.2.91.200]) by gw.capgemini.fr (8.9.3/8.9.1) with ESMTP id MAA24051; Wed, 13 Dec 2000 12:24:13 +0100 (MET)
Received: from prenoms.capgemini.fr (localhost [127.0.0.1]) by prenoms.capgemini.fr (8.9.3/8.9.3) with ESMTP id MAA21639; Wed, 13 Dec 2000 12:24:15 +0100 (MET)
Received: from bboutelo ([195.124.153.97]) by prenoms.capgemini.fr (8.9.3/8.9.3) with SMTP id MAA21537; Wed, 13 Dec 2000 12:24:13 +0100 (MET)
Message-ID: <00d501c064f7$38e1dd80$02000000@bboutelo>
From: "Bertrand BOUTELOUP" <[e-mail]>
To: <[e-mail]>
Subject: Proposed amendment to the Compressed data Content type for S/MIME
Date: Wed, 13 Dec 2000 12:24:09 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CE_01C064FF.97B2F620"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00CE_01C064FF.97B2F620
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Here are some amendments on the following draft:
> Title : Compressed Data Content Type for S/MIME=20

Can we add as an optional field the "SizeUncomp" field in the The =
compressed-data type. SizeUncomp will be the size of non compressed =
data.
Best regards.

Bertrand BOUTELOUP

------=_NextPart_000_00CE_01C064FF.97B2F620
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,<BR><BR>Here are some&nbsp;amendments on the following =
draft:<BR>&gt;=20
Title : <A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-smime-compression-=
03.txt">Compressed=20
Data Content Type for S/MIME</A> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Can we add as an optional field the =
"Size<FONT=20
face=3D"Courier New">Uncomp" field in the </FONT><FONT size=3D2><FONT=20
face=3D"Courier New">The compressed-data type. =
</FONT></FONT></FONT><FONT=20
face=3D"Courier New" size=3D2><FONT face=3D"Courier New" =
size=3D2>SizeUncomp&nbsp;will=20
be&nbsp;the size of non compressed data.</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New" =
size=3D2>Best=20
regards.</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New"=20
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New" =
size=3D2><FONT=20
face=3DArial>Bertrand BOUTELOUP</FONT></DIV></FONT></FONT></BODY></HTML>

------=_NextPart_000_00CE_01C064FF.97B2F620--



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA01128 for ietf-smime-bks; Tue, 12 Dec 2000 03:16:50 -0800 (PST)
Received: from mail1.sse.ie (s193-120-32-20.sse.ie [193.120.32.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01123 for <[e-mail]>; Tue, 12 Dec 2000 03:16:48 -0800 (PST)
Received: from ahmed (AHMED.sse.ie [193.120.32.223]) by mail1.sse.ie (8.11.1/8.11.1) with SMTP id eBCBIpr23866 for <[e-mail]>; Tue, 12 Dec 2000 11:18:52 GMT
From: "Ahmed Bhamjee" <[e-mail]>
To: <[e-mail]>
Subject: UKM size in the SMIME Freeware Library v1.8
Date: Tue, 12 Dec 2000 11:18:16 -0000
Message-ID: <000101c0642d$3a55a090$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <000001c05b95$02aef8d0$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have been testing our product with the latest SFL version. More
specifically, I have performed tests using the Diffie-Hellman key agreement
method. From the RFC (2631), the size of partyAInfo contained in the
OtherInfo sequence must be 512 bits in size. However, the SFL produces
keying material with partyAInfo set to 128 bytes. Should this not be 64
bytes? Perhaps I am missing something.

Thanks
Ahmed



Received: by ns.secondary.com (8.9.3/8.9.3) id GAA24978 for ietf-smime-bks; Mon, 11 Dec 2000 06:11:29 -0800 (PST)
Received: from sentry.gw.tislabs.com ([e-mail] [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24969 for <[e-mail]>; Mon, 11 Dec 2000 06:11:25 -0800 (PST)
Received: by sentry.gw.tislabs.com; id JAA29805; Mon, 11 Dec 2000 09:16:32 -0500 (EST)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma029741; Mon, 11 Dec 00 09:15:53 -0500
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id JAA12317 for [e-mail]; Mon, 11 Dec 2000 09:12:11 -0500 (EST)
Date: Mon, 11 Dec 2000 09:12:11 -0500 (EST)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

                   R E G I S T E R   N O W ! !

THE INTERNET SOCIETY'S
2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) 
February 8-9, 2001
Catamaran Resort Hotel, San Diego, California
General Chair:   Steve Welke, Trusted Computer Solutions
Program Chairs:  Avi Rubin, AT&T Labs - Research
                 Paul Van Oorschot, Entrust Technologies

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss01
EARLY REGISTRATION DISCOUNT DEADLINE:  January 11, 2001

The 8th annual NDSS Symposium brings together researchers,
implementers, and users of network and distributed system security
technologies to discuss today's important security issues and
challenges.  The Symposium provides a mix of technical papers and
panel presentations that describe promising new approaches to
security problems that are practical and, to the extent possible,
have been implemented.  NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.

THIS YEAR'S TOPICS INCLUDE:
* IP Traceback
* Authenticating Streamed Data
* ATM Encryption
* Source Authentication for Multicast
* Distributed Certified E-Mail
* Wireless Security
* Multi-Security Domain Networks
* Authentication And Key Agreement
* Access Control Language for Security Policies
* Limiting the Disclosure of Access Control Policies
* Principles of Policy in Secure Groups
* Trust Management for IPsec
* Building Certification Paths
* Decentralized Jini Security
* Termination in Language-based Systems
* Cryptography as a Network Service
* Implementation of Kerberos Crossrealm Referral Handling
* Security Risks of Peer-to-Peer Networking

PRE-CONFERENCE TECHNICAL TUTORIALS:
* Network Security Protocol Standards, Stephen Kent
* Deployed & Emerging Security Systems for the Internet, Radia Perlman &
  Charlie Kaufman
* Building Secure Software, Gary McGraw
* Intrusion Detection, Dan Nadir
* Biometrics, Jim Wayman
* Group Security, Thomas Hardjono & Hugh Harney

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Torryn Brazell at the Internet Society
at [phone] or send e-mail to [e-mail].

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.



Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21201 for ietf-smime-bks; Sat, 9 Dec 2000 12:00:41 -0800 (PST)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21197 for <[e-mail]>; Sat, 9 Dec 2000 12:00:39 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id JAA23076; Sun, 10 Dec 2000 09:02:46 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97639216626966>; Sun, 10 Dec 2000 09:02:46 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  looking for introductory s/mime docs?
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sun, 10 Dec 2000 09:02:46 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Erdal YILDIZ" <[e-mail]>

>I am looking for some high level documants about s/mime. I am very new in taht
>area and the docs I look for  must be in the beginners level. What is s/mime?
>The initiatives for it? Historical story of it? Etc.

You could look at part 3 of my crypto tutorial,
http://www.cs.auckland.ac.nz/~pgut001/tutorial/, which covers among other
things "email security mechanisms, PEM, the PEM CA model, PGP, PGP keys and the
PGP trust model, MOSS, PGP/MIME, S/MIME and CMS, MSP" at a reasonably easy
level.  The historical background and other information is in there as well.

Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17773 for ietf-smime-bks; Sat, 9 Dec 2000 09:13:27 -0800 (PST)
Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17735; Sat, 9 Dec 2000 09:12:42 -0800 (PST)
Message-Id: <[e-mail]>
From: Mail Sender<[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Russian Goods and Service from Moscow
Reply-To: [e-mail]
Date: 09.12.2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

www.rusgoods.com    www.rusgoods.ru
================================================================
We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical 
watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . 
  It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes 
watches for the Russian Air Forces , Russian Naval Forces. 
  All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the 
warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any 
middlemans.
 The submarine "Kursk" had on board mechanical marine hronometr 6MX. 
 ===============================================================
The "table" of orders.    Here you can to order, to find, to know almost everything, than the Russia is rich, 
everything 
that does not contradict Russian Federation laws. 
Here you can receive or order:

The information about any enterprise, firm, organization, or person in Russia 
The production or any goods of Russian manufactories, and other things if it is possible. 
===============================================================
www.rusgoods.com    www.rusgoods.ru


Received: by ns.secondary.com (8.9.3/8.9.3) id EAA07180 for ietf-smime-bks; Sat, 9 Dec 2000 04:49:07 -0800 (PST)
Received: from yengec (kasirga.tsk.mil.tr [212.50.36.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA07173 for <[e-mail]>; Sat, 9 Dec 2000 04:49:03 -0800 (PST)
Received: from yengec (192.168.1.1 [192.168.1.1]) by tufan.tsk.mil.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XAQ70VRT; Sat, 9 Dec 2000 14:49:59 +0200
Message-ID: <007801c061e0$a7aee740$4c2b1d3e@erdal>
From: "Erdal YILDIZ" <[e-mail]>
To: <[e-mail]>
Subject: looking for introductory s/mime docs?
Date: Sat, 9 Dec 2000 15:04:59 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01C061F1.664E6440"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0073_01C061F1.664E6440
Content-Type: text/plain;
	charset="iso-8859-9"
Content-Transfer-Encoding: quoted-printable

Hi All;
I am looking for some high level documants about s/mime. I am very new =
in taht area and the docs I look for  must be in the beginners level. =
What is s/mime? The initiatives for it? Historical story of it? Etc.
If someone help me I would be really very appreciated.
Thanks in advance
Erdal

------=_NextPart_000_0073_01C061F1.664E6440
Content-Type: text/html;
	charset="iso-8859-9"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-9 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Hi All;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I am looking for some high level =
documants about=20
s/mime. I am very new in taht area and the docs I look for&nbsp; must be =
in the=20
beginners level. What is s/mime? The initiatives for it? Historical =
story of it?=20
Etc.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>If someone help me I would be really =
very=20
appreciated.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks in advance</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Erdal</FONT></DIV></BODY></HTML>

------=_NextPart_000_0073_01C061F1.664E6440--



Received: by ns.secondary.com (8.9.3/8.9.3) id PAA03763 for ietf-smime-bks; Thu, 7 Dec 2000 15:05:39 -0800 (PST)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03758; Thu, 7 Dec 2000 15:05:36 -0800 (PST)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id MAA15272; Fri, 8 Dec 2000 12:07:41 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97623046120024>; Fri, 8 Dec 2000 12:07:41 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Semi-annual reminder: dumpasn1 utility available
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 8 Dec 2000 12:07:41 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a semi-annual reminder to people about dumpasn1, which picks apart
ASN.1 data and displays it in human-readable form.  I do actually update this
every now and then, so it's worth checking every few months for new copies.
Recent (within the last 6-12 months) features include automatic detection of
stuff encapsulated inside bit/octet strings (no more -o or -b options),
detection of encapsulated text strings disguised as something else, the ability
to display text alongside a hex dump of data, an attempt at displaying
BMPStrings under Windows (which for console apps doesn't actually work anything
like what the docs would have you believe, if anyone can get it to display non
8859-1 characters let me know), and an indication of which bit is set if you've
got a large string of zero bits with a single 1 bit at the start (this was
motivated by the need to pick apart CMP error codes).

Available as usual from http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.{c|.cfg}
for the source code and config file.

Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id CAA09005 for ietf-smime-bks; Thu, 7 Dec 2000 02:43:57 -0800 (PST)
Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08998 for <[e-mail]>; Thu, 7 Dec 2000 02:43:56 -0800 (PST)
Received: from scherbius.secorvo.de (kasiski.secorvo.de [194.45.12.203]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id LAA13614 for <[e-mail]>; Thu, 7 Dec 2000 11:34:33 +0100
Message-Id: <[e-mail]>
From: "Stefan Kelm" <[e-mail]>
Organization: Secorvo Security Consulting GmbH
To: [e-mail]
Date: Thu, 7 Dec 2000 11:45:56 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: v2/v3 comparison document?
Reply-to: [e-mail]
In-reply-to: <[e-mail]>
References: <[e-mail]. uk>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I'm looking for some kind of roadmap of high-level document
that compares S/MIME v2 against v3. Is such a text
available anywhere? Any input is highly appreciated.

Cheers,

	Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. [phone], Fax [phone]
E-Mail [e-mail], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B


Received: by ns.secondary.com (8.9.3/8.9.3) id UAA23708 for ietf-smime-bks; Wed, 6 Dec 2000 20:58:48 -0800 (PST)
Received: from bsd.gymparnr.sk (bsd.gymparnr.sk [195.168.176.67]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA23671 for <[e-mail]>; Wed, 6 Dec 2000 20:58:44 -0800 (PST)
From: [e-mail]
Received: (qmail 16826 invoked from network); 6 Dec 2000 00:18:39 -0000
Received: from 1cust62.tnt1.los-angeles.ca.da.uu.net (HELO qYo7NPC3Z?) (63.57.183.62) by bsd.gymparnr.sk with SMTP; 6 Dec 2000 00:18:39 -0000
DATE: 05 Dec 00 4:38:15 PM
Message-ID: <674UGKz14zV7En09R14>
SUBJECT: 1+1=2
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The Internet's Finest and Most Reliable Bulk Email Provider!

Since 1996, Tech Data Technologies has provided bulk email service to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced, direct email technology, employed by only a knowledgeable few in the world. Our expert programmers have made it possible for us to penetrate any email blocking filter in use.

We have over 120 million active email addresses, increasing our list at the rate of half a million to one million a month. We will put your product or service instantly and directly into the hands of millions of prospects! You will have instant, guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours.

Our email addresses are sorted by country, state and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience!

Your message can be presented in any language you wish, as plain text if you desire simplicity, or in html with color and graphics.

Call us for a free consultation at (323)- 851- 8386  [U.S.A.]. We are open 24 hours a day, 7 days a week. No one understands the global market like we do. 

For a limited time, take advantage of our holiday special -- two million general U.S. emails for just $450 per million! We include, at no cost, a bullet proof email address for 30 days, a $400 value!

BULK EMAIL PRICES

   500,000........................$375
   750,000........................$562
1,200,000........................$720
1,600,000..................    ...$960
3,000,000......................$1,500
3,000,000+ ...................PLEASE CALL FOR A QUOTE


Resellers welcome. We accept Visa, MasterCard and check by FAX.

DON'T WAIT! LET TECH DATA TECHNOLOGIES BE YOUR PARTNER!!


Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below).To Remove Yourself From This List: reply to this email with the email
address that you would like removed and the word REMOVE in the subject heading.




Received: by ns.secondary.com (8.9.3/8.9.3) id NAA23836 for ietf-smime-bks; Tue, 5 Dec 2000 13:20:31 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23828 for <[e-mail]>; Tue, 5 Dec 2000 13:20:30 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA26322; Tue, 5 Dec 2000 13:21:53 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 05 Dec 2000 14:55:31 -0500
To: Graeme Lunt <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-00.txt
Cc: [e-mail], "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]. uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Graeme:

The id-data content type should NOT be used to identify a CMS content in an 
X.400 envelope.  I assigned the id-ct-contentInfo OID for this purpose.

I am trying to make id-data a useful identifier.  If we use it for too many 
things, it will not help anyone determine how to process a content.

Russ


At 10:41 AM 11/16/2000 +0000, Graeme Lunt wrote:
>Russ,
>
> > The CMS contentInfo uses id-data when the content is expected to be
> > MIME.  This choice is for historical reasons (S/MIME v2 did
> > it that way).
> >
> > I think that the authors are trying to avoid a layer of MIME
> > encapsulation.
>
>Yes - I can see that you would want to avoid this.
>
> > Did I miss something?
>
>My comment was a little different.
>
>What is being proposed is that the OID id-data must be used for the
>X.400 content type when the CMS object is covered by an outer MIME
>wrapper.
>
>However, a more generic option is to use an OID (say "id-mime") for
>the X.400 content type that represents MIME.
>Using this content type I could still carry my MIME wrapped CMS object,
>but I could also carry other arbitray MIME objects. For example, I
>could carry multipart/signed with this method.
>
>In fact, thinking about it a little more, does the draft as it stands
>actually allow me to do this? If I use id-data as the content-type,
>MUST the content be a MIME wrapped CMS object? Could it just be arbitrary
>MIME?
>
>This would certainly be a useful feature.
>
>Graeme



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13451 for ietf-smime-bks; Tue, 5 Dec 2000 11:19:07 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13440; Tue, 5 Dec 2000 11:19:05 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <WY8B6Q12>; Tue, 5 Dec 2000 14:20:35 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Subject: SFL/CML/ACL/SNACC Freeware Available *NEW CML RELEASE*
Date: Tue, 5 Dec 2000 14:20:30 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

The freeware Certificate Management Library (CML), S/MIME Freeware Library
(SFL), Access Control Library (ACL), Enhanced SNACC ASN.1 freeware and
Cryptographic Token Interface Libraries (CTIL) developed by Getronics
Government Solutions are now available from the following web pages:

SFL and CTILs: <http://www.getronicsgov.com/hot/sfl_home.htm>

CML: <http://www.getronicsgov.com/hot/cml_home.htm>

ACL: <http://www.getronicsgov.com/hot/acl_home.htm>

Enhanced SNACC ASN.1 Freeware:
<http://www.getronicsgov.com/hot/snacc_home.htm>

**NEW CML RELEASE**: The CML files available from
<http://www.getronicsgov.com/hot/cml_home.htm> are a new release.  The v1.81
CML release fixes bugs in the v1.8 CML as documented in the v1.8 CML Problem
Report file.  

With the exception of the CML files, there are no significant differences
between the files available from the Getronics Government Solutions web
pages and those that were formerly available from the Fortezza Developers
Web Site <ww.armadillo.huntsville.al.us>.

We welcome all feedback regarding these freeware security libraries.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: by ns.secondary.com (8.9.3/8.9.3) id MAA20345 for ietf-smime-bks; Mon, 4 Dec 2000 12:05:03 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20339 for <[e-mail]>; Mon, 4 Dec 2000 12:05:02 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <WY8B6JN4>; Mon, 4 Dec 2000 15:06:29 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Ahmed Bhamjee <[e-mail]>, Ietf-Smime <[e-mail]>
Subject: RE: SMIME Freeware Library v1.8
Date: Mon, 4 Dec 2000 15:06:32 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

The freeware Certificate Management Library (CML), S/MIME Freeware Library
(SFL), Access Control Library (ACL) and Enhanced SNACC ASN.1 freeware will
be available on the Getronics Government Solutions web site
<http://www.GetronicsGov.com/> on 6 December 2000.  I will inform everyone
as soon as they are available.  

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12570 for ietf-smime-bks; Mon, 4 Dec 2000 10:25:55 -0800 (PST)
Received: from sparta.com (IDENT:[e-mail] [157.185.61.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12565 for <[e-mail]>; Mon, 4 Dec 2000 10:25:53 -0800 (PST)
Received: from huntsville.sparta.com (huntsville.sparta.com [157.185.4.13]) by sparta.com (8.9.3/8.9.3) with ESMTP id MAA11421; Mon, 4 Dec 2000 12:27:48 -0600
Received: from williamspc4 (williamspc4 [157.185.4.50]) by huntsville.sparta.com (8.9.3+Sun/8.8.5) with SMTP id MAA17618; Mon, 4 Dec 2000 12:27:46 -0600 (CST)
Reply-To: <[e-mail]>
From: "Eugene C. \(Gene\) Williams" <[e-mail]>
To: "Ahmed Bhamjee" <[e-mail]>, "Ietf-Smime" <[e-mail]>
Subject: RE: SMIME Freeware Library v1.8
Date: Mon, 4 Dec 2000 12:38:18 -0600
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_001C_01C05DEF.147EE000"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <000001c05b95$02aef8d0$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001C_01C05DEF.147EE000
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ahmed,

See attached message from John Pawling...John has the service become
available yet?

v.r.

Gene

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Ahmed Bhamjee
Sent: Friday, December 01, 2000 6:48 AM
To: [e-mail]
Subject: SMIME Freeware Library v1.8


Could someone please point me to a url where I can find the SMIME Freeware
Library v1.8. I have been trying the following url with no success:

http://www.armadillo.huntsville.al.us/software/smime

Thanks
Ahmed

------=_NextPart_000_001C_01C05DEF.147EE000
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment

Reply-To: <[e-mail]>
From: "Pawling, John" <[e-mail]>
Sender: <[e-mail]>
To: "Multiple recipients of list" <[e-mail]>
Subject: SFL/CML/ACL/Enhanced SNACC Freeware Availability
Date: Tue, 21 Nov 2000 10:16:42 -0600
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Internet Mail Service (5.5.2650.21)
X-UIDL: 16927760697143d93e9a32f6c1124357
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-To: "Pawling, John" <[e-mail]>
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas


All,

The freeware Certificate Management Library (CML), S/MIME Freeware Library
(SFL), Access Control Library (ACL) and Enhanced SNACC ASN.1 freeware are no
longer available from the <http://www.armadillo.huntsville.al.us> web site.
They will be available on the Getronics Government Solutions web site
<http://www.GetronicsGov.com/> by 1 December 2000.  I will inform everyone
as soon as they are available.  They will continue to be freely available to
everyone.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



------=_NextPart_000_001C_01C05DEF.147EE000--



Received: by ns.secondary.com (8.9.3/8.9.3) id PAA08588 for ietf-smime-bks; Sun, 3 Dec 2000 15:35:16 -0800 (PST)
Received: from nt40srv.sudsistemi.it ([138.66.150.18]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA08545 for <[e-mail]>; Sun, 3 Dec 2000 15:33:46 -0800 (PST)
From: [e-mail]
Received: from wk3F17b6r (unverified [63.28.123.13]) by nt40srv.sudsistemi.it (EMWAC SMTPRS 0.83) with SMTP id <[e-mail]>; Mon, 04 Dec 2000 00:31:14 +0100
DATE: 03 Dec 00 3:38:51 PM
Message-ID: <XipCiXYnU440dz069>
SUBJECT:  Holiday Special: Don't miss the savings!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hurry!!! Time is running out.

Thinking of getting a laptop computer for the holidays, or any occasions...
Brand new name brand notebooks at up to 35% savings, compare around than
call us 1-800-644-9584. We have thousands Notebook PC, PDAs, Digital
Cameras, Parts and Accessories in stock for the holiday, anything you need,
we can get you the lower prices.

 C o m p a q
==================================================
Compaq Armada M700		$2199
Intel PIII 650 MHz, 128MB, 12.0GB, 14.1in TFT, 24X CD-ROM, 56 Kbps, 10/100
Ethernet Card, Windows NT 4.0

Compaq Presario 1200-XL125	$1379
AMD K6-2 533 MHz, 64MB , 6.0GB, 13.3in TFT, 8X DVD-ROM, 56Kbps , WIN98se

Compaq Presario 1200-XL300	$1095
Intel Celeron 600 MHz, 64MB, 6.0GB, 13in HPA, 24X CD-ROM, 56K , Windows ME

Compaq Presario 1200-XL325	$1499
Intel PIII 650 MHz, 64MB, 6.0GB, 13.3in TFT, 8X DVD-ROM, 56K , Windows ME

Compaq Presario 1700-XL360	$1799
Intel PIII 600 MHz, 64MB, 10.0GB, 14.1in TFT, 8X DVD-ROM, 56K , Windows ME


 H P
====================================================
HP Omni Book 6000	$3499
Intel PIII 850MHz , 128 MB , 20GB, 15.1in TFT, 8X DVD-ROM, 56Kbps, Windows
2000

HP Pavilion N5150	$1499
Intel PIII 600 MHz, 64MB, 10.0GB , 13.3in TFT, 8X DVD-ROM, 56Kbps, Windows
Millennium Edition

HP Pavilion N5170	$1599
Intel PIII 600 MHz , 64MB, 7.0GB , 14.1in TFT, 8X DVD-ROM, 56Kbps, 10/100
Ethernet, Windows Millennium Edition

HP Pavilion N5195	$2199
Intel PIII 700 MHz , 128MB , 20.0GB , 15.1in TFT, 8X DVD-ROM, 56Kbps, 10/100
Ethernet, Windows Millennium Edition


 S O N Y
====================================================
Sony VAIO PCG-F580 Notebook	$2099
Intel PIII 650 MHz, 64MB, 12.0GB, 15.0in TFT, 8X DVD-ROM, 56K, Windows 98se

Sony VAIO PCG-F650 Notebook	$1889
Intel PIII 600 MHz, 64MB, 12.0GB, 14.1in TFT, 8X DVD-ROM, 56Kbps, Windows ME


For more info or to place an order call:

1-800-644-9584
To Visit Our Site http://www.laptopland.com to find out more detail


This message is being sent to you in compliance with the proposed Federal
legislation for commercial e-mail (S.1618 - SECTION 301)."Pursuant to
Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by
the sender of this e-mail may be stopped at no cost to you by submitting a
request to be removed. INSTRUCTIONS- click here
mailto:[e-mail]?subject=removelist134 to be
removed.







Received: by ns.secondary.com (8.9.3/8.9.3) id FAA24681 for ietf-smime-bks; Fri, 1 Dec 2000 05:57:29 -0800 (PST)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA24676 for <[e-mail]>; Fri, 1 Dec 2000 05:57:27 -0800 (PST)
Received: from wwilliams2 (dhcp058-134.genuity.com [171.78.58.134]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id JAA20456; Fri, 1 Dec 2000 09:00:44 -0500 (EST)
From: "Walter Williams" <[e-mail]>
To: "Ahmed Bhamjee" <[e-mail]>, <[e-mail]>
Subject: RE: SMIME Freeware Library v1.8
Date: Fri, 1 Dec 2000 08:54:51 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <000001c05b95$02aef8d0$[e-mail]>
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

While that server appears to be down, you might want to look at
http://www.mozilla.org/projects/security/pki/nss/smime/ as an alternative.
This is a S/MIME toolkit developed by what used to be Netscape.

Walt Williams
Genuity

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Ahmed Bhamjee
> Sent: Friday, December 01, 2000 7:48 AM
> To: [e-mail]
> Subject: SMIME Freeware Library v1.8
>
>
> Could someone please point me to a url where I can find the SMIME Freeware
> Library v1.8. I have been trying the following url with no success:
>
> http://www.armadillo.huntsville.al.us/software/smime
>
> Thanks
> Ahmed
>



Received: by ns.secondary.com (8.9.3/8.9.3) id EAA21182 for ietf-smime-bks; Fri, 1 Dec 2000 04:48:10 -0800 (PST)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA21175 for <[e-mail]>; Fri, 1 Dec 2000 04:48:08 -0800 (PST)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Fri, 1 Dec 2000 12:49:17 +0000
Received: from ahmed (AHMED.sse.ie [193.120.32.223]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id MAA01984 for <[e-mail]>; Fri, 1 Dec 2000 12:49:16 GMT
From: "Ahmed Bhamjee" <[e-mail]>
To: <[e-mail]>
Subject: SMIME Freeware Library v1.8
Date: Fri, 1 Dec 2000 12:48:21 -0000
Message-ID: <000001c05b95$02aef8d0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C05B95.02AEF8D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C05B95.02AEF8D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Could someone please point me to a url where I can find the SMIME Freeware
Library v1.8. I have been trying the following url with no success:

http://www.armadillo.huntsville.al.us/software/smime

Thanks
Ahmed

------=_NextPart_000_0001_01C05B95.02AEF8D0
Content-Type: application/octet-stream;
	name="http---www.armadillo.huntsville.al.us-software-smime.url"
Content-Disposition: attachment;
	filename="http---www.armadillo.huntsville.al.us-software-smime.url"
Content-Transfer-Encoding: 7bit

[InternetShortcut]
URL=http://www.armadillo.huntsville.al.us/software/smime
Modified=2038EDA8945BC0019D

------=_NextPart_000_0001_01C05B95.02AEF8D0--