Digital Signature CreateLongTermValidity Options Request (choose revocation check method & cancel signing process if not LTV)

[Jacobs]

Can you provide an enhancement to CreateLongTermValidity function is to choose the embedding revocation method OCSP_Only, CRL_Only, OCSP_First & CRL_First as an optional parameter while signing LTV documents ?

[Irfana Jaffer Sadhik]

Currently, we are analyzing on this and will provide the further details shortly.

[Jacobs]

Thanks ... also if there is an option to cancel signing operation (true/false)if no response received from selected method. 

[Irfana Jaffer Sadhik]

can you please elaborate on your requirement? 

[Jacobs]

What it mean is adding another new parameter ... to Cancel Signing if no response or invalid response.

so if true and selected method was CRL and CRL url was not retrieving the CRL file (wrong url) or CRL file signer is not valid (ex. expired) so the signing process will not be completed and it will return an error cannot sign with LTV.

if false ... the signing process will continue regardless the response of the selected method but the signature will not be LTV. 

[Irfana Jaffer Sadhik]

Thank you for sharing the details. Currently, we are analyzing this and will provide further details shortly.

[Jacobs]

Thanks Irfana, i want to add also  that there might be no internet connection on PC used at time of signing .... so the new parameter(true/false) will be useful to stop the signing process if want to ensure that the new signature is LTV.

[Ravikumar Baladhandapani]

Can you provide an enhancement to CreateLongTermValidity function is to choose the embedding revocation method OCSP_Only, CRL_Only, OCSP_First & CRL_First as an optional parameter while signing LTV documents ?

Currently, we are analyzing the possibilities to achieve this requirement and will provide the further details shortly.

What it mean is adding another new parameter ... to Cancel Signing if no response or invalid response. so if true and selected method was CRL and CRL url was not retrieving the CRL file (wrong url) or CRL file signer is not valid (ex. expired) so the signing process will not be completed and it will return an error cannot sign with LTV. if false ... the signing process will continue regardless the response of the selected method but the signature will not be LTV.    Thanks Irfana, i want to add also  that there might be no internet connection on PC used at time of signing .... so the new parameter(true/false) will be useful to stop the signing process if want to ensure that the new signature is LTV.

We can able to find the provided certificate is valid or not using EnableLtv property. Internally we are enabling this property, if the certificate is valid and gets the CRL file properly and we are disabling this property, if returns the invalid response. Please refer the below code snippet,   PdfLoadedDocument loadedDocument = new PdfLoadedDocument("../../Output.pdf");             //Get the page of the existing PDF document PdfLoadedPage loadedPage = loadedDocument.Pages[0] as PdfLoadedPage;               //Create a new PDF signature without PdfCertificate instance   dfSignature signature = new PdfSignature(loadedDocument, loadedPage, null, "Signature1");             //Create X509Certificate2 from your certificate to create a long-term validity             X509Certificate2 x509 = new X509Certificate2("../../PDF.pfx", "password123");             //Create LTV with your public certificates             signature.CreateLongTermValidity(new List<X509Certificate2> { x509 });               if (!signature.EnableLtv)             {                 //Signature will not be LTV.             }             //Save and close the PDF document             loadedDocument.Save("../../SignedDocument.pdf");             loadedDocument.Close(true);

[Jacobs]

That's super great ... i will check the EnableLtv property and feedback .

Is there a similar property or workaround for timestamp if no response received from timestamp server when using signature.TimeStampServer in order to stop the signing process? 

[Jacobs]

unfortunately.... i tested the property EnableLtv after CreateLongTermValidity it returned true while i was blocking CRL and LTV on two certificates of the certificate chain and only one was allowed .. and the file was signed NOT LTV and when i checked the PdfSignatureValidationResult.LtvVerificationInfo ... all fields were true which is incorrect.

Please check result file attached.

Attachment: testnotLTV_679bc15a.zip

[Moorthy Karunanithi]

Can you provide an enhancement to CreateLongTermValidity function is to choose the embedding revocation method OCSP_Only, CRL_Only, OCSP_First & CRL_First as an optional parameter while signing LTV documents ?

