JAVA Toolkit
| home | contact




Frequently asked questions iaik-cms with s/mimev3

 

Q:

Occasionally verification of RSA based signatures seem to fail when using IAIK-CMS 4.0.The problem does not occur with IAIK-CMS 5.0

A:

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.

Q:

Although usually SignedData objects or signed S/MIME messages containing a SigningCertificateV2 attribute can be verified without problems, sometimes verification fails when the included SignerInfo contains a SigningCertificateV2 attribute.The problem occurs only with IAIk-CMS versions prior 5.0

A:

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.

Q:

When running the ProcessMessageDemo with JavaMail™ 1.5 I get an exception saying that there is no MimeMessage/MimeBodyPart content. With JavaMail™ 1.4 all works fine!

A:

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.

Q:

My S/MIME appliaction does not work properly with JavaMail™ version 1.3.3. Signatures cannot be verified and encrypted messages cannot be decrypted. However, all works well with JavaMail™ 1.3.2.

A:

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.

Q:

When using JavaMail™ 1.3.3 and running the SMimeDemo I get the following exception saying that the signature cannot be verified:

     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.

Q:

I have used the S/MIME library of IAIK-CMS to create and sign a multipart/mixed MIME entity consisting of only one body part:

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--

Athough I have no problems to display the message and verify the signature when using Mozilla, both Outlook Express and Outlook are not able to handle the message.

A:

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 !");

Q:

I have used the S/MIME library of IAIK-CMS to create and send a triple wrapped (signed-encrypted-signed) message to an Outlook Express mail client. Outlook express is able to resolve and display the message, but complains that the signature is not correct. For the signed parts I have used the "multipart/signed" content type (explicit SignedContent).

A:

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.

Q:

I have used the S/MIME library of IAIK-CMS to create and send a signed message to an Outlook Express mail client. I have included my encryption certificate into the SignedData message, but Outlook Express is not able to fetch it from the certificates field. I am using different certificates for signing and encryption.

A:

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.

Q:

 When trying the SMimeSend demo, an exception is thrown saying that there is no data content handler for the S/MIME content types.
 

A:

 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.
 

Q:

 When using the S/MIME library, I get a ClassCastException to iaik.asn1.structures. Name from the Java™ JarVerifier:

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)

 

 I am using JDK1.3 and have the IAIK-JCE crypto provider (jar file is not signed) installed as first provider.

A:

 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.

Q:

When installing the IAIK-JCE provider (signed version) as first provider for IAIK-CMS and trying to do some cipher operation (e.g. with the EnvelopedData type) a stack overflow error occurs. I am using JDK 1.4.

A:

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();

Q:

When using IAIK-JCE as crypto provider for IAIK-CMS and trying to do some cipher operation (e.g. with the EnvelopedData type) I get an ExceptionInInitializerError is thrown saying "Cannot set up certs for trusted CAs". I am using JDK 1.4.

A:

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.


 
print    tip a friend
back to previous page back  |  top to the top of the page