print Print
Logo: Stiftung Secure Information and Communication Technologies SIC Stiftung Secure Information and Communication Technologies SIC

How to upgrade from IAIK-JCE and IAIK-SMIME?

IAIK-JCE contains an implementation of the PKCS#7 standard, and IAIK-SMIME was an implementation of the S/MIMEv2 protocol.  IAIK-CMS with S/MIMEv3 implements the CMS (Cryptographic Message Syntax), S/MIMEv3 and ESS (Enhanced Security Services for S/MIME) protocols. Since CMS is the successor of PKCS#7 and S/MIMEv3 is the successor of S/MIMEv2, IAIK-CMS with S/MIMEv3 succeeds both, the PKCS#7 library of  IAIK-JCE and the IAIK-SMIME library.


The API of IAIK-CMS maintains the design of IAIK-JCE and IAIK-SMIME, so that is can be used in a similar way. However, package names have been changed and enhancments/modifications have been made where required to fulfill the CMS and S/MIMEv3 protocols. The, for instance, signature contributing attributes of a PKCS#7 SignedData type are named as "authenticated attributes", whereas CMS refers to them as "signed attributes". In similar way, PKCS#7 calculates an "encrypted digest" value (since it only uses the RSA algorithm), but CMS calculates a "signature value". Thus the names of the corresponding SignedData(Stream) methods have been changed from set/getAuthenticatedAttributes to set/getSignedAttributes, and the names of the corresponding SignerInfo methods set/getEncryptedDigest have been changed to set/getSignatureValue.

As another example, PKCS#7 only used one (RSA based) RecipientInfo type for encrypting the temporary symmetric content encryption key of an EnvelopedData message. In addition to this "KeyTransRecipientInfo" type (where the content encryption key is encrypted with the public key of the recipient), CMS introduces the RecipientInfo alternatives "KeyAgreeRecipientInfo", "KEKRecipientInfo", "PasswordRecipientInfo", and "OtherRecipientInfo". To group all these types, the one and only class RecipientInfo of IAIK-JCE has become an interface in IAIK-CMS allowing to use all different RecipientInfo types in a common way.

In order to ugrade from IAIK-JCE and/or IAIK-SMIME to IAIK-CMS the most straightforward way might be to change all package names from iaik.pkcs and iaik.pkcs.pkcs7 to  iaik.cms., and all package names from to iaik.smime and then run the compiler to find and change all class and method names as required.


 IAIK-CMS contains a so-called SecurityProvider utility that centralizes all cryptographic code into one class. It can be implemented by an application to plug-in its own cryptogarphic service implementations. The PKCS#7 library contains a limited SecurityProvider version: The RSACipherProvider allows an application to use its own RSA cipher implementation for digest value en/decryption or content key en/decryption for SignerInfo or RecipientInfo objects, respectively. An application that uses this RSACipherProvider may replace it by a corresponding CMS SecurityProvider implementation by overriding any of the signature creation/verification or key encryption/decryption methods as required (see the IAIK-CMS Javadoc for more information).

Mailcap file

Because the package name of the S/MIME library has changed from to iaik.smime, it is also necessary to update the IAIK mailcap entries accordingly (see the Installation Notes contained in the IAIK-CMS distribution):

The relevant mailcap-file entries should look like

 # IAIK 'mailcap' file
 multipart/signed;; x-java-content-handler=iaik.smime.signed_content
 application/x-pkcs7-signature;; x-java-content-handler=iaik.smime.signed_content
 application/x-pkcs7-mime;; x-java-content-handler=iaik.smime.encrypted_content
 application/pkcs7-signature;; x-java-content-handler=iaik.smime.signed_content
 application/pkcs7-mime;; x-java-content-handler=iaik.smime.encrypted_content
 application/x-pkcs10;; x-java-content-handler=iaik.smime.pkcs10_content
 application/pkcs10;; x-java-content-handler=iaik.smime.pkcs10_content

print Print