Menu
I haven't been able to find any reason of why should anyone prefer to implement a CAdES oriented electronic signature software solution over a XAdES oriented one.
There are a lot more open libraries and implementation cases and examples of XAdES on the internet, but still, I don't believe that is the reason why people decide on using XAdES over CAdES.
Is it because XAdES is XML oriented and software developers tend to love anything XML related? Is there any scenario where CAdES is just outright the best option to use over XAdES?
For reference:
927
As seen just before, the definition of a simple electronic signature is rather broad and open for interpretation. The advanced electronic signature, on the other hand, has to meet more stringent identity verification criteria and thus has a higher level of security as set out in the eIDAS Regulation.
CAdES-BES. A CAdES Basic Electronic Signature (CAdES-BES) contains: The signed user data (e.g., the signer's document), as defined in CMS ( RFC 3852 [ 4]) A collection of mandatory signed attributes, as defined in CMS ( RFC 3852 [ 4]) and in ESS ( RFC 2634 [ 5]) Additional mandatory signed attributes, defined later.
In South Africa, Advanced Electronic signatures are a subset of digital signatures. In order, to sign a document with an Advanced Electronic signature the signer must first be issued with an Advanced Electronic certificate that was issued by a South African Accreditation Authority (SAAA) accredited vendor.
One advantage of CAdES is that it generally causes less interoperability problems because the XML-DSig standard allows many options including XSLT, XPointer Framework, XML canonicalization and more. CAdES would be less demanding if only dealing with strictly DER-encoded signatures (The picture changes once you need to deal with BER encodings).
CAdES outperforms XAdES in scenarios where producing "attached" signatures on large data chunks is necessary (You want the result to be one single chunk of data that contains both the original data and the signature). The equivalent of an attached CAdES signature (The original input data is stored in the EncapContentInfo element of the CMS structure) is an Enveloping Signature. If you are required to produce such a kind of signature there is a high probability that you will run into problems when dealing with large input data if your XAdES implementation is DOM-based (those I know of are) - your machine will eventually run out of memory.
Performance would be another argument where CAdES is favoured. The message digest computation of CAdES is typically done directly on the raw bytes of the input data, XML signatures that are computed on XML documents involve a lot of overhead such as evaluation of XPath expressions, XSLT transforms, Base64 en-/decoding and Canonicalization, and potentially several Transform elements.
If you are building an archiving system for long-term validation of signatures where a lot of signatures are stored, CAdES is the preferred format due to its compactness in comparison to the textual XAdES format.
72
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
