2/99 SFL Interop Testing Update

All,

J.G. Van Dyke and Associates (VDA) is developing the Secure/Multipurpose
Internet Mail Extensions (S/MIME) Freeware Library (SFL) to implement the
Internet Engineering Task Force (IETF) draft S/MIME version 3 set of
specifications.  This message summarizes the interoperability testing that
VDA has conducted using the SFL.

We have used the SFL to successfully exchange signed and encrypted S/MIME v2
messages with Microsoft Outlook Express (MSOE) and Netscape Navigator.  We
used the SFL to successfully verify the signature of MSOE and Netsacpe
generated v2 signedData messages.  We used the SFL to create a signedData
message that was verified by MSOE amd Netscape.  We used the SFL to
successfully decrypt MSOE and Netscape generated v2 envelopedData messages.
We used the SFL to create an envelopedData message that was decrypted by
MSOE and Netscape.  We also used the SFL to successfully exchange a signed
and encrypted S/MIME v2 message (i.e. signedData encapsulated within
envelopedData) with MSOE and Netscape.  We have also used the SFL to
successfully exchange signed S/MIME v2 messages with RSA S/MAIL toolkit,
WorldTalk and Entrust products.  This testing is the initial step in proving
the interoperability of the current draft IETF S/MIME v3 set of
specifications with the S/MIME v2 specifications (RFC 2315, RFC 2311, RFC
2312 based on the RSA Public Key Cryptography Standard (PKCS) #7, v1.5
specification). 

VDA successfully tested the SFL at the Internet Mail Consortium
(IMC)-sponsored SecureConnect2 event held on February 23-24, 1999 in San
Jose, CA.  We focused on performing interoperability testing of some of the
proposed S/MIME v3 features between the SFL and Microsoft prototype S/MIME
v3 software.  We used the SFL to attempt to decrypt envelopedData objects
produced by Microsoft.  We focused on testing the key wrap algorithm
documented in the draft S/MIME v3 Cryptographic Message Syntax (CMS-10)
specification and the Ephemeral-Static (E-S) Diffie-Hellman (D-H) key
agreement requirements stated in the S/MIME v3 D-H Key Agreement Method
draft.  Prior to SecureConnect2 we had not completed implementing the CMS-10
key wrap algorithm in the SFL because it is currently being changed by the
IETF S/MIME Working Group.  Because of that fact we were not able to use the
SFL to achieve complete interoperability of encrypted S/MIME v3 messages
using E-S D-H, but we were able to make significant progress toward that
goal and are confident that we will be able to enhance the SFL code to
achieve interoperability.  Please note that all S/MIME v3 implementors
(including VDA) must change their software to implement the new CMS key wrap
algorithm.

At SecureConnect2, we made significant progress with testing the
KEKRecipientInfo syntax and CMS-10 key wrap algorithm with Microsoft.  We
used the SFL to successfully decrypt an envelopedData (including
KEKRecipientInfo) constructed by Microsoft.  As part of this testing, we
used the SFL to use a Triple-DES key encryption key (KEK) to unwrap a RC2
content encryption key (CEK) using the CMS-10 key wrap algorithm.  We then
used the SFL to use the CEK to decrypt the RC2-encrypted content.  We made
several enhancements to the SFL to achieve this success.  

We also made significant progress with testing the KeyAgreeRecipientInfo
syntax with Microsoft.  We were able to use the SFL to partially process an
envelopedData (including KeyAgreeRecipientInfo) constructed by Microsoft.
We compared intermediate values generated by the SFL while attempting to
decrypt the envelopedData with those generated by Microsoft when they
constructed the envelopedData.  The intermediate values matched, so we know
that we were partially interoperable.  We were never able to successfully
decrypt a message using the KeyAgreeRecipientInfo syntax because we had not
completely integrated the Triple-DES key wrap code into the SFL
KeyAgreeRecipientInfo processing.

Prior to SecureConnect2, we used the SFL to successfully ASN.1 decode S/MIME
v3 Enhanced Security Services (ESS) signedAttributes such as Signed Receipt
Requests, ESS Security Labels and Mail List Expansion History that were
produced by Microsoft.  We have also used the SFL to process ESS Signed
Receipts created by Microsoft.

At SecureConnect2, we also performed S/MIME v3 interoperability testing with
Entrust.  We were able to successfully process a S/MIME v3 SignedData
message including an ESSSecurityLabel attribute generated by Entrust.

In summary, we believe that the SecureConnect2 event was extremely valuable
and we plan to participate at the SecureConnect3 event scheduled for
September 1999.  We also plan to conduct additional interoperability testing
via e-mail. 

This testing proves that the SFL is maturing and will soon be a viable
candidate for incorporation into applications that require S/MIME v3
capabilities including the optional S/MIME v3 security features such as
security labels and signed receipts.  We plan to deliver an updated interim
SFL release which includes the enhancements made as a result of the lessons
learned at SecureConnect2 and other improvements in the SFL. 

More information regarding the SFL is available from
http://www.jgvandyke.com/services/infosec/sfl.htm,
http://www.armadillo.huntsville.al.us/software/smime and
http://www.imc.org/imc-sfl. 

Much thanks to Bob Colestock and Pierce Leonberger for testing the SFL at
SecureConnect2 and for providing input to this report.

=========================================================
John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
[email protected]
=========================================================