Security issues with electronic invoices

> How would you digitally sign a Json document and embed the signature in the document?

You would not, because that's exactly how you get these bugs. Fortunately serialization mechanisms, whether JSON or Protobuf or XML or anything else, turn structured data into strings of bytes, and signature schemes operate on strings of bytes, so you'll have a great time signing data _after_ serializing it.

Hash: SHA1

> How would you digitally sign a Json document and embed the signature in the document?

Embedding a signature into the same file is easy enough.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v0.9.7 (GNU/Linux)

iEYEARECAAYFAjdYCQoACgkQJ9S6ULt1dqz6IwCfQ7wP6i/i8HhbcOSKF4ELyQB1

oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k =y6kj

-----END PGP SIGNATURE-----

This avoids JSON-inside-JSOn and allows to pretty-print the original object with the signature.

Presumably the same way you accomplish the thing in xml:

    { “signature”: “…”, “payload”: … }

Or at all.

> How would you digitally sign a Json document and embed the signature in the document?

Preferrably you wouldn't because that's a really bad idea.

That said, this type of support-every-conceivable-idea design-by-committee systems would be equally bad built on json or anything else. That much is true.

There's probably no silver bullet here. But that is still not an excuse for XML-Sig.

    invoice.inv (zip archive)
    └- payload.json
    └- signature.asc

It's effectively what the Java jar is.

For example, in the USA https://www.rcfp.org/briefs-comments/astm-v-upcodes-inc/

This is an especially hot topic in the EU in medical device regulations: https://www.bsigroup.com/en-GB/insights-and-media/insights/b...

But yes, for commercial offers, presumption of conformity mean you have to pay for norms to adhere to law. Big fail.

Especially since non-commercial but persistent and public, not "for profit", is still surmised in e.g. warranty laws. (E.g. geschäftsmäßige Nutzung / usage with said two terms, even for F/LOSS)

You mean the government that’s already the tax authority for which you create and report invoices? I can promise you it’s a good thing. Electronic invoices are a lot easier for us (obviously since it’s just a click instead of a whole PDF operation). It also removes a whole bunch of possibilities for mistakes.

> you have to pay to see the entire standard

The article is wrong about that though, all technical docs are available via the europa portal and reference implementation examples.

That said, I actually agree with you - it's crazy that we need to pay for a stupid standard document.

Actually, most governmental agencies (which have required e-invoices for many years), only accept the pure XML files. Zugferd is a bit of an interim solution until everybody is familiar with an e-invoice visualizer. There are already many free (as in beer and source) solutions available for that. Zugferd (X-Factur) is a problematic standard, because there can be discrepancies between the PDF and the embedded file and its unclear, which is authorative. Concerning the platforms: I don't know about France, but in Germany, sending e-invoices by e-mail is explicitly permitted by the government.

The invoicing standard is an attempt to mitigate reverse charge fraud by gathering more machine-readable data. Some countries even demand that b2b invoices are sent to the country, which then dispatches a copy to the recipient.

Knowing this background, it's pretty clear why the EU is making it mandatory.

Personally, in the abstract I like the idea to mandate the use of an open standard, I think we have way too many inefficiencies from treating many things as text documents that could be data structures. I don't like this particular standard though, it's bloated and the result of a typical top-down process.

I much prefer it when there are competing standards for a while, and one or a couple of winner emerge on technical merits. THEN I have no objections to a regulatory body picking a standard and mandating it.

Besides, many standards have been created over the past 20 years, yet most invoices are still only sent as PDF.

[1] https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=arithmetic...

People invent their own standard to make their own lives easier at the cost of making everyone else's lives miserable which is exactly what the European Committee for Standardization was intended to prevent.

You must be new to the internet /s

A company does not gain anything by sending "better" invoices that follow a standard. Only if they receive standardized invoices, but usually not enough to pay extra for it. The fact that standardized invoices haven't happened yet without legislation should be proof of that

In some member states, like Germany, the EDIFACT format, when compliant with the EN 16931 data model, is accepted as a valid e-invoice format.

EN 16931 defines what information needs to be in an invoice (the data model), while EDIFACT INVOIC defines how that information is structured and formatted for electronic transmission (the syntax).