skip to content

Why would an issuer publish a delta revocation list beside the full one, and what tells a validator the two belong together?

level: seniorimportance: nice to knowfreq 26%

answer

  1. the list only grows
  2. ship the changes, not the whole
  3. a delta names its base
  4. deltaCRLIndicator carries the base cRLNumber
  5. removeFromCRL appears only in a delta

basics

~20 s

A full list carries every unexpired withdrawal and only grows, which is expensive to re-fetch. A delta carries just the changes since a base list, and its critical deltaCRLIndicator extension names that base list's cRLNumber, so a validator can tell whether its cached base matches.

solid answer

~40 s

A revocation list enumerates every withdrawn certificate still inside its validity window, so it grows with the issuer's history and must be re-downloaded whole on every refresh - painful for gates on a thin mountain link. A delta list contains only the entries added or changed since a stated base list. Two extensions make that safe: `cRLNumber`, a monotonically increasing sequence number on every list, and `deltaCRLIndicator`, a critical extension on the delta whose value is the `cRLNumber` of the base it applies to. A validator applies the delta only if it holds that base or a later one; otherwise it must fetch a full list. `freshestCRL` points at where deltas are published, and `issuingDistributionPoint` says what scope the list covers.

code

pseudocode · 17 lines
pseudocode
function refresh_revocation_state(held_list, delta_location):
    delta = fetch(delta_location)
    if verify_issuer_signature(delta) is false:
        return held_list                 // discard, keep what we had

    base_number = delta.deltaCRLIndicator
    if base_number > held_list.cRLNumber:
        return fetch_complete_list()     // our base is too old to merge

    for each entry in delta.entries:
        if entry.reason is removeFromCRL:
            drop entry.serial from held_list
        else:
            add or update entry.serial in held_list

    held_list.cRLNumber = delta.cRLNumber
    return held_list

go deeper

for a junior

Know that a revocation list is one signed file listing withdrawn serial numbers, and that it keeps growing because entries stay until the underlying certificates expire.

for a middle

Explain the base-plus-delta split and name the sequence number that joins them, including why a delta whose base you do not hold forces a full fetch.

for a senior

Show you would check the list's scope before believing an absence, and that you know a delta is the only place a hold can be released.

for a principal

Weigh whether list distribution is worth operating at all for an intermittently connected estate, against shortening certificate lifetimes so that staleness stops mattering.

## The size problem a delta exists to solve A revocation list published under RFC 5280 is a signed enumeration: for every certificate the issuer has withdrawn and which has not yet passed its own `notAfter`, one entry with a serial number, a revocation date and optionally a reason. Entries leave only when the underlying certificate expires, so the list's size tracks the issuer's cumulative withdrawal history, not its current activity. For a validator on a fat link that is an irrelevance. For lift gates that wake up in bursts over a thin radio link, re-fetching a list of tens of thousands of entries several times a day to learn about the three certificates withdrawn overnight is the dominant cost of checking revocation at all - and the cost that gets revocation switched off. ## Base, delta, and the number that joins them Three extensions carry the mechanism: - **`cRLNumber`** - a non-critical extension on every list, a monotonically increasing sequence number for lists issued by that authority under that scope. It lets a validator order two lists and detect a replayed older one. - **`deltaCRLIndicator`** - a **critical** extension present only on a delta. Its value is the `cRLNumber` of the **base** list the delta's changes are to be applied to. Marking it critical is deliberate: a validator that does not understand deltas must reject the artefact rather than mistake a partial list for a complete one. - **`freshestCRL`** - the pointer to where delta lists are published. It can appear in a certificate or in the base list itself, and it has the same shape as `cRLDistributionPoints`. Alongside them, **`issuingDistributionPoint`** - critical, and on the list rather than the certificate - declares the list's scope: which distribution point it belongs to, whether it covers only end-entity certificates or only CA certificates, whether it is limited to certain revocation reasons, and whether it is an indirect list issued by someone other than the certificates' issuer. A validator must check the list it fetched actually covers the certificate it is asking about. ## Applying a delta correctly 1. Hold, or fetch, a complete list and note its `cRLNumber`. 2. Fetch the delta from the `freshestCRL` location and read its `deltaCRLIndicator`. 3. If the indicator's base number is greater than the `cRLNumber` of the list held, the delta is not applicable - fetch a complete list instead. 4. Otherwise merge: entries in the delta add to, or update, the held set, and a delta may also **remove** an entry. That last point is the one people miss. `removeFromCRL (8)` is the only `CRLReason` value RFC 5280 permits **exclusively in a delta list**. It exists because `certificateHold (6)` is a *suspension*: a certificate placed on hold can be released, and the way the issuer says so is a delta entry carrying `removeFromCRL`. Nothing else in the revocation model is reversible. ## The reason codes, and how strongly to state them The `CRLReason` values are `unspecified (0)`, `keyCompromise (1)`, `cACompromise (2)`, `affiliationChanged (3)`, `superseded (4)`, `cessationOfOperation (5)`, `certificateHold (6)`, `removeFromCRL (8)`, `privilegeWithdrawn (9)` and `aACompromise (10)`. Two details are worth stating precisely: - the reason code entry extension **SHOULD be absent** rather than present carrying `unspecified (0)` - a SHOULD in the specification, not a MUST; - the reason is advisory. A validator that finds the serial number listed must treat the certificate as revoked whatever the reason says, with one operational exception: some relying parties treat `keyCompromise` and `cACompromise` as the reasons that also invalidate signatures made before the revocation date, while `superseded` or `affiliationChanged` leave earlier use intact. ## What a delta does not fix A delta reduces bytes, not latency in the worst case and not staleness. The validator still needs a base list, still refreshes on the issuer's schedule, and still accepts everything issued between publications. And a delta is useless to a gate that has been offline long enough for its base to fall out of the issuer's delta window - which on an intermittently connected estate is the common case, and the reason deltas solve less in practice than their design suggests.

  • What does issuingDistributionPoint declare, and why must a validator read it?
    It is a critical extension on the list itself declaring that list's scope: which distribution point it belongs to, whether it covers only end-entity or only CA certificates, whether it is limited to particular reasons, and whether it is indirect. A validator must confirm the list it fetched actually covers the certificate in hand - a serial absent from a list scoped to other certificates is not evidence of anything.
  • Can an entry ever leave a revocation list other than by the certificate expiring?
    Yes, in exactly one case. `certificateHold (6)` is a suspension rather than a permanent withdrawal, and the issuer releases it by publishing an entry with `removeFromCRL (8)`, which RFC 5280 permits only in a delta list. Every other reason is terminal: the entry stays until the certificate passes its own notAfter and can be dropped as no longer relevant.

The base list is Monday's full inventory count; the delta is a slip of paper listing what changed since. The slip is only usable because it names the count it was taken against - applied to the wrong inventory, it silently produces a wrong total.

saying these in an interview costs you the question

  • Thinks a delta list can be applied to any base list
  • Says entries are dropped once the issuer decides they are old
  • Treats deltaCRLIndicator as non-critical, so unknown-extension handling is safe
  • Believes a delta list alone is a complete answer about a serial
  • Says every revocation reason is reversible, not just certificateHold