The public key in the e-invoice

The public key (Public Key) is one half of the cryptographic pair that makes verifying your e-invoices possible. In Phase Two of e-invoicing in Saudi Arabia, your system signs every invoice with a private key, while the corresponding public key is used to verify that the signature is valid. This technical document explains the public key alone: its role in verification, how it is distributed inside an X.509 certificate (the CSID certificate), how it appears in tag 8 of the QR (Quick Response) code, and why it can be published openly without any security risk.

This article is part of the technical documentation within the e-invoicing collection, and complements the Qoyod e-invoice software. Here we focus on the public key only. The protection of the private key and the signing mechanism itself have separate documentation that we point to where relevant.

What the public key is and why we call it “public”

The public key is a mathematical number mathematically linked to a corresponding private key. The two together are called the “key pair” (Key Pair). Your system generates this pair once, at setup. What the private key signs can only be verified by the corresponding public key, and the reverse holds in cryptography.

The name “public” comes from its nature: it can be published to any party without that threatening the security of the signature. The Authority (the Zakat, Tax and Customs Authority) holds a copy of it, the buyer who receives the invoice has access to it, and any external auditor can read it. This distribution is intentional, not a vulnerability. All the security rests on the secrecy of the private key, not on hiding the public key.

In Saudi e-invoicing, the key pair is based on an elliptic curve (Elliptic Curve) of type secp256k1. This is the same curve used in other well-known technologies, and it produces a signature in ECDSA format. The public key in this case is a point on the curve, represented by two coordinates, each 256 bits long.

The core idea on which asymmetric cryptography (Asymmetric Cryptography) is built: deriving the private key from the public key is practically impossible. You can publish the public key to the whole world, and the corresponding private key remains completely secret. For this reason the Authority and the buyer can verify your invoices without either of them being able to issue a signed invoice in your name.

The role of the public key in verifying the invoice

The public key has one specific function: verification (Verification). When your system issues an e-invoice, it computes a digital fingerprint (Hash) of the invoice content using the SHA-256algorithm, then signs that fingerprint with the private key. This signature is attached to the invoice. The signature itself is a separate mechanism with its own documentation; here we trace the side that concerns the public key.

When the invoice reaches a second party, whether the Authority or the buyer, three verification steps take place:

1. The verifier computes a new fingerprint (Hash) of the received invoice content using the same SHA-256.
2. It uses the public key to decrypt the attached signature and extract the original fingerprint that the seller signed.
3. It compares the two fingerprints. If they match, the invoice is authentic and was not altered after signing. If they differ, the invoice is either forged or has been tampered with.

This comparison achieves two goals at once. The first is proving the source (Authentication): the signature is valid only with the public key corresponding to a specific private key, so its validity means the owner of that private key is the one who signed. The second is content integrity (Integrity): any change of a single character in the invoice produces a completely different fingerprint, so the match fails immediately.

This design prevents a dangerous kind of manipulation. An intermediary party cannot intercept your invoice and change the amount or the tax number, because the new fingerprint will not match the original signature. And since it does not hold your private key, it cannot re-sign. The public key is the tool that exposes this manipulation to any verifier.

A simplified example of the verification logic

The following code shows the general logic of the verification process in Python using the cryptography library. The purpose is illustrative, to understand the role, not an operational copy:

from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.exceptions import InvalidSignature

# The public key is extracted from the CSID certificate (see the next section)
public_key = certificate.public_key()

# invoice_bytes is the canonical invoice content (Canonical XML)
# signature is the signature attached to the invoice

try:
    public_key.verify(
        signature,
        invoice_bytes,
        ec.ECDSA(hashes.SHA256())
    )
    print("Signature valid: the invoice is authentic and unaltered")
except InvalidSignature:
    print("Signature invalid: the invoice is forged or tampered with")

Note that the verification function takes three inputs: the signature, the invoice content, and the fingerprint algorithm (SHA-256). The public key is what performs the operation. The private key never appears on this side at all, because verification does not need it. This is the essence of the separation of roles.

The structure and encoding of the public key

The public key in e-invoicing is not a random string, but a specific mathematical structure. On the secp256k1 curve, the public key is a point with two coordinates: an x-coordinate and a y-coordinate. Each coordinate is a 256-bit integer, that is 32 bytes. The two coordinates together give 64 bytes, to which a single prefix byte is added that specifies the representation format.

There are two common formats for representing the point:

• The uncompressed format (Uncompressed): begins with the prefix 04, followed by the full x-coordinate then the full y-coordinate. The total length is 65 bytes.
• The compressed format (Compressed): begins with the prefix 02 or 03 depending on the sign of the y-coordinate, followed by the x-coordinate alone. The total length is 33 bytes. The y is computed mathematically from the x when needed.

The CSID certificate usually uses the uncompressed format, so you find the public key beginning with the prefix 04. Whatever the format, the mathematical point is the same, and the verifier accepts either one after decoding it.

When the public key is stored inside the certificate, it is wrapped in a standard structure called SubjectPublicKeyInfo, which includes the algorithm identifier (id-ecPublicKey) and the curve identifier (secp256k1) alongside the point bytes. This wrapping makes any standard cryptography library able to read the key without prior knowledge of its source, because the structure is self-describing.

In tag 8 of the QR code, the public key is stored in almost the same structure. The verifier that reads the tag extracts the bytes and interprets them as a SubjectPublicKeyInfo structure, obtaining the point ready for use in the verification function. The unified structure between the certificate and the code simplifies the developer’s work: the same logic reads the key in both cases.

How the public key is distributed inside the CSID certificate

The public key is not sent alone and bare. It is wrapped inside a digital certificate in X.509 format, the certificate known in e-invoicing as the CSID certificate (Cryptographic Stamp Identifier). Note the letter order: CSID, not CCSI. This certificate is the container that carries the public key to everyone who needs to verify.

The Authority issues a CSID certificate for your system when you register on the Fatoora platform. The certificate binds the public key to the seller’s identity, effectively saying: “this public key belongs to this tax number and this name.” With this binding, the public key becomes trusted, because it is guaranteed by an accredited party, the Authority, not merely a number sent from an unknown source.

An X.509 certificate contains standard fields, the most notable for our purposes being:

• The public key itself (Subject Public Key Info), which is the focus of this certificate.
• The identity of the certificate holder (Subject), including the establishment’s name and tax number.
• The issuing party (Issuer), which is the Authority through its certification authority.
• The validity period (Validity), with a start and end date.
• The issuing party’s signature over the entire certificate, which is what makes it trusted.

When the buyer or the Authority receives an invoice, it reads the attached CSID certificate, extracts the public key from it, then uses it to verify the invoice signature. The certificate in this sense is the trusted transport mechanism for the public key.

Reading the public key from the CSID certificate

The CSID certificate arrives encoded in Base64 within a PEM envelope. You can inspect its contents with the OpenSSL tool to see the public key and the other fields:

# Print the contents of the CSID certificate in readable form
openssl x509 -in csid_certificate.pem -text -noout

# Extract the public key alone from the certificate
openssl x509 -in csid_certificate.pem -pubkey -noout

A brief example of what the first command shows from the public-key section:

Subject Public Key Info:
    Public Key Algorithm: id-ecPublicKey
        Public-Key: (256 bit)
        pub:
            04:a1:b2:c3:d4: ... (the coordinates of the point on the curve)
        ASN1 OID: secp256k1

The value beginning with the prefix 04 means the key is represented in uncompressed format (Uncompressed), followed by the x-coordinate then the y-coordinate, each 32 bytes. This point on the secp256k1 curve is the complete public key. Any verifier reads this point from the certificate and uses it directly in the verification function.

The two types of CSID certificate and the public-key lifecycle

The Authority issues two types of CSID certificate during the setup journey, each with its own associated public key. Understanding the difference clarifies when the public key seen by the verifier changes.

• The Compliance CSID: issued first, in the testing phase, and used to confirm that your system generates invoices that are correct in structure and signature. Its public key is dedicated to the test environment.
• The Production CSID: issued after passing compliance, and used for real invoices. Its public key is the one that actually appears in your published invoices.

This separation means the public key in the test environment differs from the production key. When moving to production, your system generates a new key pair and requests a production certificate. A verifier examining a real invoice always uses the production key embedded in its certificate or its code.

A CSID certificate has a defined validity period. As it approaches expiry, it must be renewed, and the renewal may be accompanied by generating a new key pair. This is what we call key rotation (Key Rotation). Old invoices remain verifiable with their original public key stored in their certificate, while new invoices carry the new public key.

