Public-Key Infrastructure

Get access to whole semester resourcesSemester Pass

Chapter Sixty-Six

Syllabus topic Module 2, "Authentication Applications: Public-Key Infrastructure"

Pages 425 to 433 of 678

In one line

A public-key infrastructure is everything around the certificate: the authorities that issue it, the people who check who you are, the places certificates are published, and the rules and procedures that make a stranger's signature worth trusting.

In the words an answer should use, which are RFC 4949's: a PKI is "the set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography". The PKIX model built on X.509 recognises five components: end entities, certification authorities (CAs), registration authorities (RAs), CRL issuers and repositories.

Why "infrastructure"

The last two chapters treated a certificate as a finished object: here it is, verify it. A certificate had to come from somewhere. Someone checked that the person applying was who they said. Someone generated a key and kept the private half safe. Someone published the certificate where others could find it, and someone must be told the day the key is stolen.

The cryptography is the easy part. A signature takes milliseconds. Checking a person's identity, keeping a root key offline for twenty years, and running a revocation service are organisations, not algorithms, and together they are what the word infrastructure means.

The five components

RFC 5280 s.3 sets out the model that Internet PKI specifications assume.

Component	What it does	Example from the last two chapters
End entity	the subject of a certificate, or a user of certificates	munotes.in; a browser checking it
Certification authority (CA)	issues certificates by signing them, and is responsible for saying which of them are revoked	Let's Encrypt YE1
Registration authority (RA)	an optional body to which a CA delegates some management work, above all checking identities; it signs nothing	in India, the offices that check an applicant's documents for a licensed CA
CRL issuer	generates and signs revocation lists; usually the CA itself, but it may delegate	YE1, signing list 17
Repository	stores certificates and CRLs and hands them out	`ye1.i.lencr.org` and `ye1.c.lencr.org`

The RA is the component examiners probe, because it is the one that is easy to misstate. RFC 4949 defines it as an entity that "does not sign either digital certificates or CRLs" but records or verifies the information, "particularly the identities of subjects", that a CA needs. The CA keeps the signing key and the signing decision; the RA does the legwork, which in a country the size of India is most of the work.

The management functions

RFC 5280 s.3.5 lists seven functions that a PKI's management protocols may have to support. Each is a step in a certificate's life.

Function	What happens
Registration	the user first makes itself known to a CA, directly or through an RA, before any certificate is issued
Initialisation	the user's system is given what it needs to operate: the public keys of the CAs it will trust, and usually its own key pair
Certification	the CA issues a certificate for the user's public key, returns it, and may post it in a repository
Key pair recovery	a backed-up private key, used for encryption, is restored after the user loses it
Key pair update	a key pair is replaced with a new one, with a new certificate, as all key pairs must be regularly
Revocation request	an authorised person tells the CA something is wrong and the certificate must be revoked
Cross-certification	two CAs exchange what they need to issue a cross-certificate, one CA certifying another's signing key

Public-Key Infrastructure

Key pair recovery is for encryption keys only, and the reason is worth stating. A lost encryption key means data that can never be decrypted again, so a copy is kept. A signing key is never backed up by anyone but its owner: RFC 4949 notes that requiring a client to generate its own signature key pair "helps maintain system integrity", because then only the client ever possesses the private key. A signature is worth something only if nobody else could have made it.

How a CA says how it works

A certificate is only as good as the checks behind it, so a CA publishes them. A certificate policy says what a certificate may be relied on for; a certification practice statement (CPS) describes how the CA actually operates: how it checks identities, protects its keys and handles revocation. The certificate names its policy in the certificate policies extension, as munotes.in's names the CA/Browser Forum's domain-validated policy. India's Act writes the CPS into law: an application for a certificate under section 35(3) is accompanied by a certification practice statement.

Trust models: how separate PKIs come to trust each other

A PKI serving one organisation can have one root. The problem begins when two PKIs must trust each other. RFC 4158 describes the structures in use.

Hierarchical. One root CA, which certifies subordinate CAs, which certify end entities. Certificates are issued in one direction only and a CA never certifies one above it. Path building is simple: fetch each issuer's certificate until you reach the root. The trust list is the variation every browser uses: not one root but a list of them, "dozens to more than one hundred" in RFC 4158's words, any of which will do. RFC 4158 names its weakness plainly: the user "may have little or no idea of the policies or operating practices" of the roots, and the compromise of any one of them may compromise the whole system.

Public-Key Infrastructure

Mesh. No single root. CAs are peers, and each cross-certifies the others, so each user starts from their own CA. Nothing is superior to anything else, and that is the problem: there are many paths between any two points, and a validator looking for one can wander through a very large number of them.

