iText - General

iText-5.3.0 digital signature problem?

Classic

List

Threaded

11 messages Options

Eric Chow

iText-5.3.0 digital signature problem?

Hello,

I am trying to migrate my old digital signature program to the new iText-5.3.0, but it failed.

I tried to test the digital signature in the iText-5.3.0 tutorial but it not worked with Smartcard. It gots some exception:

java.security.NoSuchAlgorithmException: no such algorithm: SHA1 for provider SunPKCS11-GD
    at sun.security.jca.GetInstance.getService(GetInstance.java:70)
    at sun.security.jca.GetInstance.getInstance(GetInstance.java:190)
    at java.security.Security.getImpl(Security.java:662)
    at java.security.MessageDigest.getInstance(MessageDigest.java:185)
    at com.itextpdf.text.pdf.security.MakeSignature.signDetached(MakeSignature.java:128)
    at TestSign.sign(TestSign.java:46)
    at TestSign.main(TestSign.java:74)

The following is my example, please advise me if the codes exist mistakes.

import java.io.FileOutputStream;
import java.io.IOException;
import java.security.GeneralSecurityException;
import java.security.KeyStore;
import java.security.PrivateKey;
import java.security.Security;
import java.security.cert.Certificate;

import sun.security.pkcs11.SunPKCS11;

import com.itextpdf.text.DocumentException;
import com.itextpdf.text.Rectangle;
import com.itextpdf.text.pdf.PdfReader;
import com.itextpdf.text.pdf.PdfSignatureAppearance;
import com.itextpdf.text.pdf.PdfStamper;
import com.itextpdf.text.pdf.security.DigestAlgorithms;
import com.itextpdf.text.pdf.security.MakeSignature;
import com.itextpdf.text.pdf.security.PrivateKeySignature;

/**
*
*/

/**
* @author Eric Chow (hkc)
*
*/
public class TestSign {

    public static void sign(PrivateKey pk, Certificate[] chain,
            String src, String dest, String provider,
            String reason, String location,
            String digestAlgorithm, boolean subfilter)
                    throws GeneralSecurityException, IOException, DocumentException {
        // Creating the reader and the stamper
        PdfReader reader = new PdfReader(src);
        FileOutputStream os = new FileOutputStream(dest);
        PdfStamper stamper = PdfStamper.createSignature(reader, os, '\0');
        // Creating the appearance
        PdfSignatureAppearance appearance = stamper.getSignatureAppearance();
        appearance.setReason(reason);
        appearance.setLocation(location);
        appearance.setVisibleSignature(new Rectangle(36, 748, 144, 780), 1, "sig");
        // Creating the signature
        PrivateKeySignature pks = new PrivateKeySignature(pk, digestAlgorithm, provider);
        MakeSignature.signDetached(appearance, pks, chain, null, null, null, provider, 0, subfilter);

    }




    /**
    * @param args
    */
    public static void main(String[] args) {
        String PASSWORD = "password";
        String SRC = "doc/test.pdf";
        String DEST = "doc/test_signed.pdf";

        try {

            SunPKCS11 pkcs11 = new SunPKCS11("pkcs11.cfg");
            Security.addProvider (pkcs11);
            KeyStore ks = KeyStore.getInstance("PKCS11");

            ks.load(null, PASSWORD.toCharArray());

            String alias = "885856b0-60b9-4727-9416-75c70810de4d";

            PrivateKey pk = (PrivateKey) ks.getKey(alias, PASSWORD.toCharArray());
            Certificate[] chain = ks.getCertificateChain(alias);

            sign(pk, chain, SRC, DEST, pkcs11.getName(), "Test 3", "Ghent", DigestAlgorithms.SHA1, MakeSignature.CADES);
        } catch(Exception e) {
            e.printStackTrace();
        }
    }

}

Best regards,
Eric

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

mkl

Re: iText-5.3.0 digital signature problem?

Eric,

Eric Chow wrote

java.security.NoSuchAlgorithmException: no such algorithm: SHA1 for provider SunPKCS11-GD
at sun.security.jca.GetInstance.getService(GetInstance.java:70)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:190)
at java.security.Security.getImpl(Security.java:662)
at java.security.MessageDigest.getInstance(MessageDigest.java:185)
at com.itextpdf.text.pdf.security.MakeSignature.signDetached(MakeSignature.java:128)
at TestSign.sign(TestSign.java:46)
at TestSign.main(TestSign.java:74)

