Blake Ramsdell | 4 Nov 04:03 2003

S/MIME Working Group Agenda for the 58th IETF

Here is the agenda for the S/MIME working group meeting at IETF 58.

Introductions               (Blake Ramsdell)
Working group status        (Blake Ramsdell)
CMS and ESS examples update (Paul Hoffman)
MSGbis and CERTbis update   (Blake Ramsdell)
KEM status                  (Blake Ramsdell)
GOST status                 (Blake Ramsdell)
SEED overview               (Jongwook Park)

Blake Ramsdell | Brute Squad Labs | 

Jim Schaad | 4 Nov 05:55 2003

RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04


I have now finished (almost) this year's work in the winery.  Items of
agreement are gone.


> > 
> > Comments are on the -05 version of the document.
> > 
> > 11.  Section 2.5.2 - where do we document SMimeCapabilities 
> for RC2? 
> > Should be a 40-bit vs 128-bit difference between these 
> which needs an 
> > ASN.1 structure and encoding.  Based on reading of this document I 
> > could not correctly encode these values.
> I believe that this definition should be in the CMSALG 
> document (but it's not).  Should we bite the bullet and just 
> stick it in this one?  I agree that it needs to be specified 
> somewhere, but I feel a bit icky about sticking it in here.

[JLS] - I agree that the best place is to put it into the CMSALG draft.
This falls into the - Yes, but we can't do it.  Since SMimeCapabilities
is not defined in the CMS document, CMSALG can't reference it.  CMSALG
must not reference the S/MIME documents.  Unless you want Russ to add
SMIMECapabilities to CMS and this to CMSALG then it must go into this
document however icky.
(Continue reading)

Peter Gutmann | 4 Nov 11:11 2003

Re: Request change in son-of-rfc2633

I wrote:

>Mozilla (and no doubt some others that didn't get any publicity) did the same
>thing, and I'm sure they didn't get asked to do that by customers.

Actually that's not right, I thought Mozilla (or at least some apps that used
the Mozilla/Gecko/NSS/whatever code base) were vulnerable because Konqueror
was vulnerable, but it turns out that this was Konqueror with khtml rather
than with kmozilla, with OpenSSL supplying the crypto.  Apologies for the

Before this gets read as "OpenSSL is vulnerable", that isn't the case either.
OpenSSL provides application-defined callbacks that can be used to override
some checks (used to handle, as one source aptly described it, "the mass of
broken certs out there").  Some apps provide callbacks that ignore all errors,
which apparently is what happened here.  Standard OpenSSL doesn't have this


Peter Hesse | 11 Nov 04:41 2003

request for change in son-of-rfc2633


I have recently run into a problem with signed emails not being able to be
verified, because of the presence of the word "From" in the first columns of
a line of the email message.  This email will serve as an example of this
potential problem.  If your email client sees this message as signed but the
signature is invalid, the next paragraph should start with the word
"From"--see if it has been modified.

From appearing as the first characters after a blank line will result in
some email delivery agents (such as sendmail or exim) escaping the
word--"From" is replaced with ">From".   The reason for this behavior has to
do with the UNIX mbox mail storage file format.  The mbox format stores
multiple messages in one file, and the messages are separated by the word
"From" as the first characters following a blank line.  Some mail delivery
agents do not have this problem (i.e. Exchange), because they do not store
messages in the mbox format.  Many do, however, resulting in a modification
of the message and the signature being invalidated.

I would like to request that this issue be more directly dealt with in
son-of-RFC2633.  (Currently, it is mentioned in the example MIME-encoded
message, but nowhere in the text.)  One recommendation might be to borrow
from RFC2015 (MIME Security with PGP), which states:
   Though not required, it is generally a good idea to use Quoted-
   Printable encoding in the first step (writing out the data to be
   signed in MIME canonical format) if any of the lines in the data
   begin with "From ", and encode the "F".  This will avoid an MTA
   inserting a ">" in front of the line, thus invalidating the

(Continue reading)

Jim Schaad | 12 Nov 17:32 2003

RE: I-D ACTION:draft-ietf-smime-examples-12.txt


There are three problems I have encountered during extracting the

1.  Example 3.1.bin has a name mismatch

2.  Example 3.2.bin has a name mismatch

3.  Example 4.5.bin appears to be missing


Jim Schaad | 12 Nov 21:18 2003

RE: I-D ACTION:draft-ietf-smime-examples-12.txt


I have the following comments on the draft:

1.  Section 3 examples passed.

2.  Section 4 - 
	Passing - 4.1, 4.2, 4.5, 4.7, 4.11
	Untested - 4.3, 4.6, 4.8
	Comments - 4.4 - Passes but also includes Alice RSA certificate.
		     4.9 - Body is not from 4.1, body is modified MIME
		     4.10 - Actual list is [unknown OID, contentHints,
smimeCapablilties, securityLabel, ContentReference,
smimeEncryptKeyPreference, mlExpansionHistory, EquivalentLabel]

3.  Section 5 - 
	Passing - 5.1, 
	Untested - 5.3, 
	Comments - 5.2 the encoded and decode examples are not the same

4. 6.0, 7.1, 7.2 passed

5.  I would like to keep section 10 from the old document.

I found that there were two example 4.4 in the old message thus the
difference between my last message where I said that 4.5 did not exist
in the binaries and the fact that I tested it in this message.  I will
(Continue reading)

Jack Lloyd | 13 Nov 13:21 2003

CMS Implementation Questions

I've been looking over the various CMS RFCs, and have a few questions, most
of which probably have obvious and simple answers, but I could use some

1) I'm pretty sure I understand how to nest CMS structures correctly, but the
   existing S/MIME examples draft doesn't have any examples of, say, compress
   then encrypt then sign. Are there any examples floating around, or, are
   there any free implementations of CMS that do this, which I could use to
   generate a few tests? (Preferably PEM or raw binary, rather than MIME, but
   I'll take what I can get).

2) In section 6.2.3 of RFC 3369, "keyIdentifier identifies the key-encryption
   key that was previously distributed to the sender and one or more
   recipients." Is there some typical mechanism for choosing this value?
   Obviously, as far as the RFC is concerned, one can do pretty much anything
   they please, but if there is a simple and commonly used method, I figure I
   might as well go with the crowd.

3) It is legal to include SignedAttributes and sign everything that way even
   when signing plain data content, correct?