Bilateral cross-certification. Two existing PKIs join by having their roots certify each other. Workable for two or three; for many, the number of agreements grows with the square of their number.

Bridge. A bridge CA is a hub that issues no certificates to end users. Each PKI cross-certifies with the bridge alone, so every PKI can reach every other in two steps, and each new PKI adds one agreement, not one per existing member.

The fifth model, which gives up authorities altogether and lets users vouch for each other, is PGP's web of trust, the subject of the next three chapters.

India's PKI under the Information Technology Act

The PKI an Indian student will actually use is the one the IT Act 2000 creates for electronic signatures: the one behind every electronic signature certificate issued under the Act.

The Controller of Certifying Authorities. Section 17 lets the Central Government appoint a Controller, who works under its general control. Section 18 lists the Controller's functions, fourteen of them, and one is the root of the whole system: clause (b), "certifying public keys of the Certifying Authorities". The Controller's office describes what it built on that clause: it "has established the RCAI under section 18(b) of the IT Act to digitally sign the public keys of CAs in the country". RCAI is the Root Certifying Authority of India, the trust anchor for every Indian electronic signature certificate. Its root certificate "CCA India 2022", valid until 2042, is published on the Controller's website, where the Controller says the keys it signs "can be verified by a relying party".

The Certifying Authorities. Under section 21 any person may apply to the Controller for a licence to issue electronic signature certificates, and no licence issues unless the applicant meets prescribed requirements of qualification, expertise, manpower, finance and infrastructure. A licence is not transferable or heritable. On 30 September 2026 the Controller's disclosure-records page listed 23 licensed CAs, among them e-Mudhra, (n)Code Solutions, Capricorn, IDRBT, CDAC and the Indian Army, Navy and Air Force. Section 19 lets the Controller recognise a foreign CA, whose certificates are then valid under the Act.

The certificate's life, as the Act writes it.

Application, section 35: to a CA, with a fee not exceeding twenty-five thousand rupees and a certification practice statement or a statement of particulars; the CA may grant it, or reject it for reasons recorded in writing and only after giving the applicant a reasonable opportunity to show cause.
Representations, section 36: in issuing, the CA certifies among other things that the subscriber holds the private key matching the public key listed, that the two form a functioning key pair, and that the information in the certificate is accurate.
Key generation, section 40: the subscriber generates the key pair, by applying the security procedure. The private key is the subscriber's, not the CA's.
Acceptance, section 41: a subscriber accepts a certificate by publishing it or otherwise showing approval, and by accepting certifies to everyone who reasonably relies on it that they hold the private key and that their representations were true.
Suspension, section 37: on the subscriber's request, or in the public interest; not beyond fifteen days unless the subscriber has been heard.
Revocation, section 38: on request, on death, on the dissolution of a firm or company; or where a material fact was false, a requirement was not met, or the CA's own private key or security system was compromised; not without a hearing.
Notice, section 39: a suspension or revocation is published in the repository named in the certificate.
Control of the private key, section 42: the subscriber must take reasonable care to keep control of it, and if it is compromised must tell the CA without delay. The Explanation is the sentence to remember: the subscriber "shall be liable till he has informed the Certifying Authority that the private key has been compromised".

Public-Key Infrastructure

eSign. For a person who does not own a token, the Controller's office describes an online service in which the user is authenticated by e-KYC, with a one-time password or a biometric, and a certificate is issued for a key pair made in a hardware security module, whose private key is "destroyed immediately after one time use". The Act makes room for techniques of this kind in section 3A, which lets an electronic authentication technique listed in its Second Schedule be used if it is reliable.

Mapped onto the PKIX model:

PKIX term	Indian PKI under the IT Act
Trust anchor, root CA	RCAI, operated by the Controller, s.18(b)
Policy authority	the Controller, who licenses CAs and lays down their standards, s.18 and s.21
CA	a licensed Certifying Authority
End entity	the subscriber
Registration authority	the CA's own identity-checking arrangements; the Act puts the duty on the CA
Repository	the repository named in the certificate, s.39
Certificate hold	suspension, s.37
Revocation	revocation, s.38

Public-Key Infrastructure

The run: a link of India's PKI, and the cost of each trust model

The two files are real: the Controller's root certificate, and the CA certificate it issued to eMudhra, one of the licensed CAs, both downloaded from the Controller's website.

