WIP: xades (ETSI) implementation

[blaggacao]

• Schemata
• References
• Sign - SignedProperties (XAdES Baseline)
• Sign - SignedDataObjectProperties (XAdES Baseline) *
• Sign - UnsignedProperties (XAdES Baseline) *
• Sign - UnsignedDataObjectProperties (XAdES Baseline) *
• Verify (XAdES Baseline) *
• Augment (XAdES Baseline) *
• Sign (XAdES Extended)
• Verify (XAdES Extended) *
• Augment (XAdES Extended) *
• Test Cases (XAdES Baseline) *
• Test Cases (XAdES Extended) *
• Documentation

* kindly require patreon / sponsorship

Closes #90

[blaggacao]

@kislyuk Maybe you can quickly validate if this goes into the right direction (on a general understanding of the matter), having Schemata & References added.

Link: https://github.com/xoe-labs/signxml/tree/master/signxml/xades

[blaggacao]

I plan to use the from lxml.builder import ElementMaker any objections (I might have overseen)?

[codecov-io]

Codecov Report

Merging #139 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #139   +/-   ##
=======================================
  Coverage   94.42%   94.42%           
=======================================
  Files           3        3           
  Lines         592      592           
=======================================
  Hits          559      559           
  Misses         33       33

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f7e9963...13d3696. Read the comment docs.

[mileo]

Nice, take a look at https://github.com/m32/endesive/tree/master/endesive/xades

[blaggacao]

@mileo nice, thanks. Why do you use get_rdns_name instead of the certificates built-in RFC method? I've seen it several times now, but no explanation or code comment as to why, so I assume it's just path dependency. Do you have any I insight?

[mileo]

@blaggacao i'm not the author of endevise but you can ask it to @m32.

If he don't answer it, i can help you to check why.

Best regards

[ovnicraft]

@blaggacao nice work, so its possible add what type of XADES are implementing on this PR ? i am available to work together.

[blaggacao]

@mileo thanks, I understand. Don't mind, I'll have it on the radar anyhow. Once I know the answer, I'll post back.

@ovnicraft, I'm planning to implement all XAdES baseline signature levels. And provide some kind of extensibility to work with extended signatures (such as BES, EPES and others). Implementation of extended signatures often depend on the concrete policy adopted, so some kind of hook might be best.
I've also planned a switch to produce legacy XAdES signatures (currently the most widely adopted once).

[blaggacao]

I need the base64 encoded DER representation of ASN.1 IssuerSerial type as defined in https://www.ietf.org/rfc/rfc5035.txt

Can anyone help me out how to produce this struct and how to DER encode it afterwards (in python)?

I've seen OpenSSL 3.0, once released, will have support for this struct, but that's not yet available.

[ovnicraft]

Maybe links to help:

• https://cryptography.io/en/latest/hazmat/primitives/asymmetric/serialization/#der
• http://snmplabs.com/pyasn1/pyasn1/codec/der/contents.html?highlight=der#pyasn1.codec.der.encoder.encode
• https://www.pyopenssl.org/en/stable/api/crypto.html#x509-objects

Last one IMO has a API to read serial from cert with one func, then could be encoded with asn1.

[kislyuk]

@blaggacao the code overall looks good and I would encourage you to finish the PR if you can.

The links from @ovnicraft seem sufficient to answer your most recent question.

Also, the dependency version ranges are set specifically to match versions of binary packagess available in Ubuntu 18.04, please don't change them unless you have a specific reason.

Thanks for your work on this.

[blaggacao]

@kislyuk Thanks for your feedback. We'll be pushing this until a basic implementation serves our underlying use case.

Once we are there, and after some polishing, I'd ping you again for some final code review. Somewhere early next year.

Sorry for the deps, that might have been github's dependabot. Should be easily revertable.

@Deiber for such and review reasons, please care not to force push, even if it's your branch. We can squash later without problem into a clean git history. Our commit msg standards shall not apply until that squash, no worries 😉

[pokoli]

Hi,

Thanks all who put some efforts on this work.
I will like to know which is the state of this PR and if anyone is working on it?
We need xades signature for one of our projects, so if nobody is working on it we may take the current work and continue.

We are at planning phase and explorint the alternatives. We need some software to sign xml documents using xades and we prefer to contribute it to a well maintaned librarly than developing a custom solution.

Reggards

[blaggacao]

Hi @pokoli I'm completely disengaged with this PR and it's basicalky unmaintained. Hence, feel free to take and own it. That would be a more than satisfactory outcome of this PR.

[ovnicraft]

@pokoli sound great, also I opened this xoe-labs#1, adding some info needed.

[pokoli]

Hi, I just updated the current PR to current develop branch and make the test suite pass.
I have the fear that I broke some of the exiting functionality so before going further I will like to have some test suite to ensure that what was already.

I guess I will need to create a xades folder in the tests/interop folder and include an include all the required tests there. My plan is to create a simple test case and start adding more about them. Is there any guideliness for writing tests cases?

I see there is no documentation about how to run the xades signing. I think it will be great to include any. Can someone that already worked on such PR provide some example so I can include it (without reverse enginering the code).

Thanks in advance.

[pokoli]

BTW: I pushed my work to https://github.com/pokoli/signxml/tree/xades

I prefered to not create a new one until not requested. Maybe someone can give me access to the exsiting branch so I can update it or maybe the maintainers should update the branch of the pull request. In any case, let me know if something from my side is missing.

[pokoli]

I pushed new work which contains some basic testing and adapted the PR to latest tip functionalities.
I will try to work on a validator soon to ensure everything works well.

[ovnicraft]

@pokoli great so can you open a new PR and link this one for the record, we can continue review and tests on yours.

[ovnicraft]

@pokoli Also about your code an DER-instance for types you can check this code https://github.com/xoe-labs/signxml/pull/1/files and re used to complete the job :)

[pokoli]

I had some time to continue working on it.. I've tested on a Electronic document signed with Xades and XMLVerify is capable of verifing it. But I'm not able to verify my own document on the tests suite:

If I sue the x509_cert=cert I get the following result:

signxml.exceptions.InvalidSignature: Signature verification failed: bad signature

but if I remove such argument I get:

OpenSSL.crypto.X509StoreContextError: [20, 0, 'unable to get local issuer certificate']

Is expected to use the x509_cert argument in tests? Or how should I validate the signed document?

[pokoli]

@pokoli Also about your code an DER-instance for types you can check this code https://github.com/xoe-labs/signxml/pull/1/files and re used to complete the job :)

@ovnicraft Could you rebase your PR into my branch (https://github.com/pokoli/signxml/tree/xades) I will createa a new PR with my work in the following days. So it will be great to include you work also here.

[kislyuk]

Thanks everyone for your work on this PR. XAdES support was added in v3.0.0 using a different code structure. Please test v3.0.0 and let us know whether it suits your needs.