4) Is the encoding of subjectKeyIdentifier in SignerIdentifier and
   RecipientIdentifier supposed to be with EXPLICIT or IMPLICIT tags? This is
   not particularly clear to me from the texts of RFCs 2630 and 3369.

5) Is the RC2 key wrap example in RFC 3217 right? For the KEK/IV/LCEKPADICV
   given there, I get:
      03 5E 97 2A B1 5C C4 C9 C4 A0 3D BA A3 5A 21 66
      67 E4 3E BC A2 67 46 AE 86 08 DB C8 9E 64 CA 29
(Continue reading)

Peter Gutmann | 13 Nov 14:14 2003

Re: CMS Implementation Questions

Jack Lloyd <lloyd <at>> writes:

>1) I'm pretty sure I understand how to nest CMS structures correctly, but the
>   existing S/MIME examples draft doesn't have any examples of, say, compress
>   then encrypt then sign. Are there any examples floating around, or, are
>   there any free implementations of CMS that do this, which I could use to
>   generate a few tests? (Preferably PEM or raw binary, rather than MIME, but
>   I'll take what I can get).

You can do it with cryptlib,,
just run the self-tests and it'll dump one of every kind of CMS message you
can think of into /tmp (you need to create this directory first if you're
running under Windows).  If I hadn't deleted them all in a cleanup about 15
minutes ago I'd send you pre-built examples.

>2) In section 6.2.3 of RFC 3369, "keyIdentifier identifies the key-encryption
>   key that was previously distributed to the sender and one or more
>   recipients." Is there some typical mechanism for choosing this value?
>   Obviously, as far as the RFC is concerned, one can do pretty much anything
>   they please, but if there is a simple and commonly used method, I figure I
>   might as well go with the crowd.

Uhh, go to the PKIX archives and read the recent thread.  Basically, this
doesn't work properly if used with certain PKIX interpretations of


(Continue reading)

Matt Bertapelle | 14 Nov 20:10 2003

v2.3 S/MIME Freeware Library (SFL) Now Available

