Xades-X-L and a xades-A support #146
Conversation
Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
CertificateValues and RevocationValues contain certificates, CRLs and OCSP responses that can be useful in validation of Signature. Parse them and add to intermediate certs and CRLs CertStore for later use Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
…form Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
XAdES-X-L form should contain all the data needed to verify both the Attributes (TimeStamps) and Signature, the only data needed are the CAs that validate the CRLs and leaf certificates (user and TSA) uses minimal validity periods (certificate loose their validity as soon as they're not needed) and minimum of verification anchors (during validaton only one leaf certificate is valid at a time) Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Sun implementation of X509CRLSelector doesn't return CRLs published after the date provided to it using the setDateAndTime() method this makes it very hard to validate certificates in the past (one needs CRL from time of verification) and impossible to enforce grace period (which requires using CRLs published after the time of verification). The correct behaviour is in Bouncy Castle provider, so use it instead. http://java.sun.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html#X509CRLSelector http://www.bouncycastle.org/jira/browse/BJA-249 Signed-off-by: Tiago Rossi <[email protected]>
Use new verifier implementation, for now it's mostly a copy of the old verifier. Signed-off-by: Tiago Rossi <[email protected]>
default unmarshaller doesn't remember relations between properties and XML nodes, create one that does To make it possible, we need property data collector that can store relationship between property and XML node, add such one Signed-off-by: Tiago Rossi <[email protected]>
default verifier doesn't know how to use the Elements that HybridQualifyingPropertiesUnmarshaller collected, add one that knows how to use them and pass this additional informatino to property verifiers Signed-off-by: Tiago Rossi <[email protected]>
SigAndRefsTimeStamp must take properties in the order of appearence within the signature. Previous mechanism used deterministic algorithm to put properties in specific order. Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Sun X509CRLSelector doesn't return CRLs that were published "in future", but to properly validate signature we have to use time from earliest valid time stamp implement custom CRLSelector that returns usable CRLs Signed-off-by: Tiago Rossi <[email protected]>
If we're validating advanced forms of XAdES (C and above), we can sometimes get CRLs that look as if they came from future Signed-off-by: Tiago Rossi <[email protected]>
If we're validating advanced forms of XAdES, we need to provide validator with certificates and CRLs we found in Properties, they can be empty so we should be able handle this case gracefully Signed-off-by: Tiago Rossi <[email protected]>
when dealing with XAdES-X-L form, we may have full revocation data at hand, then the verification needs only trust anchors (CA certificates) but we must allow for collection of those certificates and CRLs during validation of the EncapsulatedPKIData properties: CertificateValues, RevocationValues, AttrAuthoritiesCertValues and AttributeRevocationValues Signed-off-by: Tiago Rossi <[email protected]>
change of verificato to soft-fail made the exception thrown different Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
Signed-off-by: Tiago Rossi <[email protected]>
permit add monitoring off tsa service
|
Hi, Wow, this is a huge amount of work. I see it is based on previous work from Hubert Kario. I recall having some discussions with him at the time and we had different vision/ideas about the implementation of this support.. Since the commit list is very large, any chance you can do a brief summary of the approach and the major changes to get me started on the analysis? A simple bullet list would help.. Thanks |
|
Hi, As you could see the work was really based on Hubert Kario code. We have been applying his patches and started from that point just applying small fixes and certificate updates. So, i'm not abble to tell you an explanation about all Hubert Kario changes, but i think the main point is the replacement of XadesVerifierImpl by XadesHybridVerifierImpl and DefaultQualifyingPropertiesUnmarshaller by HybridQualifyingPropertiesUnmarshaller, classes that uses JAXB to unmarshall some parts of the signature properties. As reference here are the posts where we got the patches: |
|
Hi @tiarossi
|
…into feature/xades-x-l-a # Conflicts: # pom.xml # src/main/java/xades4j/providers/impl/AuthenticatedTimeStampTokenProvider.java # src/main/java/xades4j/providers/impl/DefaultTimeStampTokenProvider.java # src/main/java/xades4j/verification/CommitmentTypeVerifier.java # src/main/java/xades4j/verification/QualifyingPropertiesVerifierImpl.java # src/main/java/xades4j/verification/SignatureUtils.java # src/main/java/xades4j/verification/XadesVerificationProfile.java # src/test/cert/csrc.nist/readme.txt # src/test/cert/csrc.nist/trustAnchor # src/test/cert/gva/readme.txt # src/test/cert/gva/rootgva_der.crl # src/test/cert/gva/rootgva_der_0?2?_05_2011 .crl # src/test/cert/my/myStore # src/test/cert/my/readme.txt # src/test/java/xades4j/production/SignerBESTest.java # src/test/java/xades4j/verification/VerifierTestBase.java # src/test/java/xades4j/verification/XadesVerifierImplTest.java # src/test/xml/detached.bes.xml # src/test/xml/detached.c.xml # src/test/xml/document.signed.bes.extres.xml # src/test/xml/document.signed.bes.xml # src/test/xml/document.signed.c.xml # src/test/xml/document.signed.epes.xml # src/test/xml/document.signed.t.bes.xml # src/test/xml/document.signed.t.epes.xml
|
OK @luisgoncalves. I'm not sure how to do that. Do i need to submit a new pull request ? |
|
I think you can do the changes and push them on your fork's branch. The PR
will be updated.
…On 5 Feb 2018 18:51, "tiarossi" ***@***.***> wrote:
OK @luisgoncalves <https://github.com/luisgoncalves>.
I'm not sure how to do that. Do i need to submit a new pull request ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADyghakWMCNlZofwEeZ0rpN-oyNGIkwWks5tR023gaJpZM4RhE5X>
.
|
|
Done |
|
Hello @tiarossi. I've (slowly) getting back context about extended forms and all the discussions I had with Hubert. From what I've got so far, he had some requirements very specific to his use-cases.. Can you say something about your use cases? For instance, what are the form transitions that you are using? Which form do you start with? Are you adding multiple Thanks! |
|
Hello @luisgoncalves, We start with XAdES-EPES, then we extend it to XAdES-C, then XAdES-XL, and finally XAdES-A. |
|
@leandrocosta I meant whether the generated signatures are being validated by other XADES implementations or if you are using xades4j to validate XAdES-X-L or -A created by third parties. Thanks. |
|
@luisgoncalves Our XAdES-A signed documents were successfully validated by |
|
This is a lot of code and, from a preliminary review, it includes a lot of breaking changes. I'm merging into a feature branch and I'll keep learning about the new code to decide the next steps. Thank you very much - all of you - for compiling the patches and contributing back. Since these changes were applied on top of a codebase that wasn't designed to support extended forms in the first place, if you have suggestions of things that could be different/improved in the current state of the implementation, feel free to leave them here or in a new issue. |
Extends xades4j adding xades-X-L and xades-A support