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
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
Russ Housley <housley(_at_)spyrus(_dot_)com> 03/15/00 12:06PM >>>
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.
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
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