The practical impact on the verifier is important: it should not assume the public key is constant over time. Every invoice carries its own reference to the correct public key, either through the attached certificate or through tag 8. This is why the verifier must read the key from the invoice itself, rather than storing a single key and assuming it is valid for all invoices. Qoyod manages this rotation automatically, so your invoice chain is not affected by a certificate expiring and being renewed.

The public key inside the QR (Quick Response) code and tag 8

In simplified invoices aimed at the consumer (B2C), a QR (Quick Response) code is printed on the invoice. This code is not a decorative image, but a structured data field following a format called TLV, that is a triple: a tag (Tag), a length (Length), and a value (Value). The tags are ordered by a sequential number, each with a specific meaning.

The Authority’s technical specification defines nine tags in the QR code for simplified invoices. The first tags carry visible data such as the seller’s name, tax number, time, amount, and tax value. The advanced tags carry the cryptographic data. Of these, tag 8 specifically concerns us.

Tag 8 carries the seller’s public key (Public Key), embedded inside the QR code itself. This means the public key reaches the verifier not only through the CSID certificate in the B2C case, but is also present inside the code printed on the invoice. This enables verification without needing to request the certificate from an external source.

The order of the cryptographic tags in the QR code of the simplified invoice per the specification:

• Tag 6: the invoice fingerprint (Invoice Hash).
• Tag 7: the seller’s digital signature (ECDSA Signature).
• Tag 8: the seller’s public key (Public Key).
• Tag 9: the Authority’s signature on the seller’s stamp (for simplified invoices after integration).

With tag 8 present, any reader application, including the Authority’s official app, can extract the public key directly from the code, then use it to verify the signature in tag 7 against the fingerprint in tag 6. This completes the verification loop locally, for the printed invoice, without an external connection.

Reading the tags from the QR code

The QR code content is encoded in Base64. After decoding it you get a byte string structured according to TLV. The general reading logic iterates over the bytes tag by tag:

import base64

# qr_data is the QR code content encoded in Base64
raw = base64.b64decode(qr_data)

fields = {}
i = 0
while i < len(raw):
    tag = raw[i]
    length = raw[i + 1]
    value = raw[i + 2 : i + 2 + length]
    fields[tag] = value
    i += 2 + length

# Tag 8 carries the seller’s public key
public_key_bytes = fields.get(8)
print("Public key length:", len(public_key_bytes), "bytes")

The value extracted in tag 8 is the very same public-key structure we saw in the CSID certificate. Whether the key comes from the certificate or from the code, it is the same value, because their source is one: the key pair your system generated.

Who uses the public key: the Authority, the buyer, and the auditor

The public key is a tool shared among three parties, each with a different verification context. Clarifying these contexts shows why the key must be publicly available.

The Authority is the first party. In tax invoices between establishments (B2B), the invoice is sent to the Fatoora platform before being delivered to the buyer, in a process called clearance (Clearance). The platform uses the public key to verify the seller’s signature before stamping it and returning it. Simplified invoices (B2C), meanwhile, are reported to the Authority within twenty-four hours, and the Authority verifies their signature with the public key as well.

The buyer is the second party. On receiving an invoice, the buyer or their accounting system can verify its authenticity before recording it in their books. It reads the public key from the attached CSID certificate or from tag 8, and confirms that the invoice was actually issued by the seller and was not altered. This protects them from recording a forged invoice in their accounts.

The auditor is the third party. Whether an internal or external auditor or an inspector from the Authority, they can later verify any stored invoice. As long as the public key is stored with the invoice, verification remains possible even after years, without needing to go back to the seller. This supports the requirements of record retention and long-term auditing.

The ordinary consumer is a fourth, non-technical party. When they scan the QR code on a simplified invoice with the Authority’s official app, the app performs the verification on their behalf using the public key in tag 8, and displays a simplified result confirming the invoice is valid. This gives the consumer instant confidence without knowing anything about cryptography.

In all these contexts, the tool is one: the public key. The variety of parties and the fact that verification remains possible for each of them is exactly why the key is made public. Were it secret, the buyer, auditor, and consumer could not verify, and the public auditability on which e-invoicing rests would collapse.

Why the public key can be published safely

It may seem strange that a cryptographic key is available to everyone. The reason lies in the nature of asymmetric cryptography. The key pair is designed so that the operation is practically secure in one direction only: from the private key the public key can be derived easily, but the reverse is computationally impossible.

