Re: S/MIME v3 Interoperability Testing (was RE: S/MIMEexamples draft )

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

It occurs to me that this effort would be extremely useful in trying to 
further the interoperability testing that the PKI Forum is being set up 
to do.

What would be really great would be if we could go beyond examples, and
try to develop actual test cases.  Or maybe contribute test cases that we 
have developed internally.

As an example of the kind of obscure things that can bite you, I recently 
tried to gather up an entire set of encrypted correspondence by 
sending a encrypted message to myself with 30 or so encrypted attachments
that I dragged on to the attachment window.

Didn't work.  Only one message showed up in the attachments. So there's one 
bug to more to fix.

Why would you want to do such a thing?  For compactness and archiving ,
and perhaps to hide the plaintext headers that show who you were 
communicating with.

Bob


>>> Russ Housley <housley@xxxxxxxxxx> 03/15/00 12:06PM >>>
John:

John, as S/MIME WG chairman, I greatly appreciate your commitment.  I hope 
that other implementors will join in this effort.  Collecting this data is 
essential for the specifications to progress from Proposed Standard to 
Draft Standard, so we might as well help implementors that come behind us.

Russ

At 09:45 AM 03/14/2000 -0500, Pawling, John wrote:
>Paul (and friends),
>
>We believe that the "Examples of S/MIME Messages" document should be
>enhanced and maintained.  We believe that it is extremely valuable to have a
>set of properly formatted sample S/MIME messages which can be used to test
>S/MIME implementations.  We have used the S/MIME Freeware Library (SFL) to
>successfully process (i.e. decode, verify, decrypt) the majority of the
>samples in the document.  I use the term "the majority" because the SFL does
>not support every S/MIME v3 optional feature.  For example, the SFL does not
>support the CMS authenticatedData content type.  We have also used the SFL
>to construct sample data (such as signed receipts) to be added to the
>document.  We have automated this SFL testing (through the use or test
>drivers and configuration files) so that it can be easily repeated and
>modified by us or independently by a third party (we provide all source
>code, unencumbered).  We are willing to spend time providing sample data to
>be included in the Examples document and to provide support when there are
>questions regarding the validity of the sample data.  We are also willing to
>participate in interoperability testing with others.
>
>We apologize for not providing feedback and submitting sample data sooner.
>We have been using the SFL to perform S/MIME v3 interoperability testing
>with Microsoft that has exercised the majority of the features specified by
>RFCs 2630 (CMS), 2631 (D-H) and 2634 (ESS).  This testing has included the
>RSA, mandatory S/MIME V3 and Fortezza suites of algorithms.  We were waiting
>until we finished interoperability testing with Microsoft to submit the
>SFL-produced sample data.  Yesterday (3/13/00) we successfully completed RFC
>2634 (ESS) signed receipt interoperability testing between the SFL and
>Microsoft.  This was the last major S/MIME v3 item that needed to be tested
>between the SFL and Microsoft.  We plan to provide sample signed receipts
>for inclusion in the Examples document.  We have also performed limited
>S/MIME v3 testing with Baltimore and Entrust.
>
>We still need to perform countersignature interoperability testing.  We plan
>to pursue this testing with Microsoft.  If anybody else can process
>countersignatures, please let us know.  We are not going to wait until this
>testing is done before submitting SFL-produced sample data for inclusion in
>the Examples document.
>
>As many of you know, Jim Schaad created a detailed set of matrices to
>document the interoperabilty testing performed between various
>implementations. There is a matrix for each S/MIME v3 specification.  These
>matrices are much more detailed than the "Examples of S/MIME Messages"
>document.  We have verified that the SFL can produce and process the
>majority of the features documented in the compliance matrices.  Again, I
>use the term "the majority" because the SFL does not support every S/MIME v3
>optional feature.  We have automated this SFL testing so that it can be
>easily repeated and modified by us or independently by a third party.  We
>have developed sample objects that illustrate each feature in the matrix
>that the SFL supports.
>
>Please note that Jim Schaad's matrices are a superset of the Examples
>document.  Does the group want to include all of Jim's tests in the Examples
>document?  If so, we can provide the sample data to illustrate each feature
>in the matrix that the SFL supports.  Please note that this document would
>be huge, but it would provide a comprehensive set of test data.  What do
>others think?
>
>We will have the SFL-produced test data ready for distribution by 24 March
>2000 at the latest.
>
>============================================
>John Pawling, Director - Systems Engineering
>J.G. Van Dyke & Associates, Inc;
>a Wang Government Services Company
>john.pawling@xxxxxxxx 
>============================================
>