There seems to be a small inconsistency concerning the use of the SunPKCS11 provider in iText: MakeSignature.signDetached uses the given provider (unless it is null) to retrieve the hash algorithm, too, while the PdfPKCS7 constructor (to which the provider value is forwarded) uses it to retrieve the hash algorithm only if it doesn't start with "SunPKCS11". This surely will be made consistent.

The actual problem is IMO that there are two different uses for the given provider: It is used both for retrieving a digest algorithm and for retrieving a Signature instance. Sometimes, though, you need different providers for these tasks. Unless resorting to not using provider arguments, therefore, there should be overloads with two provider arguments.

Regards, Michael.

Andreas Kuehne-3

Re: [SPAM] Re: iText-5.3.0 digital signature problem?

Hi Michael,

would we be better off if iText doesn't use the given provider for
hashing? The specified provider is usually intended for the signing
stuff. And BC is always a good choice for hashing algorithms.

My proposal:
Try hashing with BC. If the given algo is not available in BC, give the
specified provider a try.

Greetings

Andreas

> Eric,
>
> Eric Chow wrote
>> java.security.NoSuchAlgorithmException: no such algorithm: SHA1 for
>> provider SunPKCS11-GD
>> at sun.security.jca.GetInstance.getService(GetInstance.java:70)
>> at sun.security.jca.GetInstance.getInstance(GetInstance.java:190)
>> at java.security.Security.getImpl(Security.java:662)
>> at java.security.MessageDigest.getInstance(MessageDigest.java:185)
>> at
>> com.itextpdf.text.pdf.security.MakeSignature.signDetached(MakeSignature.java:128)
>> at TestSign.sign(TestSign.java:46)
>> at TestSign.main(TestSign.java:74)
> There seems to be a small inconsistency concerning the use of the SunPKCS11
> provider in iText: MakeSignature.signDetached uses the given provider
> (unless it is null) to retrieve the hash algorithm, too, while the PdfPKCS7
> constructor (to which the provider value is forwarded) uses it to retrieve
> the hash algorithm only if it doesn't start with "SunPKCS11". This surely
> will be made consistent.
>
> The actual problem is IMO that there are two different uses for the given
> provider: It is used both for retrieving a digest algorithm and for
> retrieving a Signature instance. Sometimes, though, you need different
> providers for these tasks. Unless resorting to not using provider arguments,
> therefore, there should be overloads with two provider arguments.
>
> Regards, Michael.
>
> --
> View this message in context: http://itext-general.2136553.n4.nabble.com/iText-5-3-0-digital-signature-problem-tp4655635p4655637.html
> Sent from the iText - General mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> iText-questions mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/itext-questions
>
> iText(R) is a registered trademark of 1T3XT BVBA.
> Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
> Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php
>

--
Andreas Kühne
phone: +49 177 293 24 97
mailto: [hidden email]

Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868

Directors Andreas Kühne, Heiko Veit

Company UK Company No: 5218868 Registered in England and Wales

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

iText Info

Re: iText-5.3.0 digital signature problem?

In reply to this post by Eric Chow

Op 19/07/2012 4:11, Eric Chow schreef:

Hello,

I am trying to migrate my old digital signature program to the new iText-5.3.0, but it failed.

I tried to test the digital signature in the iText-5.3.0 tutorial but it not worked with Smartcard. It gots some exception:

java.security.NoSuchAlgorithmException: no such algorithm: SHA1 for provider SunPKCS11-GD

This is NOT an iText issue.
The error message explains why: you are trying to create a message digest (SHA1, an algorithm that is no longer recommended as you could read in the white paper) using the security provider SunPKCS11-GD which doesn't support the algorithm of your choice.

The solution is: use another security provider to create the hash.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

iText Info

Re: [SPAM] Re: iText-5.3.0 digital signature problem?

In reply to this post by mkl

Op 19/07/2012 8:52, mkl schreef:
> The actual problem is IMO that there are two different uses for the given
> provider: It is used both for retrieving a digest algorithm and for
> retrieving a Signature instance. Sometimes, though, you need different
> providers for these tasks. Unless resorting to not using provider arguments,
> therefore, there should be overloads with two provider arguments.
I answered before reading this answer.
You are right. There should be a possibility to use different providers:
one for hashing, one for encrypting.
We'll look into it.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