On our further analysis, we have considered this requirement as a usability feature with “Support to specify the revocation type while signing the pdf document” and we will include this support in our 2023 Volume 2 Main release which will be available on the end of June 2023 tentatively.   Please use the below feedback link to track the status of this feature.   https://www.syncfusion.com/feedback/41188/support-to-specify-the-revocation-type-while-signing-the-pdf-document

Is there a similar property or workaround for timestamp if no response received from timestamp server in order to stop the signing process?

We can able find whether the TimeStampServer is valid or not using  IsValid Boolean property. Please refer the below code snippet,   TimeStampServer tsServer = new TimeStampServer(new Uri(http://timestampurl.com/)); //Check whether the Timestamp URL is valid or not. bool isValid = tsServer.IsValid;   Please let us know, if you need any further assistance on this.

Currently, we are working on the PdfSignatureValidationResult.LtvVerificationInfo & EnableLtv property problem and we will update further details on 20^th February 2023.

[Jacobs]

Great ... thanks Moorthy

[Jacobs]

i checked the timestamp.isvalid and it is working but not on all cases , sometimes the server rejects the call and it returns status 200 without returning a timestamp datetime and the timestamp.isvalid = true so the signing process completes with error (Object reference error)  ... so it would be better if there is another property that returns the timestamp datetime that the server provided so i could check on and maybe use it in other validation checks.

[Jacobs]

Another file that is not LTV , however property  IsLtvEnabled  = True in LTVVerificationInfo 

check attached.

Attachment: NOT_LTV_Issue_805088a8.zip

[Irfana Jaffer Sadhik]

i checked the timestamp.isvalid and it is working but not on all cases , sometimes the server rejects the call and it returns status 200 without returning a timestamp datetime and the timestamp.isvalid = true so the signing process completes with error (Object reference error)  ... so it would be better if there is another property that returns the timestamp datetime that the server provided so i could check on and maybe use it in other validation checks.

Can you please provide us with the timestamp URI server and password details so we can investigate the problem on our end?

Another file that is not LTV , however property  IsLtvEnabled  = True in LTVVerificationInfo   check attached.

We are currently validating the behavior for LTV with a revocation chain for signature validation. We will provide further details on February 22, 2023.

[Jacobs]

Thanks Irfana

Regarding the timestamp URL , you can check this one http://rootca.gov.eg/tmstpsrvGo 

if you add any letter at end http://rootca.gov.eg/tmstpsrvGox it will return IsValid=true but the signing process completes with error (Object reference error) 

[Santhiya Narayanan]

Currently, we are analyzing the reported behavior. we will analyze further on this and will provide further details on February 28th, 2023.

[Jacobs]

Dear, I came across a small bug while testing the function CreateLongTermValidity , one of the certificates in the certificate chain has two CRL Distribution Points(two urls second is failover if the first one is down).

When i blocked OCSP & the first CRL url , the function couldn't create an LTV signature while the second url was working fine.

The expected behaviour was to check OCSP first,if no response check on the first CRL url ,if again no response check on second CRL url ,if there is response, the function should embed this CRL.

I would really appreciate if it can be fixed with the reported IsLtvEnabled & EnableLtv properties issue that was going to be released in March 7th,2023 (or in custom nuget on March 1st,2023) as mentioned in the below reply

https://www.syncfusion.com/forums/180498/digital-signature-get-isocspembedded-and-iscrlembedded-per-certificate-in-certificate-chain?reply=SqAJ2C

[Moorthy Karunanithi]

We confirmed the issue “TimeStamp IsValid API is not working properly for invalid URI” as a defect in our product and defect and we will include the fix in our upcoming weekly NuGet release, which will be available on March 7th, 2023.

Please use the below feedback link to track the status of the reported bug.

https://www.syncfusion.com/feedback/41606/timestamp-isvalid-api-is-not-working-properly-for-invalid-uri

Note: If you require a patch for the reported issue in any of our Essential Studio Main or SP release version, then kindly let us know the version, so that we can provide a patch in that version based on our SLA policy.

Disclaimer: “Inclusion of this solution in the weekly release may change due to other factors including but not limited to QA checks and works reprioritization.”

[Jacobs]

Thanks Moorthy... 👍

Is there any update about my earlier mentioned issue on 27/02/2023 ...up here ?

[Irfana Jaffer Sadhik]

Dear, I came across a small bug while testing the function CreateLongTermValidity , one of the certificates in the certificate chain has two CRL Distribution Points(two urls second is failover if the first one is down).   When i blocked OCSP & the first CRL url , the function couldn't create an LTV signature while the second url was working fine.   The expected behaviour was to check OCSP first,if no response check on the first CRL url ,if again no response check on second CRL url ,if there is response, the function should embed this CRL

If any of the elements in the chain have either OCSP or CRL information embedded, the EnableLtv property will be enabled by default. We don’t have any plan to change this behavior for CreateLongTermValidity .

I would really appreciate if it can be fixed with the reported IsLtvEnabled  properties issue that was going to be released in March 7th,2023 (or in custom nuget on March 1st,2023) as mentioned in the below reply https://www.syncfusion.com/forums/180498/digital-signature-get-isocspembedded-and-iscrlembedded-per-certificate-in-certificate-chain?reply=SqAJ2C

We have created a custom NuGet package, version “20.4.0.51” for the IsLtvEnabled  issue, which is available for reference. The public release of this fix is expected to be available on March 7th, 2023 with the next weekly release.   NUGET Package: https://www.dropbox.com/s/cc5gp227q90vvwi/syncfusion.pdf.winforms.20.4.0.51.nupkg?dl=0

[Jacobs]

Thanks Irfana, first of all ... signature is considered LTV if every element in certificate chain has embedded revocation information (either ocsp or crl) except for root certificate.

I described up here two different cases that are considered defects in the CreateLongTermValidity function as in both cases it does not produce LTV signature.

First case:

The certificate chain consist of 3 elements in addition to root , if one of the 3 elements has its ocsp and crl down or blocked and the other elements have no issues in ocsp or crl ... the EnableLTV property should be false in order to stop the signing process as the signature generated will not be LTV ... this was the way that syncfusion team  mentioned in an earlier reply in order to be able to stop the signing process.

signature.CreateLongTermValidity(new List { x509 });
if (!signature.EnableLtv)
{
//Signature will not be LTV.
}
//Save and close the PDF document
loadedDocument.Save("../../SignedDocument.pdf");
loadedDocument.Close(true);

see my earlier detailed reply here

https://www.syncfusion.com/forums/180445/digital-signature-createlongtermvalidity-options-request?reply=SqAWI7

Note that Adobe reader stops the signing process if no LTV information could be reached if the below setting is checked "Include signature revocation status"

Second case:

Element in certificate chain may have multiple CRL urls (CRL Distribution points) used as failover.

if this specific element has no ocsp response and its first url is down while second crl url was fine then the singing process should be embedded with the second url.

CreateLongTermValidity ignores the second url if it coudn't get response from first and fails to produce LTV signature.

see my detailed reply here

https://www.syncfusion.com/forums/180445/digital-signature-createlongtermvalidity-options-request?reply=SqA610

Note that adobe reader checks for second crl url if no response received from ocsp or first crl url and can create LTV signature by embedding crl from the second crl url .

[Jacobs]

Also I tested the custom nuget you provided today ... it is now displaying correct results (IsLTVEnabled) for the two files i attached earlier.

but unfortunately for other files it is not working correctly... please check sample attached 

Adobe shows that signature is LTV (it has embedded revocation information in every element in chain )

however  IsLTVEnabled = false

Attachment: adobesignature_a2ad994a.zip

[Irfana Jaffer Sadhik]

Also I tested the custom nuget you provided today ... it is now displaying correct results (IsLTVEnabled) for the two files i attached earlier.   but unfortunately for other files it is not working correctly... please check sample attached  Adobe shows that signature is LTV (it has embedded revocation information in every element in chain ) however  IsLTVEnabled = false

Our development team is currently looking into the issue with newly shared PDF document and will provide updates on March 6th, 2023.

Thanks Irfana, first of all ... signature is considered LTV if every element in certificate chain has embedded revocation information (either ocsp or crl) except for root certificate. I described up here two different cases that are considered defects in the CreateLongTermValidity function as in both cases it does not produce LTV signature.   First case: The certificate chain consist of 3 elements in addition to root , if one of the 3 elements has its ocsp and crl down or blocked and the other elements have no issues in ocsp or crl ... the EnableLTV property should be false in order to stop the signing process as the signature generated will not be LTV ... this was the way that syncfusion team  mentioned in an earlier reply in order to be able to stop the signing process. see my earlier detailed reply here https://www.syncfusion.com/forums/180445/digital-signature-createlongtermvalidity-options-request?reply=SqAWI7   Second case:   Element in certificate chain may have multiple CRL urls (CRL Distribution points) used as failover. if this specific element has no ocsp response and its first url is down while second crl url was fine then the singing process should be embedded with the second url. CreateLongTermValidity ignores the second url if it coudn't get response from first and fails to produce LTV signature.

We are grateful for the comprehensive data you provided us. Our development team is presently examining the EnableLTV API result behviour update possibilities and the issue of CreateLongTermValidity not being able to obtain the second CRI if the first CRI does not succeed. We will give updates on March 6th, 2023.

[Jacobs]

Thanks Irfana for your quick reply 😊👍

I am glad i could be of help.

[Irfana Jaffer Sadhik]

Also I tested the custom nuget you provided today ... it is now displaying correct results (IsLTVEnabled) for the two files i attached earlier.   but unfortunately for other files it is not working correctly... please check sample attached  Adobe shows that signature is LTV (it has embedded revocation information in every element in chain ) however  IsLTVEnabled = false

We have created a custom NuGet package, version “20.4.0.51”, to address the IsLTVEnabled issue. Please try this package and let us know the result. Once we have your confirmation, we will move forward and include the fix in the public release. NUGET Package: https://www.dropbox.com/s/cc5gp227q90vvwi/syncfusion.pdf.winforms.20.4.0.51.nupkg?dl=0

Thanks Irfana, first of all ... signature is considered LTV if every element in certificate chain has embedded revocation information (either ocsp or crl) except for root certificate. I described up here two different cases that are considered defects in the CreateLongTermValidity function as in both cases it does not produce LTV signature.   First case: The certificate chain consist of 3 elements in addition to root , if one of the 3 elements has its ocsp and crl down or blocked and the other elements have no issues in ocsp or crl ... the EnableLTV property should be false in order to stop the signing process as the signature generated will not be LTV ... this was the way that syncfusion team  mentioned in an earlier reply in order to be able to stop the signing process. see my earlier detailed reply here https://www.syncfusion.com/forums/180445/digital-signature-createlongtermvalidity-options-request?reply=SqAWI7   Second case:   Element in certificate chain may have multiple CRL urls (CRL Distribution points) used as failover. if this specific element has no ocsp response and its first url is down while second crl url was fine then the singing process should be embedded with the second url. CreateLongTermValidity ignores the second url if it coudn't get response from first and fails to produce LTV signature.

Regarding problem with “Failed to fetch working CRL during CreateLongTermValidity and EnableLTV returns incorrect result” . We have planned to provide a test patch for this problem, and which is available on March 10th , 2022.

[Jacobs]

That's Great .... Thanks Irfana

Regarding the  IsLTVEnabled , i will test the custom package and feed you back

[Irfana Jaffer Sadhik]

We have included the fix for the reported issue “TimeStamp IsValid API is not working properly for invalid URI” in our latest weekly NuGet release (v20.4.0.53).

Please use the below link to download our latest weekly NuGet,     https://www.nuget.org/packages/Syncfusion.Pdf.WinForms/20.4.0.53

[Jacobs]

Thanks Irfana... i will check the new nuget for the timestamp fix .

 Regarding the IsLTVEnabled issue ... I tested the custom nuget on multiple files and it is returning correct results ... although it would be much helpful and added value if the isocspembedded & iscrlembedded can be retrieved per every element in certicate chain to be able to validate if the signature is LTV or not

(maybe in pdfsignaturevalidationresult.certifcates collection which returns the complete elements in chain)

Requested here:

https://www.syncfusion.com/forums/180498/digital-signature-get-isocspembedded-and-iscrlembedded-per-certificate-in-certificate-chain

[Irfana Jaffer Sadhik]

i will check the new nuget for the timestamp fix	Sure, we will wait for your result.
Regarding the IsLTVEnabled issue ... I tested the custom nuget on multiple files and it is returning correct results ...	Thank you for confirming. As promised, we will include the fix in our upcoming weekly NuGet release scheduled for March 14th, 2023.
although it would be much helpful and added value if the isocspembedded & iscrlembedded can be retrieved per every element in certicate chain to be able to validate if the signature is LTV or not (maybe in pdfsignaturevalidationresult.certifcates collection which returns the complete elements in chain) Requested here: https://www.syncfusion.com/forums/180498/digital-signature-get-isocspembedded-and-iscrlembedded-per-certificate-in-certificate-chain	As promised, we will implement this support in our upcoming 2023 Volume 2 main release, which will be expected at end of June 2022 tentatively.   Please use the below feedback link to track the status of the feature. https://www.syncfusion.com/feedback/41225/support-to-get-ocsp-and-crl-certificates-and-validity-from-signature-validation

[Irfana Jaffer Sadhik]

Regarding the problem with “Failed to fetch working CRL during CreateLongTermValidity and EnableLTV returns the incorrect result”. We have planned to provide a test patch for this problem, which is available on March 10th , 2022.

We have created a custom NuGet package, version “20.4.0.51”, to address the “Failed to fetch working CRL during CreateLongTermValidity and EnableLTV returns incorrect result” . Please try this package and let us know the result. Once we have your confirmation, we will move forward and include the fix in the public release.   NuGet Package: https://www.dropbox.com/s/eoc24721pq3oj3n/syncfusion.pdf.winforms.20.4.0.51.nupkg?dl=0

[Irfana Jaffer Sadhik]

Thank you for confirming. As promised, we will include the fix in our upcoming weekly NuGet release scheduled for March 14th, 2023.

We have included the fix for the reported issue “IsLTVEnabed returned incorrect results while verifying signature validation” in our latest weekly NuGet release (v20.4.0.54). Please use the below link to download our latest weekly NuGet,     https://www.nuget.org/packages/Syncfusion.Pdf.WinForms/20.4.0.54 Please let us know if you have any concerns on this

[Jacobs]

Hello Irfana,

i have tested the fix in custom nuget for both issues:

•  Failed to fetch working CRL during CreateLongTermValidity 
• EnableLTV returns incorrect result

Both are working properly now ... thank you for your usual support , I really appreciate it.

[Jacobs]

When will the fix be included in weekly nuget package?

Also i want to make sure that createlongtermvalidity function is checking internally ocsp/crl signer validity... if oscp/crl signature is not valid(expired),partial chain ...etc.. .. the function should return error or set enableltv = false with some indication about the issue... 

Waiting your reply

[Irfana Jaffer Sadhik]

I have tested the fix in custom NuGet for both issues:  Failed to fetch working CRL during CreateLongTermValidity  EnableLTV returns incorrect result Both are working properly now ... thank you for your usual support, I really appreciate it. When will the fix be included in weekly NuGet package?

Thank you for confirming. We will include the fix for the reported issue in our upcoming weekly release after our Volume 1 release which we excepted at the end of March.

Also i want to make sure that createlongtermvalidity function is checking internally ocsp/crl signer validity... if oscp/crl signature is not valid(expired),partial chain ...etc.. .. the function should return error or set enableltv = false with some indication about the issue...  Waiting your reply

Currently, we don’t have “Support for verifying and validating the OCSP and CRL signer and chain certificate while adding LTV to PDF”. At present, we do not have any immediate plans to implement this feature and we will implement this support in any of our upcoming releases. We usually have an interval of at least three months between releases, at the planning stage for every release cycle, we review all open features.  We will let you know when this feature is implemented. Please use the below feedback link to track the status of the feature. https://www.syncfusion.com/feedback/42321/support-for-verifying-and-validating-the-ocsp-and-crl-signer-and-chain-certificate

[Jacobs]

Thanks Irfana, can you please add also support for verifying and validating timestamp signer and its OCSP and CRL signer and chain certificate while adding timestamp to signature.

Also, is there currently any workaround to do it manually in code at my end till releasing this feature ?

[Santhiya Narayanan]

We don't have any alternative solution now. Currently, we are analyzing your requirements and we will provide further details on March 28th, 2023.

[Irfana Jaffer Sadhik]

We have logged your requirement “Support for verifying and validating the OCSP and CRL signer and chain certificate while adding LTV to PDF” in our database. At present, we do not have any immediate plans to implement this feature and we will implement this support in any of our upcoming releases. We usually have an interval of at least three months between releases, at the planning stage for every release cycle, we review all open features.  We will let you know when this feature is implemented. 

Please use the below feedback link to track the status of the feature.

https://www.syncfusion.com/feedback/42443/support-for-verifying-and-validating-timestamp-signer-and-its-ocsp-and-crl-signer

[Jacobs]

Thanks...hope to be included soon as these are some important security enhancements.

Also, is verifying and validating timestamp signer and its OCSP / CRL signer and chain certificate done in ValidateSignature() function ? And errors are returned in ValidationErrors in PDFValidationResult?

[Irfana Jaffer Sadhik]

i have tested the fix in custom nuget for both issues:  Failed to fetch working CRL during CreateLongTermValidity  EnableLTV returns incorrect result Both are working properly now ... thank you for your usual support , I really appreciate it. When will the fix be included in weekly nuget package?

We have included the fix for the reported issue “Failed to fetch working CRL during CreateLongTermValidity and EnableLTV returns the incorrect result” in our latest weekly NuGet release (v21.1.37). Please use the below link to download our latest weekly NuGet,    https://www.nuget.org/packages/Syncfusion.Pdf.WinForms/21.1.37

[Jacobs]

Thanks Irfana , waiting for your reply on my previous inquiry on 28/3/2023.

Thanks...hope to be included soon as these are some important security enhancements.

Also, is verifying and validating timestamp signer and its OCSP / CRL signer and chain certificate done in ValidateSignature() function ? And errors are returned in ValidationErrors in PDFValidationResult?

[Irfana Jaffer Sadhik]

Also, is verifying and validating timestamp signer and its OCSP / CRL signer and chain certificate done in ValidateSignature() function ? And errors are returned in ValidationErrors in PDFValidationResult?

We currently do not have the support to verifying and validity of the timestamp signer, as well as the OCSP/CRL signer and chain certificate, during the process of signature validation.

[Jacobs]

Thanks ... Can you please add this feature? 

Support to verifying the validity of the timestamp signer, as well as the OCSP/CRL signer and chain certificate, during the process of Signing and Validation

Along with other requests expected to be released soon

"Support to get IsOCSPEmbedded and IsCRLEmbedded properties per each element in certificate chain" 

"Support to get OCSP and CRL certificates and validity from signature validation results"​

"Support to get CRL embedded issuer details, effective and next updates details"

Also note that validating signer with revocation checking on all elements in chain​ for:

1. pdf signature itself

2. embedded timestamp signer

3. ocsp/crl signer for pdf signature

4. Ocsp/crl signer for embedded timestamp signer

needs to be added in both signing and validation process to have consistent behavior.

Waiting for your reply.

[Irfana Jaffer Sadhik]

We have logged your requirement “Support for verifying and validating timestamp signer and its OCSP and CRL signer and chain certificate during signature validation” in our database. At present, we do not have any immediate plans to implement this feature and we will implement this support in any of our upcoming releases. We usually have an interval of at least three months between releases, at the planning stage for every release cycle, we review all open features.  We will let you know when this feature is implemented.

 

Please use the below feedback link to track the status of the feature.

https://www.syncfusion.com/feedback/42671/support-for-verifying-and-validating-timestamp-signer-and-its-ocsp-and-crl-signer

[Jacobs]

Thanks Irfana,  what about the same during signing process...

And what about other inquiries in last reply.

[Santhiya Narayanan]

Thanks Irfana,  what about the same during signing process...

We have already given information regarding the update that occurred on March 28th, 2023, in this ticket.

And what about other inquiries in last reply.

We have already completed the revocation checking process for all the elements in the chain, which ensures that we can provide LTV verification information for each signature through the signature validation function. If there are any use cases that we have not implemented, we will address them when we enhance the signing process to ensure consistent behavior. Currently, we do not have any plans for this enhancement feature, but we will inform you once we consider and complete it.

[Jacobs]

Thanks 😊 ... I will be waiting for any updates.

Thanks for your usual support.