The listing verifies the second against the first exactly as the previous chapter verified munotes.in's chain, RSA with SHA-256 from integers alone. Then it builds a mesh of k PKIs and a bridge joining k PKIs, and counts both the certificates each needs and every route a validator could follow from one PKI to another without visiting a CA twice.

# India's PKI, one real link verified; then what each trust structure costs, counted.
import base64, datetime, hashlib, itertools

def der(path):
    lines = open(path).read().split('\n')
    return base64.b64decode(''.join(l for l in lines if l and not l.startswith('-----')))

def tlv(d, i):
    tag, n, j = d[i], d[i + 1], i + 2
    if n & 0x80:
        k = n & 0x7F
        n, j = int.from_bytes(d[j:j + k], 'big'), j + k
    return tag, j, j + n

def items(d, s, e):
    out = []
    while s < e:
        t, a, b = tlv(d, s)
        out.append((t, a, b, s)); s = b
    return out

def oid(b):
    arcs, v = [b[0] // 40, b[0] % 40], 0
    for x in b[1:]:
        v = (v << 7) | (x & 0x7F)
        if not x & 0x80: arcs.append(v); v = 0
    return '.'.join(map(str, arcs))

def common_name(d, s, e):
    for _, s1, e1, _ in items(d, s, e):
        for _, s2, e2, _ in items(d, s1, e1):
            (_, a, b, _), (_, c, f, _) = items(d, s2, e2)
            if oid(d[a:b]) == '2.5.4.3':
                return d[c:f].decode()

def parse(path):
    d = der(path)
    _, s, e = tlv(d, 0)
    (_, ts, te, t0), _, (_, ss, se, _) = items(d, s, e)
    f = items(d, ts, te)
    v = items(d, f[4][1], f[4][2])
    spki = items(d, f[6][1], f[6][2])
    key = d[spki[1][1] + 1:spki[1][2]]
    (_, a, b, _), (_, x, y, _) = items(key, *tlv(key, 0)[1:])
    c = {'tbs': d[t0:te], 'issuer': common_name(d, f[3][1], f[3][2]),
         'subject': common_name(d, f[5][1], f[5][2]),
         'from': datetime.datetime.strptime(d[v[0][1]:v[0][2]].decode(), '%y%m%d%H%M%SZ').date(),
         'until': datetime.datetime.strptime(d[v[1][1]:v[1][2]].decode(), '%y%m%d%H%M%SZ').date(),
         'n': int.from_bytes(key[a:b], 'big'), 'e': int.from_bytes(key[x:y], 'big'),
         'sig': int.from_bytes(d[ss + 1:se], 'big'), 'ca': False, 'path': None}
    for _, xs, xe, _ in items(d, *tlv(d, f[7][1])[1:]):
        p = items(d, xs, xe)
        if oid(d[p[0][1]:p[0][2]]) == '2.5.29.19':
            inner = items(d, *tlv(d, p[-1][1])[1:])
            c['ca'] = bool(inner and inner[0][0] == 1 and d[inner[0][1]])
            c['path'] = next((int.from_bytes(d[a:b], 'big') for t, a, b, _ in inner if t == 2),
                             None)
    return c

def rsa_sha256_ok(cert, issuer):           # RFC 8017, RSASSA-PKCS1-v1_5 with SHA-256
    size = (issuer['n'].bit_length() + 7) // 8
    em = pow(cert['sig'], issuer['e'], issuer['n']).to_bytes(size, 'big')
    tail = bytes.fromhex('3031300d060960864801650304020105000420') + \
        hashlib.sha256(cert['tbs']).digest()
    return em == b'\x00\x01' + b'\xff' * (size - 3 - len(tail)) + b'\x00' + tail

root, ca = parse('cca-india-2022.pem'), parse('emudhra-ca-2022.pem')
print('INDIA\'S PKI: THE CONTROLLER\'S ROOT AND ONE LICENSED CA')
for c in (root, ca):
    limit = '' if c['path'] is None else ', at most %d CA below it' % c['path']
    print('  %-17s issued by %-15s %s to %s   RSA-%d   CA: %s%s' % (
        c['subject'], c['issuer'], c['from'], c['until'], c['n'].bit_length(),
        'yes' if c['ca'] else 'no', limit))
print('  the root signs itself                          :', rsa_sha256_ok(root, root))
print('  e-Mudhra\'s certificate verifies with the root  :', rsa_sha256_ok(ca, root))
forged = dict(ca, tbs=ca['tbs'].replace(b'e-Mudhra CA 2022', b'e-Mudhra CA 2023'))
assert forged['tbs'] != ca['tbs']
print('  the same, with its name changed by one digit   :', rsa_sha256_ok(forged, root))

# ---- trust structures ------------------------------------------------------------------------
def paths(graph, a, b):                   # every route from a to b that repeats no CA
    count, stack = 0, [(a, {a})]
    while stack:
        node, seen = stack.pop()
        for nxt in graph[node]:
            if nxt == b:
                count += 1
            elif nxt not in seen:
                stack.append((nxt, seen | {nxt}))
    return count

print()
print('JOINING k SEPARATE PKIs SO EACH TRUSTS THE OTHERS')
print('     k   mesh: certificates   routes A to B   bridge: certificates   routes A to B')
for k in (3, 4, 6, 8, 10):
    names = ['PKI%d' % i for i in range(k)]
    mesh = {x: [y for y in names if y != x] for x in names}
    bridge = {x: ['BRIDGE'] for x in names}
    bridge['BRIDGE'] = list(names)
    print('  %4d   %18d   %13s   %20d   %13d' % (
        k, sum(len(v) for v in mesh.values()), f"{paths(mesh, 'PKI0', 'PKI1'):,}",
        sum(len(v) for v in bridge.values()), paths(bridge, 'PKI0', 'PKI1')))

Public-Key Infrastructure

INDIA'S PKI: THE CONTROLLER'S ROOT AND ONE LICENSED CA
  CCA India 2022    issued by CCA India 2022  2022-02-02 to 2042-02-02   RSA-4096   CA: yes
  e-Mudhra CA 2022  issued by CCA India 2022  2022-02-16 to 2032-02-16   RSA-2048   CA: yes, at most 1 CA below it
  the root signs itself                          : True
  e-Mudhra's certificate verifies with the root  : True
  the same, with its name changed by one digit   : False

JOINING k SEPARATE PKIs SO EACH TRUSTS THE OTHERS
     k   mesh: certificates   routes A to B   bridge: certificates   routes A to B
     3                    6               2                      6               1
     4                   12               5                      8               1
     6                   30              65                     12               1
     8                   56           1,957                     16               1
    10                   90         109,601                     20               1

What the run establishes, in order.

India's PKI is a hierarchy with a real root. CCA India 2022 is self-signed, with a 4,096-bit RSA key, valid for twenty years from February 2022. e-Mudhra CA 2022 is signed by it and verifies; its basic constraints allow one further level of CA below it.

Public-Key Infrastructure

One digit changed and the verification fails, exactly as with a website's certificate. The cryptography of India's PKI and of the web's is the same.

A mesh multiplies routes; a bridge does not. Ten PKIs fully cross-certified need 10 × 9 = 90 cross-certificates and offer 109,601 different routes between two of them; the same ten joined through a bridge need 2 × 10 = 20 certificates and offer exactly one route. A validator in a mesh must search; in a bridge it cannot get lost.

Worked example: a digital signature certificate for Asha's company

Asha is a director of a company that must file a return electronically, and the filing must carry her electronic signature.

Registration. She applies to a licensed CA under section 35, with the fee and the documents the CA's identity checks require. The identity checking is registration-authority work; the CA takes the signing decision.
Key generation. Her key pair is generated on her side, under section 40, for example inside a cryptographic token, so that the private key never leaves it.
Certification. The CA verifies her identity and her request and issues a certificate binding her name to her public key, signed by the CA's key, which is itself certified by RCAI. Its representations under section 36 are now the CA's legal responsibility.
Acceptance. She accepts the certificate, and under section 41 certifies to anyone relying on it that she holds the private key.
Use. She signs the return. The receiving portal verifies her signature with her public key, her certificate with the CA's, and the CA's with RCAI's root.
Loss. Her token is stolen. Under section 42 she must tell the CA without delay, and she remains liable for signatures made with the key until she does. The CA revokes the certificate under section 38 and publishes the notice under section 39.

Distinctions that carry marks

	Certification authority	Registration authority
Signs certificates and CRLs	yes	never
Checks the applicant's identity	may	usually, that is its purpose
Required in a PKI	yes	optional

	Hierarchy	Mesh	Bridge
Root	one (or a trust list)	none; each user trusts its own CA	none; a hub issues no end-user certificates
Certificates to join k PKIs	not applicable	k(k - 1), every pair both ways	2k, each PKI with the bridge
Paths between two points	one	many, growing explosively	one, through the bridge
Example	India's RCAI; browsers' trust lists	peer organisations	a hub joining several organisations' PKIs

	Suspension, IT Act s.37	Revocation, IT Act s.38
Effect	temporary	permanent
Limit	not beyond 15 days without a hearing	not without a hearing
X.509 counterpart	`certificateHold`	revocation with a reason code

Public-Key Infrastructure

What beginners get wrong here

Saying the registration authority issues certificates. It never signs anything. It verifies identities for the CA.

Equating PKI with certificates. A certificate is one product of a PKI. The infrastructure is the people, policies and procedures that make the certificate trustworthy.

Thinking the CA keeps the subscriber's private signing key. Under section 40 the subscriber generates the key pair, and a signing key is never backed up by anyone else. Key pair recovery is for encryption keys.

Assuming a browser's roots and India's root are the same list. RCAI is the trust anchor the Controller operates for electronic signatures under the Act, and the Controller's site is where a relying party is directed to verify the keys it signs.

Forgetting the subscriber's liability. Until the subscriber tells the CA that the key is compromised, section 42 keeps them liable.

Quick revision

PKI (RFC 4949): hardware, software, people, policies and procedures to create, manage, store, distribute and revoke certificates.
Five PKIX components (RFC 5280 s.3): end entity, CA, RA (optional, signs nothing), CRL issuer, repository.
Seven management functions (s.3.5): registration, initialisation, certification, key pair recovery (encryption keys only), key pair update, revocation request, cross-certification.
Trust models (RFC 4158): hierarchy and the browsers' trust list; mesh; bilateral cross-certification; bridge. Ten PKIs: mesh 90 certificates and 109,601 routes; bridge 20 and one.
India: Controller (s.17); functions (s.18), including (b) certifying CAs' public keys, done by RCAI; licences (s.21); 23 licensed CAs (30 September 2026); root CCA India 2022.
Certificate's life under the Act: application (s.35), representations (s.36), suspension up to 15 days without hearing (s.37), revocation (s.38), notice in repository (s.39), key generated by the subscriber (s.40), acceptance (s.41), liability until the CA is told (s.42). eSign: e-KYC and a one-time key in an HSM.

Test yourself

1. Name the five components of the PKIX model and state what each does. The end entity, the subject or user of certificates; the certification authority, which issues and signs certificates and indicates their revocation status; the registration authority, an optional body to which a CA delegates management tasks such as verifying identities, and which signs nothing; the CRL issuer, which generates and signs revocation lists, usually the CA itself; and the repository, which stores certificates and CRLs and distributes them to end entities.

2. Distinguish a CA from an RA. The CA holds the signing key: it signs certificates and revocation lists and bears responsibility for them. The RA is optional and never signs either; it performs delegated work such as authenticating applicants' identities, assigning names, distributing tokens and receiving revocation reports, so that the CA can make its decisions on verified information.

Public-Key Infrastructure

3. List the PKI management functions and explain why key pair recovery applies to encryption keys only. Registration, initialisation, certification, key pair recovery, key pair update, revocation request and cross-certification. Recovery exists because losing an encryption key makes data permanently unreadable, so a backup is kept; a signing key is not backed up by anyone but its owner, because a signature proves something only if nobody else could have produced it.

4. Compare hierarchical, mesh and bridge trust models. A hierarchy has one root that certifies subordinate CAs in one direction, so there is a single path from any certificate to the root; browsers use a variation with a list of trusted roots. In a mesh, CAs are peers that cross-certify each other and each user trusts its own CA; there are many paths between any two points, and path building can become very expensive. A bridge CA is a hub that each PKI cross-certifies with, so k PKIs need 2k certificates and there is one route between any two, through the bridge.

5. What is RCAI, and under which provision does it operate? It is the Root Certifying Authority of India, the trust anchor of the Indian PKI for electronic signature certificates. The Controller of Certifying Authorities established it under section 18(b) of the Information Technology Act 2000, which empowers the Controller to certify the public keys of the Certifying Authorities.

6. A subscriber's token holding the private key is stolen on Monday and reported to the CA on Thursday. Who bears the risk for signatures made in between, and what must the CA do? Under section 42 the subscriber must communicate the compromise to the CA without delay, and the Explanation makes the subscriber liable until they have informed the CA, so the risk up to Thursday is theirs. On being told, the CA revokes the certificate under section 38, after giving the subscriber an opportunity to be heard, and publishes notice of the revocation in the repository named in the certificate under section 39.

7. How long can an Indian certificate be suspended without a hearing? Not beyond fifteen days. Section 37 allows suspension on the subscriber's request or in the public interest, but a suspension longer than fifteen days requires that the subscriber has first been given an opportunity of being heard.

The rest of this subject

These notes are cut from the University's printed syllabus. Open the syllabus itself for the same subject.

Syllabus for Cyber and Information Security

Issue