mkl

Re: [SPAM] Re: iText-5.3.0 digital signature problem?

In reply to this post by Andreas Kuehne-3

Andreas,

Andreas Kuehne-3 wrote

would we be better off if iText doesn't use the given provider for hashing? The specified provider is usually intended for the signing stuff. And BC is always a good choice for hashing algorithms.

That can be a solution, too. Maybe, though, someone prefers a specific digest algorithm implementation but cannot guarantee the provider being positioned at an early enough position in the provider list. On the other hand iText cannot consider all tiny special cases and such persons should create their signature containers externally.

Most important in my eyes, though, is to make the provider handling in iText consistent --- if excluding SunPKCS11 when retrieving a digest algorithm once, it should be done in all similar contexts.

Regards, Michael

Andreas Kuehne-3

Re: [SPAM] Re: [SPAM] Re: iText-5.3.0 digital signature problem?

Hi Michael,

yes, it could be useful to denote a special provider for hashing. Maybe
the best solution would be to have a signing provider parameter and an
optional parameter for hash usage, which defaults to BC.

I wouldn't recommend to make decision upon provider names within the
code (like the check for SunPKCS11). This fails far to easily. E.g. I
prefer to use the iaik PKCS11 provider ;-)

Greetings,

Andreas

> Andreas,
>
> Andreas Kuehne-3 wrote
>> would we be better off if iText doesn't use the given provider for
>> hashing? The specified provider is usually intended for the signing stuff.
>> And BC is always a good choice for hashing algorithms.
> That can be a solution, too. Maybe, though, someone prefers a specific
> digest algorithm implementation but cannot guarantee the provider being
> positioned at an early enough position in the provider list. On the other
> hand iText cannot consider all tiny special cases and such persons should
> create their signature containers externally.
>
> Most important in my eyes, though, is to make the provider handling in iText
> consistent --- if excluding SunPKCS11 when retrieving a digest algorithm
> once, it should be done in all similar contexts.
>
> Regards, Michael
>
> --
> View this message in context: http://itext-general.2136553.n4.nabble.com/iText-5-3-0-digital-signature-problem-tp4655635p4655642.html
> Sent from the iText - General mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> iText-questions mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/itext-questions
>
> iText(R) is a registered trademark of 1T3XT BVBA.
> Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
> Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php
>

Eric Chow

Re: [SPAM] Re: [SPAM] Re: iText-5.3.0 digital signature problem?

Hello,

Do you mean that I cannot not use SunPKCS11 with iText-5.3.0 now?

If I need to do the digital signature with a smart card, how can I do?

Would you please to show me a simple example?

Best regards,
Eric

On Thu, Jul 19, 2012 at 3:53 PM, Andreas Kuehne <[hidden email]> wrote:

Hi Michael,

yes, it could be useful to denote a special provider for hashing. Maybe
the best solution would be to have a signing provider parameter and an
optional parameter for hash usage, which defaults to BC.

I wouldn't recommend to make decision upon provider names within the
code (like the check for SunPKCS11). This fails far to easily. E.g. I
prefer to use the iaik PKCS11 provider ;-)

Greetings,

Andreas

> Andreas,
>
> Andreas Kuehne-3 wrote
>> would we be better off if iText doesn't use the given provider for
>> hashing? The specified provider is usually intended for the signing stuff.
>> And BC is always a good choice for hashing algorithms.
> That can be a solution, too. Maybe, though, someone prefers a specific
> digest algorithm implementation but cannot guarantee the provider being
> positioned at an early enough position in the provider list. On the other
> hand iText cannot consider all tiny special cases and such persons should
> create their signature containers externally.
>
> Most important in my eyes, though, is to make the provider handling in iText
> consistent --- if excluding SunPKCS11 when retrieving a digest algorithm
> once, it should be done in all similar contexts.
>
> Regards, Michael
>
> --
> View this message in context: http://itext-general.2136553.n4.nabble.com/iText-5-3-0-digital-signature-problem-tp4655635p4655642.html
> Sent from the iText - General mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> iText-questions mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/itext-questions
>
> iText(R) is a registered trademark of 1T3XT BVBA.
> Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
> Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php
>