This impossibility is not an assumption, but rests on a known mathematical difficulty called the Elliptic Curve Discrete Logarithm Problem. Solving it on a 256-bit curve requires computational power that vastly exceeds what is available today. That is why the world publishes the public key with confidence.

The roles are clearly distributed:

• The private key stays inside the seller’s system, and is used for signing only. Its secrecy is absolute. Its protection and the signing mechanism are the subject of the separate private-key documentation.
• The public key is distributed freely, and is used for verification only. Its spread is intentional.

If the public key is lost or copied, there is no harm. The most its holder can do is verify invoices the seller originally signed, an operation available to everyone by nature. Issuing a signed invoice in the seller’s name, however, requires the private key, which no one has access to. This separation is what makes the system both secure and publicly verifiable at once.

A subtle point worth clarifying: the verifier’s trust is not in the public key itself, but in the certificate that carries it. If an attacker sent a public key from a key pair they own, the verifier would not accept it, because the correct CSID certificate is signed by the Authority and binds the public key to the seller’s actual tax number. The Authority’s signature on the certificate is the source of trust, not the bare key.

How Qoyod handles the public key on your behalf

Everything above happens behind the scenes in compliant systems. The Qoyod e-invoice software software manages the full key lifecycle, so you do not need to deal with any cryptographic detail manually.

When you set up your account for Phase Two, Qoyod generates the key pair, sends the certificate request to the Fatoora platform, and receives the CSID certificate carrying your public key authenticated by the Authority. After that, it signs every invoice with the private key, embeds the public key in tag 8 of the QR code for simplified invoices, and attaches the certificate where required. This process is instant with every invoice you issue.

The role that remains yours is simple and specific: you must register your certificate with the Authority yourself through the Fatoora platform, and Qoyod guides you through this step. The Authority is not set up on your behalf automatically, but everything else, the key, signing, and verification details, happens automatically inside the system.

The practical benefit is that you get invoices verifiable by the Authority and by your customers without understanding the mathematics behind them. The system ensures your public key is in its right place: inside the certificate, inside the code, and available to every verifier, while your private key stays protected.

Public key vs. private key: separating the roles

To fix the picture, it helps to place the two roles side by side. Remember that this article concerns the public key, and that the details of protecting the private key and the signing mechanism have their own separate documentation within the e-invoicing collection.

• The public key: used for verification. Distributed openly inside the CSID certificate and in tag 8 of the QR code. Accessible to the Authority, the buyer, and any auditor. Publishing it is safe.
• The private key: used for signing. Stays secret inside the seller’s system. It does not leave to any party. Its secrecy is a condition of the security of the entire system.

The relationship between them is a fixed mathematical one: what the private key signed can only be verified by the corresponding public key. And because deriving the private from the public is practically impossible, the public can be published without compromising the private. This balance is what makes e-invoicing both publicly auditable and protected from forgery at the same time.

To go deeper into the other side, see the documentation on the digital signature in the e-invoice, which explains the signing mechanism that produces the value the public key verifies.

Frequently asked questions about the public key

Does the public key change with every invoice? No. The public key is constant throughout the validity of the CSID certificate, so all invoices issued during that period carry the same public key. It changes only when the certificate is renewed or the keys are rotated.

If someone leaks my public key, can they issue invoices in my name? No. The public key is for verification only, and does not enable its holder to sign. Issuing a signed invoice requires the private key protected inside your system.

What is the difference between the public key in the certificate and the public key in the QR code? No difference in value. Both are the same public key of the same key pair. The certificate is a transport medium authenticated by the Authority, and tag 8 embeds the key directly in the simplified invoice to ease local verification.

Do I need to read the public key manually? If you are using a compliant system such as Qoyod, no. The system handles generation, embedding, and verification. Manual reading matters to developers building their own verification tools.

A practical summary for the developer

If you are building or integrating with an invoicing system, the following points summarize what concerns the public key:

• The public key is a verification tool only. It does not sign and carries no secret.
• Its source is an ECDSA key pair on the secp256k1 curve, 256 bits long.
• The verifier accesses it via the CSID certificate in X.509 format, and also via tag 8 in the QR code for simplified invoices.
• The verifier’s trust is in the certificate signed by the Authority, not in the bare key.
• Publishing it is safe because deriving the private key from it is practically impossible.

If you want all of this without building a cryptographic layer yourself, Qoyod handles generation, signing, embedding, and binding on your behalf, so you issue Phase Two–compliant invoices from day one.