All, DigitalNet Government Solutions has delivered the Version 2.3 S/MIME Freeware Library (SFL) source code. The SFL source code files and documents are freely available at <>. The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications. When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. It has been successfully tested using the Microsoft (MS) Windows 2000/XP, Linux and Sun Solaris 2.8 operating systems. Further enhancements, ports and testing of the SFL are still in process. Further releases of the SFL will be provided as significant capabilities are added. The SFL has been successfully used to sign, verify, encrypt and decrypt CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0 Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The v2.3 SFL uses the v2.3 Certificate Management Library (CML) and v1.6 Enhanced SNACC (eSNACC) ASN.1 C++ Library to encode/decode objects. The v2.3 SFL release includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test utilities; test drivers; and test data. All CTILs were tested as Dynamically Linked Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs were tested with the respective security libraries as shared objects using Linux and Solaris 2.8. The SFL has been successfully used to exchange signedData and envelopedData messages with the MS Internet Explorer Outlook Express v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME products. Signed messages have been exchanged with the RSA S/MAIL and WorldTalk S/MIME v2 products. The SFL has also been used to perform S/MIME v3 interoperability testing with Microsoft that exercised the majority of the features specified by RFCs 3369, 3370, 2631 and 2634. This testing included the RSA, DSA, E-S D-H, 3DES, SHA and Fortezza algorithms. We used the SFL to successfully process the SFL-supported sample data included in the S/MIME WG "Examples of S/MIME Messages" document. We also used the SFL to generate S/MIME v3 sample messages that were included in the "Examples" document. The use of the v2.3 SFL is described in the v2.3 SFL Application Programming Interface (API) and v2.3 SFL Software Design Description documents. The use of the v2.3 CTIL API is described in the v2.3 CTIL API document. v2.3 SFL includes the following enhancements (compared to v2.2 SFL and CTIL releases):
1) The SFL library now provides Compressed Data Content Type for CMS.  This is implemented as a new ContentInfo type and is an extension to the types currently defined in CMS.  Compressed data can be performed on the SignedData and EnvelopedData items without application interaction, by providing the appropriate compressDataFlag flag during the session.

2) There is a major change in how the content is stored in the CSM_CommonData object.   With the addition of Compressed Data Content Type for CMS, it was necessary to distinguish between clear content and unclear content.  CSM_CommonData now stores both clear and unclear content making the application determine which content to use according to desired processing.  See the CSM_CommonData section for the changes.


3) The SFL library now provides Password-Based Encryption for CMS.  This provides a method of encrypting data using user-supplied passwords. It is implemented as a RecipientInfo type and is an extension to the RecipientInfo Types currently defined in CMS.

4) The thread support logic was updated in the SFL and libCtilMgr.  Specifically, the CSM_CSInst::AccessCertificates() method has been removed to eliminate thread access problems. This does not affect the CSM_CtilInst class, used by the CML.  The "AccessCertificcates()" and "AccessCRLs()" methods have been removed due to thread issues.  They are described more fully in the CSM_CSInst class description.

v2.3 CTILs include the following enhancements (compared to v2.2 release): 1) Elliptic Curve functionality has been added to the sm_free3 CTIL crypto library.  This includes ECDSA and ECDH processing.

v2.3 Certificate Builder include the following enhancements since v2.2: 1) Certificate Builder has been enhanced with ECDSA certificate public/private key generation. 2) Certificate Builder has been enhanced with PKCS#12 generation logic. 3) Certificate Builder has been enhanced to generate UTF-8 strings. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows, Linux and Solaris 2.8, we may port the SFL to other operating systems. All source code for the SFL is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the SFL without paying any royalties or licensing fees. DigitalNet is developing the SFL under contract to the U.S. Government. The U.S. Government is furnishing the SFL source code at no cost to the vendor subject to the conditions of the "SFL Public License". On 14 January 2000, the U.S. Department of Commerce, Bureau of Export Administration published a new regulation implementing an update to the U.S. Government's encryption export policy <>. In accordance with the revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, the downloading of the SFL source code is not password controlled. The SFL is composed of a high-level library that performs generic CMS and ESS processing independent of the crypto algorithms used to protect a specific object. The SFL high-level library makes calls to an algorithm-independent CTIL API. The underlying, external crypto token libraries are not distributed as part of the SFL source code. The application developer must independently obtain these libraries and then link them with the SFL. The SFL uses the CML and eSNACC ASN.1 Library to encode/decode certificates, ACs, CRLs and components thereof. The CML is freely available at: <>. The SFL has been successfully tested in conjunction with the Access Control Library (ACL) that is freely available to everyone from: <>. The National Institute of Standards and Technology (NIST) is providing test S/MIME messages (created by DigitalNet) at <>. DigitalNet used the SFL to successfully process the NIST test data. NIST is using the SFL and CML as part of the NIST S/MIME Test Facility (NSMTF) that they are planning to host (see <>). Vendors will be able to use the NSMTF to help determine if their products comply with the IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. The SFL has been integrated into many applications to provide CMS/ESS security services. For example, the SFL was integrated into a security plug-in for a commercial e-mail application that enabled the application to meet the Bridge Certification Authority Demonstration Phase II requirements including implementing ESS features such as security labels. The Internet Mail Consortium (IMC) has established an SFL web page <>. The IMC has also established an SFL mail list which is used to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at the IMC web site listed above. All comments regarding the SFL source code and documents are welcome. This SFL release announcement was sent to several mail lists, but please send all messages regarding the SFL to the imc-sfl mail list ONLY. Please do not send messages regarding the SFL to any of the IETF mail lists. We will respond to all messages sent to the imc-sfl mail list. -- -- Matthew J. Bertapelle DigitalNet Government Solution, LLC
Bonatti, Chris | 17 Nov 16:21 2003