--
Andreas Kühne
phone: <a href="tel:%2B49%20177%20293%2024%2097" value="+491772932497">+49 177 293 24 97
mailto: [hidden email]

Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868

Directors Andreas Kühne, Heiko Veit

Company UK Company No: 5218868 Registered in England and Wales

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

Paulo Soares-4

Re: [SPAM] Re: [SPAM] Re: iText-5.3.0 digital signature problem?

In reply to this post by Andreas Kuehne-3

The check for SunPKCS11 was to fix a problem many years ago that I'm
sure is not relevant anymore. Should a specific provider be used just
for hashing or should a new interface be introduced that would take
care of the hashing? The interface could call the BC functions
directly and wouldn't even need to have BC registered. This hashing
issues are coming up too frequently and it's time to fix them.

Paulo

On Thu, Jul 19, 2012 at 8:53 AM, Andreas Kuehne <[hidden email]> wrote:

> Hi Michael,
>
> yes, it could be useful to denote a special provider for hashing. Maybe
> the best solution would be to have a signing provider parameter and an
> optional parameter for hash usage, which defaults to BC.
>
> I wouldn't recommend to make decision upon provider names within the
> code (like the check for SunPKCS11). This fails far to easily. E.g. I
> prefer to use the iaik PKCS11 provider ;-)
>
> Greetings,
>
> Andreas
>> Andreas,
>>
>> Andreas Kuehne-3 wrote
>>> would we be better off if iText doesn't use the given provider for
>>> hashing? The specified provider is usually intended for the signing stuff.
>>> And BC is always a good choice for hashing algorithms.
>> That can be a solution, too. Maybe, though, someone prefers a specific
>> digest algorithm implementation but cannot guarantee the provider being
>> positioned at an early enough position in the provider list. On the other
>> hand iText cannot consider all tiny special cases and such persons should
>> create their signature containers externally.
>>
>> Most important in my eyes, though, is to make the provider handling in iText
>> consistent --- if excluding SunPKCS11 when retrieving a digest algorithm
>> once, it should be done in all similar contexts.
>>
>> Regards, Michael
>>
>> --
>> View this message in context: http://itext-general.2136553.n4.nabble.com/iText-5-3-0-digital-signature-problem-tp4655635p4655642.html
>> Sent from the iText - General mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> iText-questions mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/itext-questions
>>
>> iText(R) is a registered trademark of 1T3XT BVBA.
>> Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
>> Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php
>>
>
>
> --
> Andreas Kühne
> phone: +49 177 293 24 97
> mailto: [hidden email]
>
> Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868
>
> Directors Andreas Kühne, Heiko Veit
>
> Company UK Company No: 5218868 Registered in England and Wales
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> iText-questions mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/itext-questions
>
> iText(R) is a registered trademark of 1T3XT BVBA.
> Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
> Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

Andreas Kuehne-3

Re: [SPAM] Re: [SPAM] Re: iText-5.3.0 digital signature problem?

Hi Paulo,

introducing a new 'hashing' interface is a good approach. Even the
strangest algorithm could be managed this way. And it would delegate the
responsibilty for implementing adsurd requirements back to the requestor.

Greetings,

Andreas

