Op 11/01/2013 15:52, Paulo Soares schreef:
> I think this is my fault. I thought that it referred to the TSA
> imprint that also had SHA-1 hardcoded and was fixed some time ago. It
> was another one.
I think I fixed it in Java. There's an unassigned ticket in JIRA to do
the fix in C#.
best regards
I think this is my fault. I thought that it referred to the TSA
imprint that also had SHA-1 hardcoded and was fixed some time ago. It
was another one.
Paulo
On Fri, Jan 11, 2013 at 12:36 PM, iText Info wrote:
> Op 11/01/2013 12:22, aszo...@szomor.hu schreef:
>> Our TSA provider use HashSha256 no
Op 11/01/2013 12:22, aszo...@szomor.hu schreef:
> Our TSA provider use HashSha256 not HashSha1 !
I just checked, the problem also exists in the Java version.
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API
Op 11/01/2013 11:07, aszo...@szomor.hu schreef:
> why you did not repair it ?
The primary source of the digital signing code is iText, the Java
version. Changes to the Java version are then ported to C#. If a problem
is reported on the free mailing list (instead of on the ticketing system
for pa
Oops --> still there in itextsharp-all-5.3.5 package !
Our TSA provider use HashSha256 not HashSha1 !
TEST CODE:
--
//
// We trying to find the BUGs
//
#region Revised pk.IsRevocationValid()
System.Console.Out.WriteLine("Start test of IsRevocationValid() in
PdfPKCS7.cs");
X509Certificat
Dear Developers,
I reported to you a little bug in IsRevocationValid method of
PdfPKCS7.cs many times, why you did not repair it ?
This little bug still is there in itextsharp-all-5.3.3 package, please
repair it into next version.
BAD LINE 1103: CertificateID tis = new
CertificateID(Certifi
