CMS-S/MIME

CMS-S/MIME 6.0

Communication & Messaging Security

IAIK-CMS with S/MIMEv4 is a library for the Java™ platform that implements the IETF approved CMS (Cryptographic Message Syntax, RFC 5652), S/MIME (Secure/Multipurpose Internet Mail Extensions Version 4, RFC 8551) and ESS (Enhanced Security Services for S/MIME, RFC 2634, RFC 5035) protocols.
Evaluation version
PDF Brochure
Purchase

Main Features

  • Written entirely in the Java™ language guaranteeing cross platform portability
  • Works on all JDK versions 1.2, 1.3, 1.4, Java 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19 and compatible.
  • Centralized security policy configuration
  • Stream based CMS implementation for supporting one-pass processing making it possible to handle large amounts of data without running into memory problems
  • S/MIME library compatible with the javax.mail  architecture from Oracle/Sun
  • Supports ESS TripleWrapping and arbitrary nesting of S/MIME entities

Pricing and Licensing

For current prices of IAIK-CMS, please see our price list and license conditions. IAIK-CMS is free for educational and research purposes, please see our educational/research license conditions.

See Prices

Webshop

To order the product, please

See Webshop

 Protocol Standards Compliance:

  • Implements the IETF CMS, S/MIMEv4 and ESS specifications ( RFC 5652; 5751; 2634, 5053)
  • Implements all CMS content types:
    • Data
    • Signed-data
    • Enveloped-data
    • Enveloped-data
    • Digested-data
    • Encrypted-data
    • Authenticated-data
    • Authenticated-Enveloped-Data
    • Compressed-data
  • Implements all CMS RecipientInfo types:
    • KeyTransRecipientInfo
    • KeyAgreeRecipientInfo
    • KEKRecipientInfo
    • PasswordRecipientInfo
    • OtherRecipientInfo (user pluggable)
  • Supports all algorithms required and recommended for the implemented content types: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, MD5 (digest), RSA (PKCS#1v1.5 and PKCS#1v2.1 PSS signature, PKCS#1v1.5 and PKCS#1v2.1 OAEP key transport), DSA (signature), X9.42 Ephemeral Static and Static Static Diffie Hellman – RFC 2631 (key agreement), AES Key Wrap, Triple-DES Key Wrap, RC2 Key Wrap, HMACwith3DESwrap and HMACwithAESwrap (key encryption), AES, Triple-DES CBC and RC2 CBC (content encryption), PBKDF2 with PWRI-KEK (RFC 3211, password-based encryption for CMS)
  • Can be used with any alternative algorithm fulfilling the requirements of the CMS / S/MIME protocols and supported by an installed security provider
  • Supports Elliptic Curve Cryptography (ECDSA, EdDSA, ECDH, EdDH)
  • Supports DSA with SHA-2 according to FIPS 186-4
  • Supports Camellia Encryption and Key Wrap algorithm (RFC 3657
  • Supports X.509 public key and attribute certificates
  • Supports all content types of S/MIMEv4 and ESS:
    • multipart/signed with application/pkcs7-signature
    • application/pkcs7-mime
      • signed-data
      • enveloped-data
      • authEnveloped-data
      • certs-only
      • signed-receipt (ESS)
      • application/pkcs10 from S/MIMEv2 respectively CMC (Certificate Management Messages over CMS)
      • compressed-data
  • Supports ESS TripleWrapping and arbitrary nesting of S/MIME parts
  • Supports all Enhanced Security Services specified by ESS: (RFC 2634, 5035):
    • Signing Certificates (+ V2 Signing Certificates)
    • Security Labels
    • Signed Receipts
    • Secure Mailing List
  • Supports all algorithms required by the German “Regelungen zum sicheren Austausch von EDIFACT- und Fahrplan-Übertragungsdateien sowie
    Redispatch 2.0-Prozessdaten” EDI@Energy – Regelungen zum Übertragungsweg.

Application Extensible Design:

  • Pluggable custom content-type implementations
  • Pluggable custom certification path verification
  • Pluggable custom cryptographic algorithm implementations
  • Pluggable custom canonicalization policies (S/MIME)
  • Pluggable custom security label policies (S/MIME ESS)
  • Allows application defined crypto methods

Proven Interoperability:

  • Interoperates with any CMS and S/MIME implementation
  • Backwards compatible to PKCS#7v1.5 and S/MIMEv2
  • Interoperability tested among others with clients Microsoft Outlook, Mozilla Thunderbird
  • Listed in the IETF CMS Draft Standard Implementation Report ( see http://www.ietf.org/iesg/implementation/: pdf, txt)

Cryptographic Provider Independence:

  • Can be used with any JCA/JCE 1.2 (or later) compliant cryptography provider
  • Can use several different cryptography providers at the same time
  • Provisions for easy integration of smartcards and other secure hardware devices
  • Allows plug-in of user-written JCA/JCE engines
  • Allows plug-in of user-written non-JCA/JCE compliant crypto code
  • Comes with the IAIK-JCE provider by default (included in the license)

CMS  is the IETF standardized successor of the PKCS7v1.5 protocol developed by RSA Inc.. It specifies several cryptographic mechanisms for digitally signing, digesting, authenticating or encrypting any kind of data. As main difference to PKCS#7, CMS takes care of algorithm independence and introduces additional content formats and processing rules.

S/MIMEv4, S/MIMEv3  are the IETF standardized successors of the S/MIMEv2 protocol developed by RSA Inc. It uses the cryptographic mechanisms specified by CMS for securing MIME formatted messages. As S/MIMEv2 already has been some kind of industry standard for secure email transfer over the internet, S/MIMEv4 and S/MIMEv3 adopt the amendments of CMS for becoming an internet standard. Today any notable email client like Mozilla Thunderbird or Microsoft Outlook is able to speak S/MIME.

ESS  enhances the S/MIME protocol about some additional security services that are based on the Secure Data Network System (SDNS) Message Security Protocol of the NSA, but maybe useful in many other environments, particularly business and finance applications, too.

As CMS succeeds PKCS#7v1.5 and S/MIMEv4 succeeds S/MIMEv2 and S/MIMEv3, IAIK-CMS with S/MIMEv4 is the successor library of the PKCS#7 implementation of IAIK-JCE and the S/MIMEv2 implementation of IAIK-SMIME. IAIK-CMS operates on top of the IAIK-JCE API, which is included in the license. As for IAIK-JCE, we provide Applet and WebStart Editions for IAIK-CMS, too.

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/MIMEv4 implements the CMS (Cryptographic Message Syntax), S/MIMEv4 and ESS (Enhanced Security Services for S/MIME) protocols. Since CMS is the successor of PKCS#7 and S/MIMEv4, S/MIMEv3 are the successors of S/MIMEv2, IAIK-CMS with S/MIMEv4 succeeds both, the PKCS#7 library of  IAIK-JCE and the IAIK-SMIME library.

API

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 iaik.security.smime to
iaik.smime and then run the compiler to find and change all class and method names as required.

SecurityProvider

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 iaik.security.smime 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

To, for instance, use a RSA PKCS#1v1.5 compliant smartcard for signature calculatuion only, you may extend the IAIK-CMS IaikProvider and override method calculateSignatureFromSignedAttributes, e.g.:
public class MySecurityProvider extends IaikProvider {
...
public byte[] calculateSignatureFromSignedAttributes(
AlgorithmID signatureAlgorithm,
AlgorithmID digestAlgorithm,
PrivateKey privateKey,
byte[] signedAttributes)
throws NoSuchAlgorithmException,
InvalidKeyException,
SignatureException {

byte[] signatureValue = null;
// get the implementation name: RSA?
String implementationName =
signatureAlgorithm.getImplementationName();
if (implementationName == IMPLEMENTATION_NAME_RSA) {
// let the smartcard calculate the signature value
byte[] signatureValue = …;
} else {
signatureValue =
super.calculateSignatureFromSignedAttributes(
signatureAlgorithm,
digestAlgorithm,
privateKey,
signedAttributes);
}
return signatureValue;
}
}

Now tell the IAIK-CMS libary to use your SecurityProvider implementation:

MySecurityProvider mySecurityProvider = ...;
SecurityProvider.setSecurityProvider(mySecurityProvider);

Note that you also may install a SecurityProvider per CMS object. See our

SecurityProvider  description and the IAIK-CMS Javadoc for more detailed information.
If the smartcard or HSM your are using supports the PKCS#11 standard,  you may use ourPKCS#11 provider  to access it from your Java™ application.

IAIK-CMS adopts the SecurityProvider model introduced by the IAIK-TLS library (iSaSiLk) for centralizing all cryptographic tasks into one class,
iaik.cms.SecurityProvider.The SecurityProvider model used here is similar to that of iSaSiLk except for a the following changes:

  • Because of the high dependence of CMS onto ASN.1, IAIK-CMS makes use of the ASN.1 library of the crypto toolkit IAIK-JCE; so it cannot be used without having IAIK-JCE in the classpath (which does not necessarily mean to have to use (all the) the cryptographic engines provided by IAIK-JCE; i.e. any cryptographic task may be performed by any proper cryptography provider supporting the required engine).
  • Since CMS certificate handling requires access to certificate properties not supported by the JCA certificate API, any X.509 public key certficate used for IAIK-CMS has to be supplied as iaik.x509.X509Certficate, and any attribute certificate has to be supplied as
    iaik.x509.attr.AttributeCertificate. An application wishing to use certficates from other providers may use methods convertCertificateChain and convertToAttributeCertificateChain</span > of the IAIK-JCE crypto toolkit for converting them into the IAIK X.509 representation before using them with IAIK-CMS. Please note that both, iaik.x509.X509Certificate and iaik. x509.attr.AttributeCertificate fit into the JCA certificate API because being descendants of class java.security.cert.Certificate. Unfortunately
    java.security.cert.Certificate only groups public key certificates; so iaik.x509.attr.AttributeCertificate returns
    null when calling method getPublicKey.
  • Most of the getEngine methods of the SecurityProvider class does not specify the requested engine by its name; rather the engines are requested by its AlgorithmIDs as used with CMS
  • Wheras  iSaSiLk consults the SecurityProvider for getting the required — if necessary — initialized engine and subsequently performs the cryptographic operation on the engine itself, IAIK-CMS — where appropriate — allows the SecurityProvider to do the whole cryptographic task. This shall give an SecurityProvider implementing application more independence in how to perform the cryptographic operation. When, for instance, allowing the SecurityProvider to calcualte a RSA signature value, the specific SecurityProvider implementation itself may decide to use a Cipher or Signature engine or any other way to get the Signature value (e.g. from a Smartcard). This concept provides more flexibility, but sometimes may require some knowledge about the way the CMS protocol expects a cryptographic operation has to be performed. However, in general you may not have to take care about the IAIK-CMS SecurityProvider at all because you simply can use the default SecurityProvider.

Class iaik.cms.SecurityProvider is the main class of the IAIK-CMS SecurityProvider model. It itself provides default implementations for most of the cryptographic operations required by CMS, expect for functionalities that are not available from JCA/JCE engines by default, like, for instance, Ephemeral Static Diffie Hellman. Unfortunately there is no general way to initialize a
KeyPairGenerator with algorithm parameters as required when creating a originator ESDH key pair with domain parameters matching to those of the recipient´s public key. So the default implementation of method generateKeyAgreementKeyPair(AlgorithmID keyAgreeAlgorithm, PublicKey otherKey) has to throw an exception and has to be mplemented if using another cryptographic provider than IAIK. The same applies to method createSharedKeyEncryptionKey which cannot handle an ESDHKeyAgreement in provider independent way. So at the current state it might be preferable to override all ESDH related methods when intending to use another provider than IAIK.

With class IaikProvider IAIK-CMS contains an SecurityProvider implemention for the IAIK cryptography provider of the crypto toolkit IAIK-JCE. Please note the difference: The IAIK provider is a JCA/JCE cryptography provider supplying cryptographic engines; Class IaikProvider is an IAIK-CMS SecurityProvider implementation that makes the cryptographic engines of the IAIK JCA/JCE cyrptography provider available for IAIK-CMS. Per default IAIK-CMS is configured to look if the IAIK cryptography provider is available. If yes, it uses the IaikProvider as SecurityProvider. If not it uses the default SecurityProvider implementation. Thus if you want to use the IAIK provider you do not have to take any care about the SecurityProvider setting. However, if you do not want to use the IAIK provider for some reasons (e.g. you require a specific, e.g. smartcard depending, handling for some tasks) you have two options:

Use the default SecurityProvider implementation by setting it as SecurityProvider to be used

SecurityProvider.setSecurityProvider(new SecurityProvider());

Implement your own SecurityProvider for the required cryptographic tasks and install it as SecurityProvider to be used:

MySecurityProvider mySecurityProvider = ...;
SecurityProvider.setSecurityProvider(mySecurityProvider);

If choosing the second option from above basically you may follow one of two ways for implementing your own SecurityProvider:

  1. You want to mainly use the IAIK JCE as a cryptography provider and use another provider just for a few algorithms. For example, you want to use a smartcard requiring a particular handling for RSA signature calculatuion.
  2. You do not want to use the IAIK JCE at all and use only some other provider.

In the first case you may extend the IaikProvider class, e.g.:


public class MySecurityProvider extends IaikProvider {
...
public byte[] calculateSignatureFromSignedAttributes(
AlgorithmID signatureAlgorithm,
AlgorithmID digestAlgorithm,
PrivateKey privateKey,
byte[] signedAttributes)
throws NoSuchAlgorithmException,
InvalidKeyException,
SignatureException {
byte[] signatureValue = null;
// get the implementation name: RSA?
String implementationName =
signatureAlgorithm.getImplementationName();
if (implementationName == IMPLEMENTATION_NAME_RSA) {
// let the smartcard calculate the signature value
byte[] signatureValue = ...;
} else {
signatureValue =
super.calculateSignatureFromSignedAttributes(
signatureAlgorithm,
digestAlgorithm,
privateKey,
signedAttributes);
}
return signatureValue;
}
}

If the smartcard or HSM your are using supports the PKCS#11 standard, you may use our PKCS#11 provider to access it from your Java™ application.

In the second case, if you want to use a different provider alltogether and not use the IAIK-JCE at all (for whatever reason 😉 you may start with the SecurityProvider class and override those methods where you cannot use the default implementation.
Note that you also may install a SecurityProvider per CMS object. To, for instance, use one specific SecurityProvider only for one specific
SignedDataStream object, you may use its setSecurityProvider method, e.g.:

MySecurityProvider myProvider = ...;
SignedDataStream signedData = ...;
signedData.setSecurityProvider(myProvider);

Now myProvider will be used for any cryptographic operation required by this one specific SignedDataStream object. If any of the CMS objects (SignerInfos) belonging to this SignedDataStream object needs a SecurityProvider, it will use myProvider, too; except for those, who already have installed their own SecurityProvider. However, SecurityProviders are only forwarded from “higher” to “lower” objects, e.g.: if a SignedData(Stream) object has its own SecurityProvider it forwards it to its SignerInfos objects (as long as they do not already have their own SecurityProviders), but if a SignerInfo with its own SecurityProvider is added to a SignedData(Stream) object that has no SecurityProvider installed, the SecurityProvider of the SignerInfo is not forwarded to the SignedData(Stream) object. In this case the SignedDataStream object will use the default, system-wide installed SecurityProvider (which should be available in any case).

If you want to use a specific SecurityProvider for a specific CMS object please look at the Javadoc™ if you may add it by using method
setSecurityProvider (if present), or if you already may install it via the constructor (which may required when, for instance, parsing a CMS object that needs cryptographic engines already during the parsing procedure (e.g. for digest calculation initialization when parsing a SignedData object)).

Online: Javadoc for IAIK-CMS

 

IAIK-CMS-S/MIME 6.0 – 23. December 2022
Class or Package Bug / Change / New Feature Description and Examples
iaik.cms.AuthEnvelopedData, iaik.cms.AuthEnvelopedDataStream, iaik.cms.AuthEnvelopedDataOutputStream NF

Support for ChaCha20-Poly1305 Authenticated Encryption according to RFC 8419 added.

iaik.cms.AuthEnvelopedData, iaik.cms.AuthEnvelopedDataStream, iaik.cms.AuthEnvelopedDataOutputStream NF

Support for Elliptic Curve Diffie-Hellman Key Agreement Algorithm KeyAgreeRecipientInfo with X25519 and X448 according to RFC 8418 added.

iaik.cms.AuthEnvelopedData, iaik.cms.AuthEnvelopedDataStream NF

Support for explicit mode.

iaik.cms.AuthEnvelopedData, iaik.cms.AuthEnvelopedDataStream NF

Support for explicit mode.

iaik.cms.AuthEnvelopedDataStream NF

Support for AES-CBC-CMAC.

iaik.cms.AuthEnvelopedDataStream NF

Support for stream based parsing.
iaik.cms.AuthenticateddData, iaik.cms.AuthenticatedDataStream, iaik.cms.AuthenticatedOutputStream NF

Support for Elliptic Curve Diffie-Hellman Key Agreement Algorithm KeyAgreeRecipientInfo with X25519 and X448 according to RFC 8418 added.

iaik.cms.CanonicalizeOutputStream B

Fixed zero data handling in writeTo().

iaik.cms.ContentInfoStream C

toASN1Object: use blockSize of underlying type to decide between definite and indefinite encoding.

iaik.cms.EncryptedContentInfo B

toASN1Object(): fixed explicit/implicit content encoding

iaik.cms.EncryptedContentInfoStream B

Fixed EXPLICIT/IMPLICIT reference in setMode()
iaik.cms.EncryptedData, iaik.cms.EncryptedDataStream C

Increased iteration count.

iaik.cms.EnvelopedData, iaik.cms.EnvelopedDataStream, iaik.cms.EnvelopedDataOutputStream NF

Support for Elliptic Curve Diffie-Hellman Key Agreement Algorithm KeyAgreeRecipientInfo with X25519 and X448 according to RFC 8418 added.

iaik.cms.EnvelopedData, iaik.cms.EnvelopedDataStream NF

AEAD support added.

iaik.cms.EnvelopedDataStream B

Fixed calculateVersion()
iaik.cms.IaikProvider, iaik.cms.SecurityProvider NF, C

Now allow to use IAIK-CMS also without the necessity to install the JCA Provider within the JCA Security framework.

iaik.cms.KeyAgreeRecipientInfo C

Generates ukm automatically if not supplied.

iaik.cms.SignedData, iaik.cms.SignedDataStream, iaik.cms.SignedDataOutputStream NF

Support for Edwards-Curve Digital Signature Algorithm (EdDSA; Ed25519, Ed448) according RFC 8103.

iaik.cms.RecipientEncryptedKey C

decryptKey(): check also for NULL params, encryptKey(): set keyAgreeAlg only if not included yet

iaik.cms.ecc.ECCelerateProvider C

The CMS SecurityProvider for the Elliptic Curve Library IAIK-ECCelerateECCelerateTM is now included into iaik_cms.jar. Therefore iaik_eccelerate_cms.jar is no more required and has to be removed from the classpath!
iaik.cms.ecc.ECCelerateProvider NF, C

Aligned with IAIK-CMS 6.0 to support S/MIMEv4.
iaik.cms.ecc.ECCelerateProvider C

Fixed AES, DESEde key wrap AlgorithmID parameter field encoding (aligned with RFC 3278 successor RFC 5753).
iaik.cms.ecc.ECCelerateProvider NF

Support added for key agreement schemes dhSinglePass-stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha512kdf-scheme, dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass-cofactorDH-sha256kdf-scheme, dhSinglePass-cofactorDH-sha384kdf-scheme, dhSinglePass-cofactorDH-sha512kdf-scheme added.
iaik.cms.Utils NF

Added methods createPssAlgorithmID(), createOaepAlgorithmID().

iaik.smime.* NF

Support for S/MIME v4 (RFC 8551).

iaik.smime.AuthEncryptedContent, iaik.smime.SMimeAuthEncrypted NF

Support for S/MIME (v4) authenticated encryption according to RFC 8551.
iaik.smime.encrypted_content NF

application/pkcs7-mime DataContentHandler for authenveloped-data added.

iaik.smime.ess.utils.KeyStoreDatabase NF, C

Support for certificate identifiers of type SubjectKeyID and RecipientKeyIdentifier added.

iaik.smime.ess.utils.EncryptedKeyStoreDatabase NF

KeyDatabase implementation that keeps the key entries in the base KeyStore and does not decrypt them before actually using them.

demo.smime.DumpMessage NF, C

Uses the KeyStoreDatabase utility to maintain recipient keys/certifcates by their certificate identifier.

demo.smime.basic.SMimeOaepPssDemo NF

New demo showing the use for RSA-PSS and RSA-OAEP for signing and enveloping S/MIME messages.

IAIK-CMS-S/MIM 5.1 – 5. December 2016
Class or Package Bug / Change / New Feature Description and Examples
iaik.cms.AuthenticatedData, iaik.cms.AuthenticatedDataStream, iaik.cms.AuthenticatedDataOutputStream, iaik.cms.SignedData, iaik.cms.SignedDataStream, iaik.cms.SignedDataOutputStream, iaik.cms.SignerInfo, iaik.cms.attributes.CounterSignature C

Changed ContentType attribute handling. When creating a SignedData* or AuthenticatedData* object the ContentType attribute is automatically added if not included in the provided signed/authenticated attributes. During verification now an InvalidContentTypeException is also thrown if signed attributes are present but do not contain the ContentType attribute.

When creating/verifying a CounterSignature attribute a ContentType attribute must not be included.
iaik.cms.CertificateChoices NF

Class CertificateChoices to provide explicit access to the
CMS type CerificateChoices that models several certificate types to maybe included into / got from a CertificateSet.
iaik.cms.CertificateSet NF

Methods add/get/setCertificateChoices added.
iaik.cms.CMSAlgorithmID NF

Constructor added to parse AlgorithmID from a DerInputStream.
iaik.cms.CMSAlgorithmID C

aes128_CBC, aes128_CCM, aes128_GCM:
implementation names (“AES/CBC/PKCS5Padding”, “AES/CCM/PKCS5Padding”, “AES/GCM/PKCS5Padding” or “AES128/CBC/PKCS5Padding”, “AES128/CCM/PKCS5Padding”, “AES128/GCM/PKCS5Padding”) depend on version of IAIK-JCE that is used
iaik.cms.CMSAttribute NF

Extends class iaik.asn1.structures.Attribute to can keep the encoding when parsing an attribute from an InputStream (when SignedDataInOutStream is used).
iaik.cms.attributes.CMSContentType, iaik.cms.attributes.CMSMessageDigest, iaik.cms.attributes.SigningTime C

Now override method multipleAllowed to return false
indicating that only one AttributeValue is allowed in the SET OF AttributeValue for the CMS ContentType, MessageDigest and SigningTime attribute types.
iaik.cms.EncodedAttributeValue NF

New class that represents a CMS AttributeValue together with its BER encoded representation. Maybe got from an CMSAttribute object after parsing to get the parsed encoded
representation of the attribute values (when SignedDataInOutStream is used).
iaik.cms.EnvelopedDataStream, iaik.cms.EnvelopedData, iaik.cms.EncryptedContentInfoStream, iaik.cms.EncryptedContentInfo NF

Support for explicit mode where the encrypted content maybe transmitted by other means outside the EnvelopedData/EncryptedContentInfo.
iaik.cms.ecc.IaikEccProvider NF

Support for BSI TR-03109 (“ECKA-EG”) added. Note, however, that the usage of the old IAIK-ECC library is deprecated. For ECC the new IAIK ECCelerate(TM)
toolkit shall be used. See installation guidelines.
iaik.cms.OCSPRevocationInfo NF

Implements the CMS type OtherRevocationInfoFormat for the OtherRevocationInfo format OCSP (id-ri-ocsp-response – 1.3.6.1.5.5.7.16.2) according to RFC 5940.
iaik.cms.RevocationInfoChoice NF

Class RevocationInfoChoice to provide explicit access to the
CMS type RevocationInfoChoice that models several certificate revocation information types to maybe included into / got from a RevocationInfoChoices set.
iaik.cms.RevocationInfoChoices NF

Methods for adding/setting/counting/querying general RevocationInfoChoice and OCSPRevocationInfo objects added.
iaik.cms.SecurityProvider B, C

getInputStreamCipherEngine(), getByteArrayCipherEngine(), getInputStreamAuthCipherEngine(), getByteArrayAuthCipherEngine(), getAuthCipherEngine(): set SecurityProvider for the returned engines.
iaik.cms.SecurityProvider B

Fixed reflection signature based parameter setting.
iaik.cms.SignedAttributes NF

Implements the signed attributes set of a CMS SignerInfo.
iaik.cms.SignerIdentifier NF

Implements the SignerIdentifier type of CMS SignerInfo. It is defined as ASN.1 CHOICE of IssuerAndSerialNumber or SubjectKeyIdentifier.
iaik.cms.SignatureValue NF

Provides an alternative way to get the signature value from a SignerInfo object obtained from a SignedDataInOutStream object during parsing to get the encoded representation of the signature value.
iaik.cms.SignerInfo NF

Constructor and decode method added to parse AlgorithmID from a DerInputStream.
iaik.cms.SignerInfo C

toASN1Object() keeps the sorting of the parsed signed attributes when encoding a SignerInfo again
iaik.cms.SignerInfo C

Added method removeUnsignedAttribute; declared methods addUnSignedAttribute, removeUnSignedAttribute
as deprecated
iaik.cms.SignedDataStream C

SignerInfo(s) are now parsed using DerInputStream.
iaik.cms.SignedDataStream NF

Method addDigestAlgorithm added.
iaik.cms.SignedDataStream NF

Method addSDSEncodeListener added to allow usage of more than one EncodeListener
iaik.cms.SignedDataInOutStream NF

SignedDataStream implementation that encodes a SignedData object again during parsing is done. The SignedData object may be modified before finishing the encoding.
iaik.smime.attributes.SMIMECapabilities, iaik.smime.attributes.SMIMEEncryptionKeyPreference C

Now override method multipleAllowed to return false
indicating that only one AttributeValue is allowed in the SET OF AttributeValue for the S/MIME SMIMECapabilities and SMIMEEncryptionKeyPreference attribute types.
iaik.smime.ess.ContentHints, iaik.smime.ess.ContentIdentifier, iaik.smime.ess.ESSSecurityLabel, iaik.smime.ess.MsgSigDigest, iaik.smime.ess.MLExpansionHistory, iaik.smime.ess.ReceiptRequest, iaik.smime.ess.ContentReference, iaik.smime.ess.EquivalentLabels, iaik.smime.ess.SigningCertificate C

Now override method multipleAllowed to return false
indicating that only one AttributeValue is allowed in the SET OF AttributeValue for all attribute value types specified by ESS (RFC 2634): contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory, receiptRequest, contentReference, equivalentLabels and signingCertificate (and also signingCertificateV2) attribute types.
IAIK-CMS 5.0 – 20. December 2013
Class or Package Bug / Change / New Feature Description and Examples
* C

JDK 1.1.x is no longer supported. Supported Java(TM) versions are
1.2, 1.3, 1.4, 1.5 (5.0), 1.6 (6.0), 1.7 (7.0) and compatible.
* C

Adapted to latest Internet Standard versions of CMS and S/MIME: RFC 5652 (CMS)
and RFC 5751 (S/MIME Version 3.2)
demo.cms.ecc.*, demo.smime.ecc* C

Adapted for use with new IAIK ECC library IAIK-EccelerateTM
iaik.cms.CMSAlgorithmID C

changed implementation names for some ALgorithmIDs (aes192_CBC: from “AES/CBC/PKCS5Padding” to “AES192/CBC/PKCS5Padding”, aes256_CBC: from “AES/CBC/PKCS5Padding” to “AES256/CBC/PKCS5Padding”, cms_aes192_wrap: from “AESWrapAES” to “AES192WrapAES192”, cms_aes256_wrap: from “AESWrapAES” to “AES256WrapAES256”, cms_camellia192_wrap: from “CamelliaWrapCamellia” to
“Camellia192WrapCamellia192”, cms_camellia256_wrap: from “CamelliaWrapCamellia” to “Camellia256WrapCamellia256”)
iaik.cms.AuthenticatedDataOutputStream, iaik.cms.AuthEnvelopedDataOutputStream, iaik.cms.CompressedDataOutputStream, iaik.cms.DigestedDataOutputStream, iaik.cms.EnvelopedDataOutputStream, iaik.cms.SignedDataOutputStream, C

added stream closing check to write and flush methods
iaik.cms.CMSAttribute, iaik.cms.CMSAttributes C

Concrete attribute value implementation (if available) is not created/initialized
before getAttributeValue(s) is called.
iaik.cms.KeyTransRecipientInfo, iaik.cms.KeyAgreeRecipientInfo C

Method decryptKey allows null as PrivateKey (may be useful for HSM based decryption).
iaik.cms.IaikProvider C

Method verifySignatureFromHash uses the IAIK-JCE RAWRSASSA_PKCS1_V15 Signature engine to handle PKCS1#v15 signatures containing digest algorithms with
both absent and NULL parameters.
iaik.cms.SecurityProvider C

Method verifySignatureFromHash decodes the PKCS#1 DigestInfo instead of
encoding it to handle PKCS1#v15 signatures containing digest algorithms with
both absent and NULL parameters.
iaik.cms.SecurityProvider NF

Method getSignature(String algorithm, int mode, Key key, AlgorithmParameterSpec paramSpec) added to allow parameter based Signature engine intialization.
iaik.cms.SecurityProvider NF

Method getKeyLength(Key key) added to allow provider independent calculation of key length.
iaik.cms.SecurityProvider, iaik.cms.IaikEccProvider C

Method calculateSharedSecret added to calculate a shared secret between two parties using a specific KeyAgreement algorithm.
iaik.cms.SecurityProvider C

getSignature() calls getSecureRandom() to get the SecureRandom for initializing the JCA Signature engine
iaik.cms.SecurityProvider C

getMicAlgs now supports OID strings as micalg parameters for the most well known hash algorithms
iaik.cms.SignedDataStream NF

Method removeMessageDigest added.
iaik.cms.SignerInfo C

Method getSigningCertificateAttribute, getSigningCertificateV2Attribute:
check if only one SigningCertificate, SigningCertificateV2 attribute is present and if they are single-valued.
iaik.cms.SignerInfo C

Constructors with signer certificate added to allow automatic
algorithm derivation from public key.
iaik.cms.SignerInfo C

Adapted automatic algorithm selection to NIST SP 800-57; default hash algorithm now is SHA-256
iaik.cms.SignerInfo B

toASN1Object: Fixed signature algorithm NULL/absent parameter encoding.
iaik.cms.CompressedDataStream, iaik.cms.EnvelopedDataStream, iaik.cms.EncryptedContentInfoStream, iaik.cms.SignedDataStream C

toASN1Object: allows definite length encoding
iaik.smime.BufferedLineInputStream C

read tries to read from the underlying stream if less then the requested number of bytes are available in the buffer
iaik.smime.SignedContent, iaik.smime.SMimeContent C

Method setBlockSize added to allow definite length encoding.
iaik.smime.SignedContent, iaik.smime.SMimeContent C

Workaround in method setDataHandler to avoid problems with JavaMail 1.5 when setting the DataHandler of an existing MimeMessage/MimeBodyPart as DataHandler for a new MimeMessage/MimeBodyPart. The problem is fixed in version 1.5.1 of JavaMail
iaik.smime.SignedContent, iaik.smime.SMimeSigned iaik.smime.SMimeUtil C

SigningCertificate/SigningCertificateV2 attribute added to the default signed attributes where applicable. AES-256-CBC and AES-128-CBC added to the default SMIME capabilities
attribute
iaik.smime.SMimeSigned, iaik.smime.SMimeContent C

SHA-1/rsaEncryption defaults removed (if not explicitly set, digest and signature algorithm are derived from the signer key algorithm).
iaik.smime.SMimeSigned NF

addSigner methods with signer certificate added to allow automatic algorithm derivation from public key.
iaik.smime.ess.MLReceiptPolicy B

Implements the Cloneable interface. Fixed equals method.
iaik.smime.ess.ReceiptContent B

Fixed MsgSigDigest attribute calculation in method setSigner.
iaik.smime.ess.utils.KeyStoreDatabase B

Fixed certChain null check in method addKey.
iaik.smime.ess.utils.SignedReceipt B

Fixed address list calculation in method getReceiptsToAddressList.
iaik.smime.ess.SigningCertificate(V2) C

decode keeps ASN.1 structure to keep ASN.1 structure to can verify signatures with SigningCertificateV2 attributes that contain an invalid DER encoded ESSCertIDv2 object (default hash algid included)
IAIK-CMS 4.1 – 16. October 2009
Class or Package Bug / Change / New Feature Description and Examples
* C

Where possible Hashtables are replaced by HashMaps to increase access performance especially
in multithreaded environments; for JDK 1.1.x a new jdk11x_update.jar version must be used
demo.smime.ecc.SMimeEccSuiteBDemo NF

Demo showing how to use the S/MIME library with the NSA Suite B algorithm suite (RFC 5008)
iaik.cms.ecc.IaikEccProvider NF

Support for the dhSinglePass_stdDH_sha256kdf_scheme and dhSinglePass_stdDH_sha384kdf_scheme
key encryption schemes as required by the NSA Suite B S/MIME algorithm suite (RFC 5008)
iaik.cms.AuthenticatedData, iaik.cms.AuthenticatedDataStream, iaik.cms.AuthenticatedDataOutputStream NF

Support for HMACwithAESwrap key wrap algorithm (RFC 3537).
iaik.cms.AuthEnvelopedData, iaik.cms.AuthEnvelopedDataStream, iaik.cms.AuthEnvelopedDataOutputStream NF

Implementation of the Authenticated-Enveloped-Data Content Type according to RFC 5083 for authenticated
content encryption using AES-CCM or AES-GCM (RFC 5084).
iaik.cms.ContentInfo B

Fixed EOC parsing
iaik.cms.Data, iaik.cms.EncapsulatedContentInfo C

Uses DerCoder for content parsing to support arbitrary nested octet strings
iaik.cms.EncryptedContentInfo, iaik.cms.EnvelopedData C

setInputStream now read the stream instead of throwing an “Method not supported” exception
iaik.cms.EncryptedContentInfoSream C

Additional setupCipher methods (required for AuthEnvelopedData type support)
iaik.cms.EncryptedData, iaik.cms.EncryptedDataStream, iaik.cms.EncryptedDataOutputStream NF

Support for Camellia cipher algorithm added (RFC 3657).
iaik.cms.EnvelopedData, iaik.cms.EnvelopedDataStream, iaik.cms.EnvelopedDataOutputStream, iaik.smime.EncryptedContent NF

Support for Camellia cipher and Camellia key encryption algorithm added (RFC 3657).
iaik.cms.IaikProvider NF

When used with the unltd version of IAIK-JCE (v3.17 or later), IAIK-CMS can be used with unlimited strength
cryptography even if only the default jurisdiction policy files are installed.
iaik.cms.OtherRecipientInfo B

getEncryptedKey: fixed recursive call
iaik.cms.SecurityProvider NF

getAuthCipherEngine methods and AuthCipherEngine interfaces added;
used for Authenticated-Enveloped-Data Content Type support (RFC 5083)
iaik.cms.SignedDataStream NF

decode: Now also can handle an empty content OCTET STRING
if included in explicit mode (some applications erronously may include an empty OCTET
STRING instead of omitting the eContent field)
iaik.cms.SignerInfo, iaik.cms.SignedData, iaik.cms.SignedDataStream, iaik.cms.SignedDataOutputStream, iaik.smime.SignedContent NF

Added SHA-2 support for Digital Signature Algorithm (DSA) specified by FIPS PUB 186-3.

Added support for ECDSA plain variant according to German BSI Technical Guideline TR-03111.
iaik.cms.SignerInfo NF

verifySignature: If signature verification fails with the given signed attributes
try a second time with sorted attributes
iaik.cms.SignerInfo NF

verifySignature: If signature verification fails with the given signed attributes
try a second time with sorted attributes
iaik.cms.SignerInfo C

Automatic digest- and/or signature algorithm derivation (if not explcitly set) now
also considers RSA-PSS, DSA with SHA-2 and ECSDA with SHA-2
iaik.cms.SignerInfo B

Fixed version number setting in constructor

SignerInfo(signerIdentifier, digestAlgorithm, signatureAlgorithm, privateKey)
iaik.cms.TrustVerifier NF

verifyChain: check that different consecutive certificates do not have the same signature value
(countermeasure against preimage attacks on the signature hash algorithm)
iaik.smime.SMimeParameters NF

New method setCommandMap allowing to set a MailcapCommandCap for locale use
without changing the system-wide default command map (see the Javadoc guidelines for
using this method).
IAIK-CMS 4.01 – 21. December 2007
Class or Package Bug / Change / New Feature Description and Examples
ECC NF

Support for ECDSA with SHA224, SHA256, SHA384, SHA512, RIPEMD160 added; requires version 2.16 (or later)
of the IAIK-ECC provider
iaik.smime.SignedContent B, C

micalg header update done already when adding a signer (to be recognized by any JavaMailTM version)
IAIK-CMS 4.0 – 20. September 2007
Class or Package Bug / Change / New Feature Description and Examples
demo.cms.*, demo.smime.* NF, B, C

Description and Examples
demo.cms.*, demo.smime.* NF

Demos showing how to use the IAIK-ECC and IAIK-PKCS#11 libraries with
IAIK-CMS to use ECDSA, ECDH and smartcards with CMS/SMIME, respectively.
A lot of further demos added. CMS demos splitted according to content
type membership.
iaik.cms.SignedDataOutputStream, iaik.cms.EnvelopedDataOutputStream, iaik.cms.DataOutputStream, iaik.cms.AuthenticatedDataOutputStream, iaik.cms.EncryptedDataOutputStream, iaik.cms.DigestedDataOutputStream, iaik.cms.CompressedDataOutputStream iaik.cms.ContentInfoOutputStream NF

OutputStream based implementations of the several CMS content types to encode the CMS object during the application write the content data to an output stream, e.g.:

// the output stream to which to write the signed data
OutputStream resultStream = …

// create SignedDataOutputStream
int mode = SignedDataOutputStream.IMPLICIT;
SignedDataOutputStream signedData =
new SignedDataOutputStream(resultStream, mode);
…
// add certificates, SignerInfos…
…
// write in the data to be signed
byte[] buffer = new byte[2048];
int bytesRead;
while ((bytesRead = dataInputStream.read(buffer)) != -1) {
signedData.write(buffer, 0, bytesRead);
}
// closing the stream adds the signer infos
signedData.close();
iaik.cms.AuthenticatedDataStream B

Fixed getAuthenticatedAttributes; accidently returned authenticated attributes
iaik.cms.AuthenticatedDataStream, iaik.cms.AuthenticatedData B

toASN1Object: unauthenticated attributes tagged with number 3
iaik.cms.ContentInfo NF, C

Does no more keep encoded content by default; static method keepEncodedContent
may be used to enforce to change the default behaviour and keep the encoded content
iaik.cms.ContentInfo, iaik.cms.ContentInfoStream C

Changed content type implementation class registration so that classes are not loaded before actually needed
iaik.cms.CounterSignature B, C

Fixed recursive call in methods get(Un)signedAttributes, methods add(un)SignedAttribute, getUnsignedAttributeValue added
iaik.cms.EncryptedDataStream NF, C

Additional setupCipher methods; default iteration count for pbe encryption set to 2000
iaik.cms.DigestedDataStream, iaik.cms.DigestedData NF

Method setInputStream, setContent, respectively, added
iaik.cms.EncryptedContentInfo(Stream) C

If not set, tries to get the name of the cek name from the content encryption algorithm to avoid problems due to jurisdiction policy checks
iaik.cms.IaikCCProvider NF

CMS SecurityProvider for use with the Common Criteria evaluated IAIK-JCE versions, IAIK-JCE 3.1CC, IAIK-JCE 3.15CC
iaik.cms.IaikEccProvider NF

CMS SecurityProvider for using the IAIK-ECC library to encrypt CMS and S/MIME messages based on ECDH
iaik.cms.OutputStreamCompressEngine NF

OutputStreamCompressEngine for use with CompressedDataOutputStream added
iaik.cms.OutputStreamMacEngine NF

OutputStreamMacEngine for use with AuthenticatedDataOutputStream added
iaik.cms.RecipientEncryptedKey NF

AES key wrap added
iaik.cms.SecurityProvider B

checkDomainParameters: fixed getting algorithm id from public key
iaik.cms.SecurityProvider NF

Method getOriginatorPublicKey added to parse the OriginatorPublicKey of a KeyAgreeRecipientInfo, if present
iaik.cms.SecurityProvider NF

Method getOutputStreamCompressEngine added for use with CompressedDataOutputStream
iaik.cms.SecurityProvider NF

Method getOutputStreamMacEngine added for use with AuthenticatedDataOutputStream
iaik.cms.SecurityProvider NF

verifySignatureFromHash: countermeasure against Bleichenbacher RSA signature forgery attack against signature value garbage when keys with public exponents of 3 are used (when not using IAIK-JCE 3.142 or later for RSA PKCS#1v1.5 signatures)
iaik.cms.SecurityProvider C

Changed Attribute implementation class registration so that classes are not loaded before actually needed
iaik.cms.SignedDataStream, iaik.cms.SignedData NF

New method getCertificates(CertificateIdentifier) to get the (sorted) certificate chain of some specific signer, if included
iaik.cms.SignerInfo C

get(Un)SignedAttributes: return empty array if no attributes are included
iaik.cms.SignerInfo C

Constructor with digest algorithm only does not set the signature algorithm automatically to rsaEncryption; rather it tries to derive the signature algorithm (and digest algorithm — if not set) from the private key algorithm
iaik.cms.SignerInfo NF

Support for SigningCertificateV2 attribute (methods getSigningCertificateV2Attribute,

isSignerCertificate)
iaik.smime.BinaryCanonicalizer NF

New canonicalizer that does not canonicalize the contents; to be used in environments where no canonicalization is needed, for instance when transfering multipart/signed S/MIME messages over HTTP (as, e.g., done by AS2)
iaik.smime.EncryptedContent NF

Method setupCipher added to allow an application to initialize the cipher for decryption with the (already decrypted) symmetric content encryption key
iaik.smime.SignedContent C

Performance improvements by using new buffering and canonicalization meachanisms
iaik.smime.SMimeParameters NF

New method setTempDirectory allows to configure a temporary directory to avoid memory problems by temorarily writing contents to a file during message processing
iaik.smime.SharedFileInputStream, iaik.smime.SharedByteArrayInputStream NF

New shared streams used for performance improvements
iaik.smime.ess.MLData B

Fixed equals method
iaik.smime.ess.ESSCertIDv2, iaik.smime.ess.SigningCertificateV2 NF

Implementation of RFC 5035 to support hash algorithm agility for the SigningCertificateV2 attribute
IAIK-CMS 3.2 – 11. February 2005
Class or Package Bug / Change / New Feature Description and Examples
demo.cms.* NF

Demos showing how to use the IAIK-ECC and IAIK-TSP libraries with IAIK-CMS to use ECDSA as signaure algorithm and adding a TimeStampToken attribute to a SignedData object, respectively.
demo.smime.ess.* NF

SecurityLabel and SigningCertificate attribute demos added.
iaik.cms NF

Adopted to most recent standard specification (RFC 3852)
iaik.cms.CertificateSet B

Fixed tag in AttributeCertificate encoding.
iaik.cms.SignerInfo B

Parameters field must be absent only for DSA in encoding of signature algorithm (not for ECDSA).
iaik.smime NF

Adopted to most recent standard specification (RFC 3851)
iaik.smime.encrypted_content B, C

If header parsing failes, tries to parse content type from encoding.
iaik.smime C

SignedContent, EncryptedContent, CompressedContent: Allow/Recommend to call methods setContentHeaders/setContentContentTransferEncoding before setting the content (to avoid header update overhead during the saveChanges run).
IAIK-CMS 3.1 – 1. July 2004
Class or Package Bug / Change / New Feature Description and Examples
ALL NF, B, C

A lot of changes and new features, some bug fixes throughout the library. Full ESS (Enhanced Security Services, RFC 2634) support added. Authenticated-data content type and Compressed-data content type (RFC 3274) added. PasswordRecipientInfo (RFC 3211) and OtherRecipientInfo added. S/MIMEv3.1 ContentType application/pkcs7-mime compressed-data added. New SDSEncodeListener interface allows to update (e.g. add attributes like time stamp or counter signature) a SignedDataStream during the encoding phase (also when verifying and encoding an already existing SignedData again). Improved attribute handling.
IAIK-CMS 3.0 Beta 1 – 18. May 2001
Class or Package Bug / Change / New Feature Description and Examples
demo.cms NF

CMS demo examples
demo.smime NF

S/MIME demo examples
iaik.cms NF

Implements the Cryptographic Message Syntax (CMS, RFC 2630); succeeds the PKCS#7 library of IAIK-JCE
iaik.smime NF

Implements the S/MIME Version 3 standard; succeeds IAIK-S/MIMEv2
IAIK-S/MIME 2.6 – 30. June 2000
Class or Package Bug / Change / New Feature Description and Examples
demo.* NF, C

The demo class files have been separated from the library. Now the following jar files are available: iaik_smime.jar and iaik_smime_demo.jar.
IAIK-S/MIME 2.6 Beta 1 – 23. December 1999
Class or Package Bug / Change / New Feature Description and Examples
iaik.security.smime.Canonicalizer NF

Interface that allows an application to implement its own canonicalization strategy. The canonicalization scheme will come into effect when activating the new Canonicalizer by calling the static setCanonicalizer method of class SMimeParameters. Ougoing messages are processed by the Canonicalizer when modelling body parts and multiparts by classes SMimeBodyPart and SMimeMultipart or when setting the text of a multipart/signed message by method setText of class SignedContent. Ingoing multipart/signed messre also processed by the canonicalizer.
iaik.security.smime.SMimeParameters NF

New method setCanonicalizer for enabling an application-written canonicalizer.
iaik.security.smime.DefaultCanonicalizer NF

Default implementation of the Canonicalizer interface for ensuring that and only appaer together as for non binary entities. On ougoing messages only enabled when modelling body parts and multiparts by classes SMimeBodyPart and SMimeMultipart or when setting the text of a multipart/signed message by method setText of class SignedContent. On ingoing messages only used for the contents part of multipart/signed messages.
iaik.security.smime.EncryptedContent NF

New method setContentContentTransferEncoding for allowing to explicitly set the content transfer encoding of the inner content. This method may be useful, for instance, when setting the content by means of method setText and wishing to apply another content transfer encoding than allocated by the JavaMail™ API.
iaik.security.smime.EncryptedContent NF

New method getRecipientInfoIndex(X509Certificate recipientCertificate) for searching for the recipient index belonging to the recipient certificate.
iaik.security.smime.EncryptedContent B

Content with another content transfer encoding than 7bit, 8bit may have not been encoded as desired.
iaik.security.smime.JMailSigned C

Only extends class SMimeSigned to be used for SignedContent to ensure that for a multipart/signed message the content body is piped through the DigestStream before writing the signature. Allows to use SMimeSigned without dependence on JavaMail™ code.
iaik.security.smime.pkcs10_content NF

DataContentHandler for type application/pkcs10 to handle certificate request messages.
iaik.security.smime.PKCS10Content NF

Class for sending and parsing application/pkcs10 messages conatining a PKCS#10 certification request.
iaik.security.smime.SignedContent NF

New method setContentContentTransferEncodingfor allowing to explicitly set the content transfer encodingof the inner content. This method may be useful, for instance,when setting the content by means of method setText and wishingto apply another content transfer encoding than allocated bythe JavaMail™ API.
iaik.security.smime.SignedContent B

Content with another content transfer encodingthan 7bit, 8bit may have not been encoded as desired.
iaik.security.smime.SignedContent C

Multipart/signed messages where the contentsitself is composed of parts have to be built with classes SMimeBodyPartand SMimeMultipart for ensuring proper canonicalization.
iaik.security.smime.SMimeBodyPart NF, C

New Constructor SMimeBodyPart to be used forcreating body parts for multipart/signed messages.
iaik.security.smime.SMimeBodyPart C

If the SMimeBodyPart representing the first (contents)part of a multipart/signed message contains a multipart noweach of the body parts of this multipart separately is canonicalized.
iaik.security.smime.TrustVerifier NF

New class allowing simple certificate verifying,trust checking and check of Email addresses of From: headerand certificate.
demo.smime.keystore NF

Special keystore files (SMimeKeyStore, SetupSMimeKeyStore,SMimeKeyStoreConstants)used by the IAIK-S/MIME demos to distinguish between signingandencryption certificates.
IAIK-S/MIME 2.52 – 11. August 1999
Class or Package Bug / Change / New Feature Description and Examples
iaik.security.smime B

When no or only one certificate is included, a wrong hash may have been sent within the authenticated attributes; and therefore verification must fail.
iaik.security.smime.SignedContent B

Method getContentInputStream has not returned the message as required.
iaik.security.smime.SMimeParameters NF

Allows to decide whether to use old (starting with an “x”) or new S/MIME content types when creating a new S/MIME message.
iaik.security.smime.SignedContent B

When parsing a message now the new S/MIME content types are also recognized.
iaik.security.smime.SignedContent B

When parsing a message where the content-transfer-encoding is binary or 8Bit, no Base64 decoding is performed.
iaik.security.smime.CanonicalizeOutputStream B

A single 0x0D now also is forced to 0x0D 0x0A.
iaik.security.smime.SignedContent NF

Setting of smime-type parameter (“signed-data”, “certs-only”); creating of certs-only messages;
iaik.security.smime.SignedContent NF

New method setHeaders(Message) for setting content-disposition and filename parameters for implicit messages (in equivalence to EncryptedContent)
iaik.security.smime.SignedContent NF

New methods setCRLs(..) and getCRLs() for setting/getting the SignedData´s crls field
iaik.security.smime.EncryptedContent NF

New Method setSMimeType() for setting the smime-type parameter (“enveloped-data”
IAIK-S/MIME 2.51 – 15. June 1999
Class or Package Bug / Change / New Feature Description and Examples
iaik.security.smime.SignedContent B

A nullpointer exception or misleading verification error message may occur when parsing a data source returning no smime-type. This has been fixed.
iaik.security.smime.EncryptedContent B

When using the setDataHandler(…) method for supplying a multipart object the body headers had not been updated accurately. This has been fixed.
IAIK-S/MIME 2.5 – 30. April 1999
Class or Package Bug / Change / New Feature Description and Examples
iaik.security.smime NF, B, C

Now detached from the IAIK-JCE toolkit and available as own distribution. Several bugs fixed. Gerneral support for certs-only messages for distributing certificates.
iaik.security.smime.SMimeMailer NF

A simple class for sendingS/MIME emails.
demo NF

Redisigned demo library.
IAIK-JCE 2.5 beta1 – 23. December 1998
Class or Package Bug / Change / New Feature Description and Examples
iaik.security.smime NF

Now support for the Sun.javax.mail.API. The following types of e-mails are supported: signed, encrypted, signed and encrypted
IAIK-JCE 2.0 Beta2 – 2. February 1998
Class or Package Bug / Change / New Feature Description and Examples
iaik.security.smime NF

Package for dealing with S/MIME messages.At this time only S/MIME encrypted is implemented.
Show more

Some signature applications seem to use different parameter encoding practices (NULL or absent parameter) for digestAlgorithm(s) fields and DigestInfo encoding during signature calculation for one and the same SignedData/SignerInfo. IAIK-CMS 4.0 uses an raw RSA Signature engine for signature verification and assumes the same parameter encoding for digestAlgorithm(s) field and DigestInfo encoding. With IAIK-CMS 4.0 the problem can be fixed by using, e.g. an Cipher based SecurityProvider like the IaikCCProvider:

SecurityProvider.setSecurityProvider(new IaikCCProvider());

IAIK-CMS 5.0 fixes this problem by using a special raw Signature engine checking both encoding practices.

There are some application(s) which erroneously encode the SigningCertificateV2 attribute by including the hashAlgorithm field of the ESSCertIDv2 component even if the default hash algorithm (SHA-256) is used. Since default components have to be omitted the encoding is different and signature verification will fail. The current version of IAIK-CMS (5.0) fixes this problem by keeping the encoding when parsing a SigningCertificateV2 attribute. With versions prior 5.0 you may write and register a SigningCertificateV2 attribute implementation that keeps the encoding.

The ProcessMessageDemo takes an existing (received) message and signs/encrypts it anew. Due to a bug in JavaMail™ 1.5 the Content-Type and Content-Transfer-Encoding headers may not be properly updated when copying the DataHandler from an existing to a new message. The bug will be fixed in the next version of JavaMail™. The next version of IAIK-CMS (5.0) will contain a workaround to solve this problem for JavaMail™ 1.5.

There seems to be a bug in the BASE64 decoding routine used by JavaMail™ version 1.3.3. For that reason base64 encoded MIME parts cannot be properly decoded and you may get exception messages like the one described in the following bug report. Unfortunetaly we cannot provide a workaround for this problem since base64 decoding is invoked inside the JavaMail™ library. You may use a JavaMail™ version prior 1.3.3 (e.g. 1.3.2) or you may switch to JavaMail™ 1.4 which already has fixed the problem. However, please note that JavaMail™ 1.4 only can be used with JDK 1.4 or later.

    java.security.SignatureException: Signature verification error: iaik.cms.CMSSignatureException: SignerInfo does not exist. Wrong index.
at demo.smime.DumpMessage.dump(DumpMessage.java:118)
at demo.smime.SMimeV3Demo.start(SMimeDemo.java:213)
at demo.smime.SMimeV3Demo.main(SMimeDemo.java:882)
java.lang.RuntimeException
at demo.smime.SMimeV3Demo.start(SMimeDemo.java:465)
at demo.smime.SMimeV3Demo.main(SMimeDemo.java:882)

A: Due to a bug in the BASE64 decoding routine used by JavaMail™ version 1.3.3 the SignedData object cannot be decoded corretly. For that reason it is not possible to verify the signature. Unfortunetaly we cannot provide a workaround for this problem since base64 decoding is invoked inside the JavaMail™ library. You may a JavaMail™ version prior 1.3.3 (e.g. 1.3.2) or you may switch to JavaMail™ 1.4 which already has fixed the problem. However, please note that JavaMail™ 1.4 only can be used with JDK 1.4 or later.

Content-Type: multipart/mixed;
boundary="----=_Part_0_1551868.1088869295069"

——=_Part_0_1551868.1088869295069
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello world !
——=_Part_0_1551868.1088869295069–

For some reason Outlook Express and Outlook seem to have problems with multipart/signed messages where the content consists of a multipart/mixed MIME entity that contains only one body part. However, when creating an implicit signed message (application/pkcs7-mime), Outlook and Outlook Express are able to handle the message, too. So you may either create an application/pkcs7-mime message:

boolean implicit = true;
SignedContent sc = new SignedContent(implicit);

or not to use a multipart/mixed entity that only consists of one body part with an explicit SignedContent object (multipart/signed). For your sample you may immediately call method setText of class SignedContent:

boolean implicit = false;
SignedContent sc = new SignedContent(false);
sc.setText(“Hello world !”);

For some reason some versions of Outlook Express seem to have problems when verifying the signatures of nested multipart/signed messages. You may use the application/pkcs7-mime (signed-data) content type by creating implicit SignedContent objects.

Some versions of Outlook Express and Outlook 98 are not able to recognize the encryption certificate included in a signed message when separate certificates are used for signing/encryption. Some versions of MS Outlook Express even complain that the contents maybe altered. The reason for this strange behaviour is that MS uses a private attribute (OID “1.3.6.1.4.1.311.16.4”) for identifying the encryption certificate of the sender by issuer name and serial number. When adding signer information to your SignedContent object you will have to ensure to use a proper addSigner method that creates and adds the required private MS attribute to the corresponding SignerInfo object (see Javadoc™ of class SignedContent for choosing the right addSigner method). It might be noticed that S/MIMEv3 introduced new attribute (SMIMEEncryptionKeyPreference) allowing to include identification information similar to the Microsoft attribute. You may allow method addSigner to set this attribute, too.

The mapping between S/MIME types and data content handlers is done by a RFC1524 mailcap file which is included in the IAIK-S/MIME distribution (named “mailcap”) to be copied into the lib directory of your Java™Home (e.g. C:/Java/j2re1.4.2/lib). You alternatively may register the IAIK-S/MIME mailcap file dynamically by using the default command map:

String mailcapFileName = …;
MailcapCommandMap mc = new MailcapCommandMap(mailcapFileName);
CommandMap.setDefaultCommandMap(mc);
Or you may add the IAIK mailcap entries to the default mailcap command map, e.g.:

MailcapCommandMap mc = (MailcapCommandMap)CommandMap.getDefaultCommandMap();

mc.addMailcap(“multipart/signed;; x-java-content-handler=iaik.smime.signed_content”);
mc.addMailcap(“application/x-pkcs7-signature;; x-java-content-handler=iaik.smime.signed_content”);
mc.addMailcap(“application/x-pkcs7-mime;; x-java-content-handler=iaik.smime.encrypted_content”);
mc.addMailcap(“application/pkcs7-signature;; x-java-content-handler=iaik.smime.signed_content”);
mc.addMailcap(“application/pkcs7-mime;; x-java-content-handler=iaik.smime.encrypted_content”);
mc.addMailcap(“application/x-pkcs10;; x-java-content-handler=iaik.smime.pkcs10_content”);
mc.addMailcap(“application/pkcs10;; x-java-content-handler=iaik.smime.pkcs10_content”);

CommandMap.setDefaultCommandMap(mc);
For a more detailed description of mailcap handling consult the Javadoc™ of the Activation Framework.

java.lang.ClassCastException: iaik.asn1.structures.Name
at sun.security.pkcs.PKCS7.getCertificate(PKCS7.java:569)
at sun.security.pkcs.SignerInfo.getCertificate(SignerInfo.java:198)
at sun.security.pkcs.SignerInfo.verify(SignerInfo.java:324)
at sun.security.pkcs.PKCS7.verify(PKCS7.java:463)
at sun.security.pkcs.PKCS7.verify(PKCS7.java:480)
at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:143)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:279)

Some versions of the JavaMail™ jar files (e.g. mail.jar) and the Java™ Activation Framework jar files (activation.jar) may be signed. Due to a bug (hardcoded cast to SUN´s distinguished name implementation) in the jar file verification mechanism of some JDK versions it may be necessary to have SUN based DSA/RSA capable providers installed before the IAIK provider when the jar file verification takes places. However, you still may use IAIK as first provider if you take care to load classes from the mail.jar and activation.jar files before installing the IAIK provider. For instance, you may register the mailcap file and create a Session object, e.g.:

// register content data handlers for S/MIME types
MailcapCommandMap mc = new MailcapCommandMap(“mailcap”);
CommandMap.setDefaultCommandMap(mc);
// create some properties and get the default Session
Properties props = new Properties();
props.put(“mail.smtp.host”, host);
Session session = Session.getDefaultInstance(props, null);

// now install IAIK as first provider
IAIK.addAsProvider();

Now MailcapCommandMap and Session are loaded from activation.jar and mail.jar, respectively, and the signatures of these two jar files are verified before the IAIK provider is installed.

Due to a bug in the JDK jar file verification mechanism it may be necessary that the original SUN provider is installed as first provider. So insert the IAIK provider as second provider and explicitly request an IAIK engine when calling getInstance:

Security.insertProviderAt(new IAIK(), 2);
Cipher c = Cipher.getInstance(“DES/CBC/PKCS5Padding”, “IAIK”);
Alternatively you may use static method addAsJDK14Provider of the IAIK-JCE provider main class. This method uses a work around that allows to use IAIK as first provider for JDK1.4, too:

IAIK.addAsJDK14Provider();

With JDK1.4 the JCE framework (JAVAX CRYPTO) has been incorporated into the standard JDK. Because of export regulations a JCE provider only maybe used with JDK1.4 (or JCE 1.2.1) if it is signed. IAIK-JCE provides signed and unsigned versions of its jar files (iaik_jce.jar, iaik_jce_full.jar). Using the unsigned version with JDK 1.4 will cause the ExceptionInInitializerError “Cannot set up certs for trusted CAs”. Please use the signed jar file.

You also may ensure that the right JCE policy files are installed in the lib/security directory. due to import control restrictions of some countries, JDK1.4 per default comes with jurisdiction policy files allowing “strong” but limited cryptography; so keys that exeed the allowed strength are not allowed to be used by this policy. If you are entitled to do so, you may download and install an “unlimited strengh” version of these files. Usually, you can download them from the same web page as the Java™ runtime or JDK. Usually these files have to be put into the lib/security subdirectory of your JRE; however some VMs (e.g. IBM) may require to put them into another directory (e.g. lib/ext). Please read the installation instructions that come with these policy files. Take care to install these policy files in the correct JRE installation. Note that many JDKs install two JREs by default and that the one which is used by default is not(!) the one embedded in the JDK directory. To see which one is used, you may type java™ -verbose -version.

Some signature applications seem to use different parameter encoding practices (NULL or absent parameter) for digestAlgorithm(s) fields and DigestInfo encoding during signature calculation for one and the same SignedData/SignerInfo. IAIK-CMS 4.0 uses an raw RSA Signature engine for signature verification and assumes the same parameter encoding for digestAlgorithm(s) field and DigestInfo encoding. With IAIK-CMS 4.0 the problem can be fixed by using, e.g. an Cipher based SecurityProvider like the IaikCCProvider:

SecurityProvider.setSecurityProvider(new IaikCCProvider());

IAIK-CMS 5.0 fixes this problem by using a special raw Signature engine checking both encoding practices.

There are some application(s) which erroneously encode the SigningCertificateV2 attribute by including the hashAlgorithm field of the ESSCertIDv2 component even if the default hash algorithm (SHA-256) is used. Since default components have to be omitted the encoding is different and signature verification will fail. The current version of IAIK-CMS (5.0) fixes this problem by keeping the encoding when parsing a SigningCertificateV2 attribute. With versions prior 5.0 you may write and register a SigningCertificateV2 attribute implementation that keeps the encoding.

The ProcessMessageDemo takes an existing (received) message and signs/encrypts it anew. Due to a bug in JavaMail™ 1.5 the Content-Type and Content-Transfer-Encoding headers may not be properly updated when copying the DataHandler from an existing to a new message. The bug will be fixed in the next version of JavaMail™. The next version of IAIK-CMS (5.0) will contain a workaround to solve this problem for JavaMail™ 1.5.

There seems to be a bug in the BASE64 decoding routine used by JavaMail™ version 1.3.3. For that reason base64 encoded MIME parts cannot be properly decoded and you may get exception messages like the one described in the following bug report. Unfortunetaly we cannot provide a workaround for this problem since base64 decoding is invoked inside the JavaMail™ library. You may use a JavaMail™ version prior 1.3.3 (e.g. 1.3.2) or you may switch to JavaMail™ 1.4 which already has fixed the problem. However, please note that JavaMail™ 1.4 only can be used with JDK 1.4 or later.

    java.security.SignatureException: Signature verification error: iaik.cms.CMSSignatureException: SignerInfo does not exist. Wrong index.
at demo.smime.DumpMessage.dump(DumpMessage.java:118)
at demo.smime.SMimeV3Demo.start(SMimeDemo.java:213)
at demo.smime.SMimeV3Demo.main(SMimeDemo.java:882)
java.lang.RuntimeException
at demo.smime.SMimeV3Demo.start(SMimeDemo.java:465)
at demo.smime.SMimeV3Demo.main(SMimeDemo.java:882)

A: Due to a bug in the BASE64 decoding routine used by JavaMail™ version 1.3.3 the SignedData object cannot be decoded corretly. For that reason it is not possible to verify the signature. Unfortunetaly we cannot provide a workaround for this problem since base64 decoding is invoked inside the JavaMail™ library. You may a JavaMail™ version prior 1.3.3 (e.g. 1.3.2) or you may switch to JavaMail™ 1.4 which already has fixed the problem. However, please note that JavaMail™ 1.4 only can be used with JDK 1.4 or later.

Content-Type: multipart/mixed;
boundary="----=_Part_0_1551868.1088869295069"

——=_Part_0_1551868.1088869295069
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello world !
——=_Part_0_1551868.1088869295069–

For some reason Outlook Express and Outlook seem to have problems with multipart/signed messages where the content consists of a multipart/mixed MIME entity that contains only one body part. However, when creating an implicit signed message (application/pkcs7-mime), Outlook and Outlook Express are able to handle the message, too. So you may either create an application/pkcs7-mime message:

boolean implicit = true;
SignedContent sc = new SignedContent(implicit);

or not to use a multipart/mixed entity that only consists of one body part with an explicit SignedContent object (multipart/signed). For your sample you may immediately call method setText of class SignedContent:

boolean implicit = false;
SignedContent sc = new SignedContent(false);
sc.setText(“Hello world !”);

For some reason some versions of Outlook Express seem to have problems when verifying the signatures of nested multipart/signed messages. You may use the application/pkcs7-mime (signed-data) content type by creating implicit SignedContent objects.

Some versions of Outlook Express and Outlook 98 are not able to recognize the encryption certificate included in a signed message when separate certificates are used for signing/encryption. Some versions of MS Outlook Express even complain that the contents maybe altered. The reason for this strange behaviour is that MS uses a private attribute (OID “1.3.6.1.4.1.311.16.4”) for identifying the encryption certificate of the sender by issuer name and serial number. When adding signer information to your SignedContent object you will have to ensure to use a proper addSigner method that creates and adds the required private MS attribute to the corresponding SignerInfo object (see Javadoc™ of class SignedContent for choosing the right addSigner method). It might be noticed that S/MIMEv3 introduced new attribute (SMIMEEncryptionKeyPreference) allowing to include identification information similar to the Microsoft attribute. You may allow method addSigner to set this attribute, too.

The mapping between S/MIME types and data content handlers is done by a RFC1524 mailcap file which is included in the IAIK-S/MIME distribution (named “mailcap”) to be copied into the lib directory of your Java™Home (e.g. C:/Java/j2re1.4.2/lib). You alternatively may register the IAIK-S/MIME mailcap file dynamically by using the default command map:

String mailcapFileName = …;
MailcapCommandMap mc = new MailcapCommandMap(mailcapFileName);
CommandMap.setDefaultCommandMap(mc);
Or you may add the IAIK mailcap entries to the default mailcap command map, e.g.:

MailcapCommandMap mc = (MailcapCommandMap)CommandMap.getDefaultCommandMap();

mc.addMailcap(“multipart/signed;; x-java-content-handler=iaik.smime.signed_content”);
mc.addMailcap(“application/x-pkcs7-signature;; x-java-content-handler=iaik.smime.signed_content”);
mc.addMailcap(“application/x-pkcs7-mime;; x-java-content-handler=iaik.smime.encrypted_content”);
mc.addMailcap(“application/pkcs7-signature;; x-java-content-handler=iaik.smime.signed_content”);
mc.addMailcap(“application/pkcs7-mime;; x-java-content-handler=iaik.smime.encrypted_content”);
mc.addMailcap(“application/x-pkcs10;; x-java-content-handler=iaik.smime.pkcs10_content”);
mc.addMailcap(“application/pkcs10;; x-java-content-handler=iaik.smime.pkcs10_content”);

CommandMap.setDefaultCommandMap(mc);
For a more detailed description of mailcap handling consult the Javadoc™ of the Activation Framework.

java.lang.ClassCastException: iaik.asn1.structures.Name
at sun.security.pkcs.PKCS7.getCertificate(PKCS7.java:569)
at sun.security.pkcs.SignerInfo.getCertificate(SignerInfo.java:198)
at sun.security.pkcs.SignerInfo.verify(SignerInfo.java:324)
at sun.security.pkcs.PKCS7.verify(PKCS7.java:463)
at sun.security.pkcs.PKCS7.verify(PKCS7.java:480)
at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:143)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:279)

Some versions of the JavaMail™ jar files (e.g. mail.jar) and the Java™ Activation Framework jar files (activation.jar) may be signed. Due to a bug (hardcoded cast to SUN´s distinguished name implementation) in the jar file verification mechanism of some JDK versions it may be necessary to have SUN based DSA/RSA capable providers installed before the IAIK provider when the jar file verification takes places. However, you still may use IAIK as first provider if you take care to load classes from the mail.jar and activation.jar files before installing the IAIK provider. For instance, you may register the mailcap file and create a Session object, e.g.:

// register content data handlers for S/MIME types
MailcapCommandMap mc = new MailcapCommandMap(“mailcap”);
CommandMap.setDefaultCommandMap(mc);
// create some properties and get the default Session
Properties props = new Properties();
props.put(“mail.smtp.host”, host);
Session session = Session.getDefaultInstance(props, null);

// now install IAIK as first provider
IAIK.addAsProvider();

Now MailcapCommandMap and Session are loaded from activation.jar and mail.jar, respectively, and the signatures of these two jar files are verified before the IAIK provider is installed.

Due to a bug in the JDK jar file verification mechanism it may be necessary that the original SUN provider is installed as first provider. So insert the IAIK provider as second provider and explicitly request an IAIK engine when calling getInstance:

Security.insertProviderAt(new IAIK(), 2);
Cipher c = Cipher.getInstance(“DES/CBC/PKCS5Padding”, “IAIK”);
Alternatively you may use static method addAsJDK14Provider of the IAIK-JCE provider main class. This method uses a work around that allows to use IAIK as first provider for JDK1.4, too:

IAIK.addAsJDK14Provider();

With JDK1.4 the JCE framework (JAVAX CRYPTO) has been incorporated into the standard JDK. Because of export regulations a JCE provider only maybe used with JDK1.4 (or JCE 1.2.1) if it is signed. IAIK-JCE provides signed and unsigned versions of its jar files (iaik_jce.jar, iaik_jce_full.jar). Using the unsigned version with JDK 1.4 will cause the ExceptionInInitializerError “Cannot set up certs for trusted CAs”. Please use the signed jar file.

You also may ensure that the right JCE policy files are installed in the lib/security directory. due to import control restrictions of some countries, JDK1.4 per default comes with jurisdiction policy files allowing “strong” but limited cryptography; so keys that exeed the allowed strength are not allowed to be used by this policy. If you are entitled to do so, you may download and install an “unlimited strengh” version of these files. Usually, you can download them from the same web page as the Java™ runtime or JDK. Usually these files have to be put into the lib/security subdirectory of your JRE; however some VMs (e.g. IBM) may require to put them into another directory (e.g. lib/ext). Please read the installation instructions that come with these policy files. Take care to install these policy files in the correct JRE installation. Note that many JDKs install two JREs by default and that the one which is used by default is not(!) the one embedded in the JDK directory. To see which one is used, you may type java™ -verbose -version.

Any questions?

Don‘t hestitate to ask us about our products.

Contact us