> The check for SunPKCS11 was to fix a problem many years ago that I'm
> sure is not relevant anymore. Should a specific provider be used just
> for hashing or should a new interface be introduced that would take
> care of the hashing? The interface could call the BC functions
> directly and wouldn't even need to have BC registered. This hashing
> issues are coming up too frequently and it's time to fix them.
>
> Paulo
>
> On Thu, Jul 19, 2012 at 8:53 AM, Andreas Kuehne <[hidden email]> wrote:
>> Hi Michael,
>>
>> yes, it could be useful to denote a special provider for hashing. Maybe
>> the best solution would be to have a signing provider parameter and an
>> optional parameter for hash usage, which defaults to BC.
>>
>> I wouldn't recommend to make decision upon provider names within the
>> code (like the check for SunPKCS11). This fails far to easily. E.g. I
>> prefer to use the iaik PKCS11 provider ;-)
>>
>> Greetings,
>>
>> Andreas
>>> Andreas,
>>>
>>> Andreas Kuehne-3 wrote
>>>> would we be better off if iText doesn't use the given provider for
>>>> hashing? The specified provider is usually intended for the signing stuff.
>>>> And BC is always a good choice for hashing algorithms.
>>> That can be a solution, too. Maybe, though, someone prefers a specific
>>> digest algorithm implementation but cannot guarantee the provider being
>>> positioned at an early enough position in the provider list. On the other
>>> hand iText cannot consider all tiny special cases and such persons should
>>> create their signature containers externally.
>>>
>>> Most important in my eyes, though, is to make the provider handling in iText
>>> consistent --- if excluding SunPKCS11 when retrieving a digest algorithm
>>> once, it should be done in all similar contexts.
>>>
>>> Regards, Michael
>>>
>>> --
>>> View this message in context: http://itext-general.2136553.n4.nabble.com/iText-5-3-0-digital-signature-problem-tp4655635p4655642.html
>>> Sent from the iText - General mailing list archive at Nabble.com.
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> iText-questions mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/itext-questions
>>>
>>> iText(R) is a registered trademark of 1T3XT BVBA.
>>> Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
>>> Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php
>>>
>>
>> --
>> Andreas Kühne
>> phone: +49 177 293 24 97
>> mailto: [hidden email]
>>
>> Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868
>>
>> Directors Andreas Kühne, Heiko Veit
>>
>> Company UK Company No: 5218868 Registered in England and Wales
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> iText-questions mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/itext-questions
>>
>> iText(R) is a registered trademark of 1T3XT BVBA.
>> Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
>> Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> iText-questions mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/itext-questions
>
> iText(R) is a registered trademark of 1T3XT BVBA.
> Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
> Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php
>

Paulo Soares-4

Re: [SPAM] Re: [SPAM] Re: iText-5.3.0 digital signature problem?

I'll go the interface way, after all there's already an interface for
the signatures and I'll add one for the hashing.

Paulo

On Thu, Jul 19, 2012 at 11:01 AM, Andreas Kuehne <[hidden email]> wrote:

> Hi Paulo,
>
> introducing a new 'hashing' interface is a good approach. Even the
> strangest algorithm could be managed this way. And it would delegate the
> responsibilty for implementing adsurd requirements back to the requestor.
>
> Greetings,
>
> Andreas
>> The check for SunPKCS11 was to fix a problem many years ago that I'm
>> sure is not relevant anymore. Should a specific provider be used just
>> for hashing or should a new interface be introduced that would take
>> care of the hashing? The interface could call the BC functions
>> directly and wouldn't even need to have BC registered. This hashing
>> issues are coming up too frequently and it's time to fix them.
>>
>> Paulo
>>
>> On Thu, Jul 19, 2012 at 8:53 AM, Andreas Kuehne <[hidden email]> wrote:
>>> Hi Michael,
>>>
>>> yes, it could be useful to denote a special provider for hashing. Maybe
>>> the best solution would be to have a signing provider parameter and an
>>> optional parameter for hash usage, which defaults to BC.
>>>
>>> I wouldn't recommend to make decision upon provider names within the
>>> code (like the check for SunPKCS11). This fails far to easily. E.g. I
>>> prefer to use the iaik PKCS11 provider ;-)
>>>
>>> Greetings,
>>>
>>> Andreas
>>>> Andreas,
>>>>
>>>> Andreas Kuehne-3 wrote
>>>>> would we be better off if iText doesn't use the given provider for
>>>>> hashing? The specified provider is usually intended for the signing stuff.
>>>>> And BC is always a good choice for hashing algorithms.
>>>> That can be a solution, too. Maybe, though, someone prefers a specific
>>>> digest algorithm implementation but cannot guarantee the provider being
>>>> positioned at an early enough position in the provider list. On the other
>>>> hand iText cannot consider all tiny special cases and such persons should
>>>> create their signature containers externally.
>>>>
>>>> Most important in my eyes, though, is to make the provider handling in iText
>>>> consistent --- if excluding SunPKCS11 when retrieving a digest algorithm
>>>> once, it should be done in all similar contexts.
>>>>
>>>> Regards, Michael
>>>>
>>>> --
>>>> View this message in context: http://itext-general.2136553.n4.nabble.com/iText-5-3-0-digital-signature-problem-tp4655635p4655642.html
>>>> Sent from the iText - General mailing list archive at Nabble.com.
>>>>