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 <kue...@trustable.de> 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 <kue...@trustable.de> 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 iText-questions@lists.sourceforge.net 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
