Part II: Regulation of Digital Infrastructure

So far, we have understood that the authenticity of electronic records is verified through electronic signatures. We have also understood how exactly such signatures operate. Through this Section, we will understand the legal infrastructure supporting the use of digital signatures, the licensing and regulation of Certifying Authorities, and the responsibilities of subscribers (i.e., those who apply for the digital signature certificate ("DSC") under Section 35 of the IT Act).

As discussed previously, license to issue DSCs requires an application under Section 21 of the IT Act made to the Controller of Certifying Authorities ("CCA"). Interestingly, the bare text of Section 21 allows "any person" to make such application subject to fulfilment of technical and operational standards as may be prescribed by the Central Government. These entities that are thereafter allowed to issue digital signature certificates are known as Certifying Authorities ("CAs"), and regulation of the activities of CAs is undertaken by the CCA, who is appointed by the Central Government under Section 17 of the IT Act. The CCA stands as a key nodal point of India's Public Key Infrastructure, and introduced the Root Certifying Authority of India ("RCAI") to digitally sign the public keys of the various licensed CAs. Further, it ensures compliance of CAs with Indian laws, both technical and procedural, especially as outlined under Section 30 of the IT Act.

The CCA further has the power under Sections 25 and 26 to suspend or revoke the license granted if there is some material irregularity with respect to the licensing application itself, or in the manner of functioning post issuance of license, subject to the CA being given a chance at being heard. If such suspension or revocation is carried out, a notice must be issued.

But even before this, the Rule 18 of the Information Technology (Certifying Authorities) Rules, 2010 ("CA Rules") establish that the CCA may refuse to grant a license upon application if applicants don't give required business information, are being wound up, have a court-appointed receiver, are convicted of fraud or dishonesty, fail to provide a bank guarantee, don't follow their Certification Practice Statement, fail to submit audit reports, are found unable to operate based on the audit, or don't follow the Controller's directions.

We have understood how asymmetric encryption works. This is the basis for PKI, which uses public and private keys to verify authenticity, validity and source or any DSC.

Upon validation of the application under Section 21, a set of public and private keys are generated for CAs as well. As we know, a public key is the only way by which private key encryptions may be decrypted and vice versa. Now, the public key of the CAs is digitally signed by the private key of the RCAI, and may be cross verified using its public key. This verification process is important, and is repeated throughout the PKI. This is how:

The presence of a digital signature means that there is a DSC attached to the public key of the CA. The signature of the RCAI is not applied directly to the key itself but to a hash function of the DSC of the key, which is essentially a "one-time-encryption."

For example, assume that the public key is "123." After hashing, the key will turn into a "hash" of uniform length, typically 128 or 256 characters or "bits" in length. This is known as a fixed length hash. Now, this 256-bit long hash is signed using the RCAI's private key, creating an encrypted hash. The DSC will include certain important blocks of information, such as the hash function used.

When someone wishes to authenticate the public key of the CA, they run the data (i.e., the key) through the same hash function, and decrypt the encrypted hash using the RCAI's public key (available publicly). If the decrypted hash and the new hash match in value, then the key is considered valid.

Once a CA is validated under Section 21 of the IT Act, 2000 and issued its key pair (with its public key digitally signed by the Root Certification Authority of India, or RCAI), it becomes authorized to issue Digital Signature Certificates (DSCs) to subscribers – i.e., individuals, companies, or entities seeking to use digital signatures for authentication and legal recognition of electronic documents.

The process of generating and verifying a DSC for a subscriber is conceptually similar to the CA–RCAI structure, built around public key infrastructure (PKI). The CA's role is to act as a trusted third party, vouching for the link between the subscriber and their public key.

When a subscriber applies for a DSC, the CA must first verify their identity. This can include submission of Aadhaar, PAN, passport, or organization credentials, and may also involve biometric or video-based authentication methods as mandated by the Controller of Certifying Authorities (CCA). Once the identity is authenticated, the next step is key generation.

A pair of cryptographic keys — one private and one public — is created. The private key is securely stored in a hardware token or protected software container, and is never disclosed to anyone other than the subscriber. The public key, however, is included in the Digital Signature Certificate.

To ensure that this public key genuinely belongs to the subscriber (and has not been tampered with), the CA does not sign the key itself, but rather signs a hash of the certificate contents. This includes the public key, subscriber name, certificate serial number, validity period, issuing CA name, and the hashing algorithm used. A fixed-length hash is computed from this data. The CA then encrypts this hash using its own private key, creating the digital signature that is attached to the DSC. The final certificate contains:

(i) The subscriber's public key

(ii) Identifying information

(iii) The issuing CA's name

(iv) The CA's digital signature

(v) The hash function used

This certificate is now issued to the subscriber. When the subscriber signs a document, the system uses their private key to generate a signature on that document. This is different from the certificate — the signature on the document ensures authenticity and integrity of that specific file.

Now, if a third party wants to verify the subscriber's digital signature (on a document), they must validate the underlying DSC itself. This is done as follows. The verifier extracts the public key of the issuing CA from a trusted store. Then, they:

(i) Decrypt the CA's digital signature (the encrypted hash) using the CA's public key.

(ii) Run the DSC's unsigned content (the original data, including the subscriber's public key and identity details) through the same hash function.

(iii) Compare the result of their hash with the decrypted hash.

If both hashes match, it proves that the certificate is valid and untampered. The same logic extends up the trust chain — the CA's public key is in turn validated using the RCAI's public key, available in the trusted root store of most operating systems and browsers. This chain of trust ensures the authenticity of both the CA and subscriber certificates, enabling secure digital interactions in compliance with the IT Act, 2000.

As we know, subscribers apply for DSCs under Section 35 to the CAs, whose digital signature authenticates the certificate. However, usage of DSCs is by no means unconditional.

A CA can suspend a DSC in two cases: (i) if the subscriber or someone authorised by them requests it, or (ii) if suspension is necessary in the public interest. However, if the suspension lasts more than 15 days, the subscriber must first be given a chance to be heard.

A CA can also revoke a DSC in several situations: (i) if requested by the subscriber or their authorised representative, (ii) if the subscriber has died, or (iii) if the subscriber is a firm or company that has been dissolved or wound up.

Additionally, the CA may revoke a certificate if: (a) any material fact in the certificate is false or concealed, (b) the conditions for issuing the certificate were not met, (c) the CA's private key or security system was compromised, or (d) the subscriber has been declared insolvent, is dead, or no longer exists.

In all revocation cases, the subscriber must be given an opportunity to be heard. Once a DSC is suspended or revoked, the CA must inform the subscriber and also publish a notice in the designated repository mentioned in the certificate.

Permissible and prohibited activities with respect to DSCs have been outlined under the X509 Certificate Policy for India.