Draft S/MIME WG Notes

  Draft notes from last week's WG meeting are attached.  Comments
or corrections are welcome, of course.


IETF 58th Meeting
Hilton Hotel - Minneapolis, Minnesota
11 November 2003, 1700-1800


   The meeting was chaired by Blake Ramsdell of Brute Squad
Labs.  The other co-chair, Sean Turner of IECA, was unable to
attend.  Approximately 40 participants were in attendance.

   The Chairman introduced the agenda.  There were no comments
on the agenda from the WG.  He acknowledged that Chris Bonatti
agreed to serve as note-taker.  He asked for an official XMPP scribe,
but there were no volunteers.  So the Chairman suggested that anybody
using XMPP act on their own recognizance to highlight important
statements over that service.


   The Chairman gave an update of the status of WG activities.
He reported the following:

	There are two newly completed RFCs:

		- RFC 3560: Use of the RSAES-OAEP Key Transport
		  Algorithm in the Cryptographic Message Syntax (CMS),
		  Russ Housley, July 2003.

		- RFC 3565: Use of the Advanced Encryption Standard
		  (AES) Encryption Algorithm in Cryptographic Message
		  Syntax (CMS), Jim Schaad, July 2003.

	Reported that four I-Ds were approved and were now in the
	RFC Editor's Queue:
		- draft-ietf-smime-camellia-05
		- draft-ietf-smime-symkeydist-09
		- draft-ietf-smime-x400wrap-09
		- draft-ietf-smime-x400transport-09

	WG Last Call coming up again on:
		- draft-ietf-smime-rfc2632bis-04 (Son-of-CERT)
		- draft-ietf-smime-rfc2633bis-06 (Son-of-MSG)
		- draft-ietf-smime-examples-12

	Up and coming drafts include:
		- draft-ietf-smime-cms-rsa-kem-01
		- draft-ietf-smime-gost-00

	New draft coming in soon:
		- draft-park-cms-seed-00

	Completed milestones
		- Submittted x400wrap and x400transport drafts

	Open Milestones
		- Complete rfc2632bis and rfc2633bis 
		- Complete examples draft
		- Develop draft on RSA PSS algorithm

	Longer Term
		- WG Last Call on RSA KEM
		- Submit RSA KEM
		- Final S/MIME version 3.1 interoperability matrix

	New Milestones
		- SEED
		- GOST


   Paul Hoffman reported on the update to the CMS and ESS
Examples draft.  He noted that major revision was performed since
Vienna.  Essentially we admitted that we were in denial about a
lot of the examples, and so rethought the scope so that it took
at least two working implementations to include the case.  Thus
many examples were deleted.  There are still some outstanding
comments from Jim Schaad noting some bugs in the code.  These
should be resolved shortly.  He noted that comments are still
welcome.  At least one comment outstanding.

MSGbis and CERTbis

   Blake Ramsdell reported as the editor of MSGbis and CERTbis drafts.
He noted numerous changes from Jim Schaad (mostly editorial) had been
integrated into the document. He noted that he still needs to clear up
the "I-D Nits" issues (i.e., splitting references, etc.). He also
noted that he is waiting for a secondary validation of hex dump. Jim
Schaad is looking at this, but additional comments from others would
be helpful. He noted that there was a new issue on definition of
smimeCapabilities attribute values for the RC2 algorithm. It is not
clear that these are defined anywhere. Ideally, we would like to have
this elsewhere, but since it's kind of an afterthought we're going to
have to squeeze it into MSG. Another new issue that has been discussed
on the list is the guidance text on selection encryption algorithm.
There was some obsolete language that dealt with weaker algorithms.
Ramsdell indicated that he was revising text to update the decision
tree to lead you instead to 3DES. 

   Another new issue was clarification of the semantics of the
smime-type subtype.  The smime-type is indicated an attribute on
the Content-Type MIME header.  Current values defined in MSG
include signed-data, enveloped-data, compressed-data, and certs-
only.  The question is, what is the right way to use this.

	-	As a hint for IMAP?
	-	As a content hint for processing?

