Summary

  • Let’s Encrypt said on 27 October that staging now uses six remote network perspectives for domain validation. Its 15 October plan makes seven validation requests in all: one primary and six remote, up from four remote perspectives.
  • The CA/Browser Forum’s current quorum table allows one remote non-corroboration when two to five distinct remotes are used and two when six or more are used. Corroborating remotes must still cover two RIR service regions. Let’s Encrypt scheduled production for 10 November, conditional on staging; its checked announcement thread has no production cutover receipt yet.

The sixth chair at the table

Certificate issuance used to have a comfortable political fiction: if the applicant answered a challenge, the name was theirs for the purpose of the certificate. A network attacker can make one validator see an answer that the rest of the Internet does not. Multi-Perspective Issuance Corroboration, or MPIC, replaces that lonely witness with several network positions. The primary view makes a determination; remote views corroborate it. The question is no longer only whether a response arrived. It is whether sufficiently independent observers saw the same authority.

The Let’s Encrypt operator notice dated 15 October says it is adding two remote views, moving from four to six. On 27 October, the operator posted the narrow but decisive update: staging is now using six. The notice anticipates seven validation requests per domain challenge, one from the primary data centre and six from remote positions. Its production date is 10 November, subject to the staging run. The announcement does not report a completed production switch. That distinction matters to anyone whose renewal depends on the new geometry.

The CA/Browser Forum Baseline Requirements set two separate tests. From 15 June 2026, a CA needs at least four remote perspectives for the specified validation work; from 15 December, it needs at least five. The remote perspectives that corroborate the primary must sit in at least two distinct RIR service regions. The latter condition is about successful witnesses, not a map decorating a deployment diagram. Put six validators on a world map and a certificate can still fail the regional test if the corroborating replies all come from one service region.

One extra view, one extra tolerated failure

The Forum’s quorum table makes the sixth remote position more than a spare server. For two to five distinct remote perspectives, the maximum allowed non-corroborations is one. For six or more, it is two. With six distinct remotes, four can corroborate and two can disagree, provided the other conditions are met. With five, four would have to corroborate. The same affirmative count can therefore survive a second bad or adverse remote result when the CA has six rather than five perspectives. The operator has bought tolerance through another independent observation, not through a lower nominal witness count.

That arithmetic is conditional. The primary must make the determination being corroborated. The remote set must be genuinely distinct: the Requirements define distinct network perspectives by at least 500 kilometres of straight-line separation, and a remote must also be distinct from the primary and others in the quorum. Where the CA uses different perspective sets for domain control and CAA checks, each set must satisfy its own quorum. A shared DNS cache cannot be passed from one perspective to another as if it were independent evidence. If a check is retried, earlier corroborations cannot be carried into the new attempt.

Each detail exists because the word “six” is cheap; six independent observations are operational work.

The older Let’s Encrypt deployment thread records four remote perspectives in production by 27 March 2024. The new thread records the next staging state, not an incident or an observed improvement rate. The operator says greater network coverage makes BGP redirection of validation requests harder. The standard gives the concrete control: an equally specific routing hijack that fools one path should not be sufficient if the other required views and the regional condition disagree with it. An attacker capable of fooling several ostensibly independent paths remains a different problem.

The issuer owns the refusal

The Baseline Requirements say the CA must not issue if the applicable quorum or two-region condition fails. That is a hard decision in an automated renewal system. A website operator may see a challenge response on its own server and still be denied a certificate because distant validators cannot corroborate it. A support desk may be tempted to call that a nuisance. The issuance system must know whether it saw a genuine validation failure, a network reachability problem, a CAA prohibition, or a regional quorum miss before anyone promises a remedy.

The Forum allows an immediate retry, including with another validation method, but the retry has to obtain fresh corroborations. The rule prevents a failed collection of observations from becoming a bag of reusable votes. It also makes diagnosis an operator responsibility: a retry can solve transient reachability without authorising the CA to average contradictory attempts into a passing story.

There is no public outcome table in the checked October thread: no staging pass rate, no latency distribution, no number of renewals blocked by remote disagreement. A dated production notice with the final perspective count and region coverage would establish the next state. Until then, the public fact is a staging cutover and a planned production date.

The sharp point is easy to miss. The sixth witness does not merely strengthen a security poster. It changes which disagreement an issuer is allowed to tolerate when it decides whether to mint a credential that browsers will trust. The CA/Browser Forum writes the counting rule; Let’s Encrypt places and runs the observers; the applicant bears the consequence of a refusal. Governance lives in that handoff.