A Contract Signed in Mumbai and Read in Munich: Whose Rules Decide Whether the Signature Counts?

Cross-border contracts have always had a jurisdiction question. Electronic signatures added a second one that’s easier to miss: not which law governs the contract, but whose trust infrastructure can even confirm the signature is real.

Those are separate problems. A signature can be validly signed at the place of signing and still warn the recipient when the recipient’s program hasn’t seen the name of the authority that signed the certificate.

A Contract Signed in Mumbai and Read in Munich Whose Rules Decide Whether the Signature Counts

Two systems that don’t know each other

India has a well-defined digital signature regime. The Controller of Certifying Authorities (CAA) is issuing and regulating Certifying Authorities (CA) under the Information Technology Act, 2000, and the Information Technology Act, 2000, CCA’s API specification for eSign service indicates that it is a service that operates under the provisions of the Second Schedule of the Information Technology Act, 2000, and the e-authentication technique is Aadhaar e-KYC. The document is signed, a certificate is issued for the transaction, and the document is authenticated.

eIDAS also provides its own regime for the EU. Member states issue lists of trusted providers they have qualified. Software signature validation traverses the certificate chain and checks if the root certificate is on one of those lists.

Both systems work. Each is not necessarily seen by the other. Of course, an Indian certificate authority is not on an EU member state trusted list and an EU qualified provider is not on India’s list of qualified providers, since these are national lists that were never intended to be a single graph.

A word of caution here, as this area is subject to confident overstatement—neither the CCA, nor MeitY, nor the European Commission have issued any guidance that makes Indian digital signatures mutually recognized with EU qualified digital signatures. Nor has any of them published a statement denying it. The question doesn’t have a published answer, and anyone who claims otherwise should be requested for the document.

One Signature Different Ssytems

What this looks like at the receiving desk

The finance team in Europe receives a signed Purchase Order from an Indian supplier. They open it. This reader displays a warning, indicating the unknown status of the signature validity, or at least one signature being problematic.

The next thing that typically occurs is one of two errors.

The document is treated as ‘suspicious’ and is bounced back after days, and the supplier is irritated and does nothing wrong. Or it’s waved through because the warning always shows up in documents from that supplier, and the team has been trained to ignore the one warning they have that will alert them to a real problem.

The two errors are alike, in that both are related to mixing up separate questions.

Separating the questions

There are four questions to be answered with signature validation, and they all fail independently.

Integrity asks whether the document has been modified since it was signed. This is a hash comparison, so it’s the same no matter which country issued the certificate. It’s also the question that actually detects tampering.

Trust’s question is whether the certificate chain points to a root known to the validator. This is where the “cross-border” signatures go wrong, and it is a statement of the validator configuration rather than the document it validates.

Revocation: If the certificate was active at the time it was signed.

Timestamps: question whether there is evidence of when that time was.

Note that only the second one is jurisdictional. A document from an Indian supplier can get through integrity, revocation, and timestamp checks but not trust checks: because nobody in Europe has been told to trust that root. It is a complete document. The signature is genuine. The validator can’t vouch for the issuer.

On the other hand, a document that is not in integrity has been edited, regardless of the authority of the state that signed it. The one failure to be acted upon is that.

Getting a breakdown instead of a verdict

The solution is to have individual icons for each check, and to run cross-border documents through such a thing.

Chaindoc handles verifying a cross-border eSign document this way. It will use the EU Trusted List as trust anchor, run the file through the EU Digital Signature Service library, and provide integrity, signing certificate and certificate chain, revocation validity check, embedded timestamps and PAdES baseline profile as separate pass or fail lines. Files up to 50 MB. After a check, an e-mail address and a one-time code are asked for, and the file is not saved after this check.

The trust anchor is the EU Trusted List, and any certificate not in the EU Trusted List is still considered untrusted. Yes, that’s right – and it’s helpful because the other three lines tell you what sort of untrusted you’re dealing with. This is distinct from an altered document, where the signature has been changed. This is not an altered document, where the signature has been changed, which is a very different situation.

What to actually do about it

If the documents are signed by another jurisdiction regularly, there are three things to do.

Establish once, per supplier, what their signatures should look like. Who issues them, what types of information the certificate contains, and what a typical validation report from that supplier would include. If there is a deviation, then there is something, but today there is nothing since nobody has a baseline.

If suppliers don’t include it, request them to include a timestamp. This entails a configuration change and allows his signatures to be verified years down the road, when certificates have expired. It’s a sensible request to make in a supplier onboarding discussion, and very few ask for it.

If actual enforceability across borders is a real concern for your contractual agreement, then the form of signature is not just an IT issue that you’ll need to find out about later. Which standard, which level, whose certificate? It’s better to find it in the contract than when something goes wrong.

The part nobody likes

This does not render an Indian signature valid in Germany and a German signature valid in India. It depends on the law and the forum; it is a legal question; it requires a lawyer, not a validator.

What verification does is more narrow, but still useful: it will tell you if the file directly in front of you is the file that was signed. That question has a definite technical answer, and it takes less than a minute; if either it’s wrong, or if you reject a good document or accept a document that’s been edited, it costs more than a minute.

Popular on OTW Right Now!

Add a Comment

Your email address will not be published. Required fields are marked *