You are here: NSS project page > S/MIME Toolkit
The S/MIME Toolkit provides S/MIME functionality via an API that can be integrated with a variety of MIME parsers and generators. It will support S/MIME version 3 features.
The S/MIME Toolkit cannot act as a MIME parser on its own. It includes a simple parser for testing, but final applications will need to use a MIME parser like the one developed for the Mozilla mail/news project (see libmime).
To check out the source code,
cvs -d :pserver:email@example.com:/cvsroot co mozilla/security
The library source code is located in
nss/lib/smime. Two utilities are located in
smimeis a Perl script that turns ordinary RFC822 messages into signed and/or encrypted S/MIME messages that verify and decrypt correctly in Netscape Communicator 4.7 and Microsoft Outlook.
cmsutilgenerates CMS/PKCS7 messages and is used by
You can send an automatically generated, signed email as follows:
"cat rfc822msg.txt | smime -S "nickname" -p "passwd" | mail firstname.lastname@example.org"
"nickname" is the nickname of the certificate to sign with,
"passwd" is the key database password.
The message sent to email@example.com is signed and verifies correctly with Netscape Communicator 4.7 and Microsoft Outlook.
Our current task list includes the following:
- Document a first cut at an API and begin to refine it.
- Review the API to determine fitness for inclusion into various MIME parsers, changing the API definition where necessary.
- Create a test harness that can ideally be integrated into the build process.
- Create a prioritized list of further tasks, such as: Implement Cryptographic Message Syntax (CMS) and S/MIME v3 features.
We have completed and posted the version 1.0 code to mozilla.org.
Possible applications for the new S/MIME Toolkit include:
- S/MIME support in the Mozilla mail/news client.
- S/MIME support in WebMail clients.
- EDI messaging.
- A Perl module that can be used to generate and process S/MIME messages using Perl scripts.
The S/MIME Toolkit will be implemented on top of the core NSS crypto and PKI services.
The S/MIME API will be implemented in C for several reasons:
- The existing NSS code is in C, so sticking with C maintains the same level of portability.
- Not all widely-used C++ compilers are up to the current standards.
- Some applications (especially embedded apps) may not want the C++ runtime performance overhead.
- Some of the NSS C code on which S/MIME depends may be difficult to interface with a C++ API.
- Of course, there may be some software engineering and maintenance advantages to C++, so we should not consign it to the dustbin just yet.
The overall goal for the S/MIME Toolkit is to create useful code that can be implemented in real applications. To help keep us focused on that goal, the list below shows what we want to accomplish.
The S/MIME Toolkit will...
Make S/MIME easy to use and integrate in a wide variety of MIME
parsers and generators.
We want a flexible API that anticipates the possible needs of users. For example, we need to support regular and streaming input and output.
We will need an implementation of Cryptographic Message Syntax (CMS) to get full support for cryptographic messages in non-email/MIME contexts.
Finally, we will need S/MIME-specific glue code to allow easy integration with common MIME parsers and generators.
Implement commonly used features of S/MIME v3.
The following features are currently on the "commonly used" list, in order of decreasing importance:
- DSA signatures
- Triple-DES CBC bulk encryption
- Diffie-Helman key agreement protocol
Provide an API specifically for generating and processing CMS
S/MIME is based on CMS messages, but CMS messages have many useful applications even outside the context of MIME (wallets, data storage, generic messaging, etc.).
Provide a support tool that can sign, verify, encrypt, and
decrypt S/MIME and raw CMS messages.
A toolkit just isn't easy to use if it's harder to test and verify the code than it is to write it.
- Provide a lightweight MIME parser suitable for basic testing
The Non-Goals list shows some things that could be done, but that we are explicitly excluding.
The S/MIME Toolkit will not...
Be a reference implementation for S/MIME v3.
The S/MIME Toolkit will not implement all of the features of S/MIME v3. For example, support for some parts of ESS are not planned at this time.
Parse or generate MIME headers.
The goal is to integrate with the MIME parsers/generators that have already been built, debugged, and stood the test of time.
The list below prioritizes the features to be implemented. For each feature, the S/MIME Toolkit will be able to generate or process the attribute (or feature) using an appropriate API.
The toolkit should be able to process message containing any features and attributes defined in RFC2632, RFC2633, or RFC2634 without displaying adverse behavior. Features marked with (*) are available in the current PKCS7 and i S/MIME implementations for Communicator.
- MIME Parser Interface: Input/output both in streaming and one-shot mode (* - streaming mode)
- MIME Parser Interface: both clear-signed and inline-signed messages (multipart/signed and application/pkcs7-mime)
- CMS: SignedData objects, with internal and external signatures (RFC2630 - 5) (* - external signatures)
- CMS: EnvelopedData objects (RFC2630 - 6) (*)
- SMIME: smimeCapabilities attribute
- CERT: Build list of certificates and CRLs for SignedData messages (*)
- CMS: MD5 and SHA1 digest algorithms (RFC2630 12.1.1, 12.1.2) (*)
- CMS: RSA signature algorithm (RFC2630 12.2.2) (*)
- CMS: DSA signature algorithm (RFC2630 - 12.2.1) (*)
- CMS: RSA Key Transport Protocol RFC2630 18.104.22.168) (*)
- CMS: Triple-DES CBC and RC2 CBC content encryption algorithms (RFC2630 12.4.1 and 12.4.2) (*)
- SMIME: sMIMEEncryptionKeyPreference attribute (dual key support)
- ESS: signingCertificate attribute (RFC2634 - 5)
- ESS: Triple Wrapping (RFC2634 - 1.1)
- CMS: "degenerate" SignedData objects containing certs and CRLs only (RFC2630 - 5)
- CMS: Ephemeral Static Diffie-Helman Key Agreement Protocol (ESDH) (RFC2630 22.214.171.124). This includes Triple-DES and RC2 key wrap algorithms
- CMS: EncryptedData objects (RFC2630 - 8)
The following features are lower in priority and are not likely to be included in version 1.0:CMS: Static Static Diffie Hellman Key Agreement Protocol (SSDH) (RFC2630 126.96.36.199)
- CMS: multiple signers for SignedData objects
- CMS: counter signatures (RFC2630 - 11.4)
- CMS: DigestedData objects (RFC2630 - 7)
- CMS: AuthenticatedData objects (RFC2630 - 9)
- ESS: Signed Receipt Requests and Receipts (RFC2634 - 2)
- ESS: Security Labels (RFC2634 - 3)
- ESS: contentHints attribute (RFC2634 - 2.9)
- ESS: contentIdentifier / contentReference attributes (RFC2634 - 2.7, 2.11)
- ESS: Mail List Agent (MLA) Processing (RFC2634 - 4)