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 on this and will provide the further details shortly.
Thanks ... also if there is an option to cancel signing operation (true/false)if no response received from selected method.
can you please elaborate on your requirement?
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.
Thank you for sharing the details. Currently, we are analyzing this and will provide further details shortly.
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.
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,
|
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?
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
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.
|
|
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,
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 20th February 2023.
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.
Another file that is not LTV , however property IsLtvEnabled = True in LTVVerificationInfo
check attached.
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. |
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)
Currently, we are analyzing the reported behavior. we will analyze further on this and will provide further details on February 28th, 2023.
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
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.
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.”
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
|
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
|
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
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.