Ramsdell stated that he believed this should really reflect the
outermost wrapper that must first be processed.  Chris Bonatti
stated that he didn't have an answer to this question, but
pointed out that the x400wrap and x400transport drafts added some
new values of smime-type for signed-x400 and encrypted-x400.
While these clearly address more than just the outer wrapper,
they distinguish a different service and message spec than S/MIME
per se so there is some value.  Indicating that he was an e-mail
implementer, DABOO stated that he does not want to have to decode
the entire content to know what kind of visual indicator to
present, but he does not think that these two things are
separate.  Jim Schaad indicated that what brought this issue up
is the ambiguity of signed receipts.  In the instance of a signed-
receipt that is also encrypted, which smime-type value should be
used: the signed-receipt (defined in RFC 2634) or encrypted-data
(as per the MSG spec)?  Somebody (Blake?) noted that they have
the same issue with the SIP WG, in that they want to easily
identify data that contains SIP so that they can further process
them.  The chairman noted that he was not sure whether the
Application Area should be consulted before deciding this matter.
The WG tentatively agreed that the strawman solution is that
smime-type is more a display hint than a processing hint, and
that we will clarify this in the document.  More discussion on
the list is possible.

   Ramsdell noted that there is a PKIX issue that may require
clarifications to the language regarding the subjectKeyIdentifier
(SKI), and that he is not clear what the outcome should be.  The
problem is that use of the SKI to identify certificates is not
sufficiently unique by itself.  The reason for this seems to be
that some implementations may issue crappy SKIs that are short,
locally incremented identifiers.  We need to add language to
clarify that certificate processing when identified with SKI

	-	Be prepared for matching multiple certificates;
	-	Be prepared for some of those candidate certificates to

This would help implementations to bullet-proof against failing
in what is a predictable scenario.  Russ Housley, the Security
Area Director, stated that he agreed with most of this, but
indicated that we should preface this new text with the statement
that if the recommendations of RFC 3280 are followed (i.e., SKI
is the hash of the public key) then the overlap of these
identifiers is possible but unlikely.  This text is required
mainly because that recommendation is a SHOULD instead of a

   Ramsdell also indicated that he had made several minor updates
to the CERTbis document.  He reported that he has added
differences since 3.0 certificate profile to the document.  He
has also added credits and minor editorial fixes.


   Jim Schaad reported that he has finished the edits of the PKIX
version of PSS.  This S/MIME PSS draft should be completed
shortly.  He also indicated that the Interoperability Matrix
entries for CMS and CMSALG are finished.  He still needs to do
some editorial work to clean up the document.  The ESSbis issue
is still alive, but there has been no recent movement.


   The Chairman reported speaking to Burt Kaliski of RSA, and
noted that the KEM draft is temporarily stalled.  The KEM draft
is based on ANSI X9.44, which has not yet stabilized its ASN.1
syntax.  The KEM draft cannot progress to RFC status until
relevant X9.44 areas are stabilized.


   The Chairman reported that the GOST draft is being updated and
will be posted after the meeting.  The new draft will add
normative references to CMS and Russian law.  He noted there are
still some additional comments that need to be taken care of.
Normative reference to CPALGS is a problem.  The GOST algorithm
needs to be described in an international standard, national
standard, or RFC.  An informational RFC would be easiest.  Russ
Housley stated that he thinks they are aiming to provide such an
informative RFC for the Seoul meeting.  Paul Hoffman pointed out
that making it an RFC makes things a lot easier than the
alternatives.  Ramsdell and Housley agreed.  Another issue is
ASN.1 modules.  The -00 draft uses the X.680 version of ASN.1,
and needs to switch to X.208-88 to align with the rest of S/MIME.
There are also too many modules in the draft.  There were six
modules in the -00 version, and will be 5 in -01, but they can
still be further merged.


   Jongwook Park from KISA gave a presentation introducing the
SEED algorithm.  He noted that SEED is based on a Feistel
structure with 16 rounds.  It has a 128-bit blocksize, and
employs a 128-bit key.  He proposed publishing the SEED algorithm
description as an informational RFC prior to the Seoul meeting.
All the documentation is available now from  He invited comments from
the WG.  Park also noted that we should watch for feedback from
ISO/IEC JTC1 SC27.  The Chairman asked whether SEED was currently
being considered by ISO.  Park indicated that it was.  He noted
that he does not attend the ISO meetings, but some of his
colleagues do.  Ramsdell asked whether ISO has assigned OIDs for
the algorithm.  Park indicated that they have not.  He stated
that they were examining the strength of the algorithm, but there
had been no results yet.  Russ Housley asked whether SEED was the
Korean national algorithm.  Park responded that SEED was
mandatory in Korea.