@blamejs/pki 0.5.9 → 0.5.10

package/CHANGELOG.md

@@ -4,7 +4,19 @@ All notable changes to `@blamejs/pki` are documented here. The format
 follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this
 project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## v0.5.9 — 2026-08-18
+## v0.5.10 — 2026-08-18
+
+The documentation and the package's own source comments settle on one spelling of the words they use in both, and a gate keeps them there.
+
+### Added
+
+- `npm run check:spelling` reports any word in the repository that has a second accepted spelling. It runs in `npm run gates`, on every pull request, and again before the published tarball is packed. The check is whole-word and case-insensitive, both to avoid a failure mode: a substring match reports `publicEncrypt` as a misspelling, and a case-sensitive one walks past the same word capitalized or upper-cased. It self-tests on planted forms before reporting, so a word list that has stopped matching cannot pass as a clean tree.
+
+### Changed
+
+- Documentation and source comments now use the US spellings behavior, recognize, unrecognized, labeled, honored, license, defense, neighbor, authorize, initialization, enrollment, signaled, modeled, favor and fulfill. 267 occurrences across 98 files no longer carry a second spelling: the README, the security policy, thirteen release notes and the changelog generated from them, the status-lifecycle record, the comments and error text in lib/, the test suite, and the release and wiki tooling. That figure counts words whose spelling changed, so a line edited for another reason that happened to contain one of these words is not counted twice. One word settles the other way: catalogue, which this repository already used by 185 uses to 32, so the checked form is that one and the US spelling is what now reports. Simple Certificate Enrolment Protocol is RFC 8894's title, quoted as published and allowed only on a line carrying that title in full, so the exception cannot spread to the word.
+
+## v0.5.9 — 2026-08-17
 
 A certificate can now carry an internationalized email address, which this toolkit could read and never write.
 
@@ -15,7 +27,7 @@ A certificate can now carry an internationalized email address, which this toolk
 
 ### Fixed
 
-- pki.smime.verify's sender binding is now exercised against certificates carrying an otherName. Two behaviours that previously had no conformance vector are pinned: a certificate whose subjectAltName carries an SmtpUTF8Mailbox does not let a legacy subject distinguished-name emailAddress speak for it, and an otherName unrelated to email, such as a Microsoft user principal name, neither erases a matching rfc822Name nor turns a definite non-match into an undecidable one.
+- pki.smime.verify's sender binding is now exercised against certificates carrying an otherName. Two behaviors that previously had no conformance vector are pinned: a certificate whose subjectAltName carries an SmtpUTF8Mailbox does not let a legacy subject distinguished-name emailAddress speak for it, and an otherName unrelated to email, such as a Microsoft user principal name, neither erases a matching rfc822Name nor turns a definite non-match into an undecidable one.
 
 ## v0.5.8 — 2026-08-17
 
@@ -24,7 +36,7 @@ Four verdicts that answered a question nobody had asked now say what they checke
 ### Added
 
 - pki.cms.decrypt reports originAuthenticated, authenticatedBy and originatorInfo. authenticated is a claim about the content and the key that opened it; it never described who sent the message. originAuthenticated is false for every recipient type the toolkit supports: a ktri or ephemeral-static kari message is minted by anyone holding the recipient's public key, and a pwri or kekri message by any co-recipient sharing the secret. authenticatedBy names what the integrity rests on. originatorInfo is now surfaced rather than decoded and discarded, and is documented as unauthenticated: it sits outside the AEAD's authenticated data, so it is a hint the sender chose, and any certificate it carries must be validated before use. To bind a sender, verify a signature over the plaintext.
-- pki.smime.verify accepts expectedSender and reports a sender block of { checked, expected, source, identities, match }. A signature proves a key signed; it does not prove the message came from the mailbox the reader sees. match is true only when the signer certificate asserts the address, compared under RFC 5280 section 7.5: the local-part exactly, the host-part case-insensitively. The address is read from the subjectAltName rfc822Name entries (RFC 8550 section 4.4.3), and where the extension carries none, from the subject distinguished name's PKCS #9 emailAddress attribute, which RFC 8550 section 3 requires a receiving agent to recognise. Where both are present the extension is authoritative, so a stale subject value cannot satisfy expectedSender while the extension names a different mailbox. It is three-valued: false when every identity was comparable and none matched, null when the question went unanswered, and null is not a pass, so a caller enforcing sender binding tests match === true. identities lists what the certificate actually asserts. With no expectedSender a single outer From is used and reported as source: "from", which is advisory, because on a message without header protection that header is attacker-controlled.
+- pki.smime.verify accepts expectedSender and reports a sender block of { checked, expected, source, identities, match }. A signature proves a key signed; it does not prove the message came from the mailbox the reader sees. match is true only when the signer certificate asserts the address, compared under RFC 5280 section 7.5: the local-part exactly, the host-part case-insensitively. The address is read from the subjectAltName rfc822Name entries (RFC 8550 section 4.4.3), and where the extension carries none, from the subject distinguished name's PKCS #9 emailAddress attribute, which RFC 8550 section 3 requires a receiving agent to recognize. Where both are present the extension is authoritative, so a stale subject value cannot satisfy expectedSender while the extension names a different mailbox. It is three-valued: false when every identity was comparable and none matched, null when the question went unanswered, and null is not a pass, so a caller enforcing sender binding tests match === true. identities lists what the certificate actually asserts. With no expectedSender a single outer From is used and reported as source: "from", which is advisory, because on a message without header protection that header is attacker-controlled.
 
 ### Changed
 
@@ -34,7 +46,7 @@ Four verdicts that answered a question nobody had asked now say what they checke
 
 - An rfc822Name identity comparison no longer folds the host-part with a Unicode-aware lowercase. U+212A KELVIN SIGN lowercases to ASCII k, so ban<U+212A>.com and bank.com are different byte strings, separately registrable, that compared equal and read as one email identity. The host-part is now folded across A-Z only, which is the case-insensitive ASCII comparison RFC 5280 section 7.5 authorizes and no more. The local-part was already compared exactly and stays that way: RFC 8398 section 5 requires that it not be transformed in any way, including by case folding.
 - pki.merkle.verifyConsistency refuses a proof whose older tree is empty and whose newer tree is not, as merkle/no-consistency-claim. RFC 6962 section 2.1.2 defines a consistency proof for 0 < oldSize < newSize. An empty tree is a prefix of every tree by definition, so there was no proof to check and nothing bound the newRoot that was passed: any value returned true, including a root from a different log. Two empty trees are unchanged and still check each root against the empty root hash.
-- pki.cmc.verify refuses a Full PKI Response that carries nothing tying it to a request, as cmc/unbound-response. Every binding the module could check was previously conditional on the caller having supplied the matching value, and nothing in the verdict reported whether any of them ran, so a response captured from an earlier successful enrollment against the same CA verified identically. Pass what the request retained (transactionId, senderNonce, whose echo is the replay defence of RFC 5272 section 6.6, or dataReturn), or allowUnbound: true to interpret a response that could be a replay of any earlier exchange.
+- pki.cmc.verify refuses a Full PKI Response that carries nothing tying it to a request, as cmc/unbound-response. Every binding the module could check was previously conditional on the caller having supplied the matching value, and nothing in the verdict reported whether any of them ran, so a response captured from an earlier successful enrollment against the same CA verified identically. Pass what the request retained (transactionId, senderNonce, whose echo is the replay defense of RFC 5272 section 6.6, or dataReturn), or allowUnbound: true to interpret a response that could be a replay of any earlier exchange.
 
 ## v0.5.7 — 2026-08-16
 
@@ -212,12 +224,12 @@ CMC (Certificate Management over CMS) ships end to end: build a Full PKI Request
 - pki.cmc.build takes transactionId, senderNonce and dataReturn as named spec fields, the same three pki.cmc.verify checks a response against. They previously had to be hand-encoded into spec.controls, and an unrecognized spec field was accepted in silence, so a request written the obvious way built, signed and sent with no exchange binding at all. Neither end could detect that, because the verifier only enforces the halves the client says it sent. An unknown spec field is now refused.
 - pki.cms.verify and pki.cmc.verify parse a private copy of a Buffer input, so the value they report and the bytes the signature was checked against are provably the same. Both decode the message synchronously and check signatures in a later turn, which left every byte range the parse surfaced, the signed content above all, a view into the caller's memory across that gap. A buffer rewritten in between could yield a result describing one message while the signature covered another, and the everyday way to hit it is a pooled read buffer recycled across concurrent verifies. A PEM string or an already-parsed object is untouched, so neither call accepts less than it did.
 - Every example in the API documentation runs against the shipped package as part of the test suite, with no fixtures supplied to it, and the ones that did not run have been corrected. An example that quietly depended on a value the surrounding text never defined would previously have failed only for the operator who pasted it.
-- pki.webauthn.verify copies opts.rootCertificates synchronously, so pinned attestation roots cannot be swapped out from under the check. The roots are not read until the attestation verifier resolves, a later promise turn, and both the array and each DER buffer stayed caller-owned across it: a caller recycling the array or overwriting a certificate's bytes in that gap had the attestation anchored against the replacement roots while the verdict still reported anchoredTo: "rootCertificates". Both are now copied at the entry point, the same defence the assertion input already had, and the documented parsed-certificate form is deep-copied and never passed by reference, since the anchor comparison reads its nested subject and subjectPublicKeyInfo buffers. opts.safetyNetRoots carried the identical window one level down, since a format verifier reads it a microtask after the call returns, and is snapshotted at the same boundary.
+- pki.webauthn.verify copies opts.rootCertificates synchronously, so pinned attestation roots cannot be swapped out from under the check. The roots are not read until the attestation verifier resolves, a later promise turn, and both the array and each DER buffer stayed caller-owned across it: a caller recycling the array or overwriting a certificate's bytes in that gap had the attestation anchored against the replacement roots while the verdict still reported anchoredTo: "rootCertificates". Both are now copied at the entry point, the same defense the assertion input already had, and the documented parsed-certificate form is deep-copied and never passed by reference, since the anchor comparison reads its nested subject and subjectPublicKeyInfo buffers. opts.safetyNetRoots carried the identical window one level down, since a format verifier reads it a microtask after the call returns, and is snapshotted at the same boundary.
 - In a compound attestation, an element the metadata catalogue does not list can no longer launder a revoked sibling. The two governance failures are not equal: metadata-not-found is the one outcome a caller may fall back to opts.rootCertificates on, and that fallback covers the whole statement. Governance stopped at the first failing element, and a compound's element order is not signed, so placing an unlisted element first raised the fallback error before a listed-but-revoked sibling was ever consulted, and the statement anchored against the pinned roots instead. Every element is now governed, and every listed element chain-validated against the roots its own entry registers, before any outcome is chosen. So a disqualifying status report outranks an unlisted sibling from either position, and a listed element whose path reaches the caller's pinned roots but not its own registered roots can no longer ride out on that sibling's fallback either. A compound in which no element is listed still falls back as documented.
 - pki.ocsp.sign copies the responder key synchronously. The key is not read until several promise turns after the call, and capturing only the reference stopped responder.key being reassigned but not the PKCS#8 bytes, or a composite key's components, being rewritten in place. Either produced a response carrying this responder's identifier and embedded certificate over a signature made by different key material, which no relying party can verify. A CryptoKey is opaque and a PEM string immutable, so both were already safe. A composite descriptor is cloned whether or not its components currently hold bytes: one carrying two PEM strings has nothing mutable inside it, but the object is still the caller's, and reassigning a component reaches the deferred sign just as rewriting a buffer would.
 - An Apple attestation certificate whose anonymous-attestation extension carries more than the nonce is refused. AppleAnonymousAttestation is a SEQUENCE of exactly one field wrapping exactly one value, but the decoder read the first child and ignored the rest, so a certificate with a trailing field beside the nonce, a second value inside the EXPLICIT [1] wrapper, or a non-SEQUENCE outer value was accepted. That extension exists to carry the value the attestation binds to, so an ambiguous encoding of it is not a shape the verifier gets to pick a reading from; arity is now enforced as part of the declared type.
 - A key identifier and a pre-encoded CertID must now be bytes, and are no longer coerced. pki.cms.sign takes a key-only signer's keyIdentifier and pki.ocsp.sign takes a response entry's certID straight into the encoding, and both previously ran the value through Buffer.from, which accepts far more than it should mean: Buffer.from(20) allocates twenty zero octets and Buffer.from("a1b2") takes the ASCII of the text where a reader means two octets. Either produced a structurally valid but wrong SignerIdentifier or CertID, inside a message that then gets signed and that no verifier can match back. A Buffer or Uint8Array is accepted as before; anything else is now cms/bad-input or ocsp/bad-input.
-- An OCSP response whose nonce does not echo the request no longer downgrades a revoked verdict to unknown. pki.ocsp.verify applies that downgrade to good only. Revocation does not go stale the way non-revocation does, so discarding a signed, current, authorized revoked response because it was replayed would hand a soft-failing caller the certificate the responder just refused: the anti-replay defence would become the thing that accepts it. The verdict was also self-contradictory, reporting status unknown while carrying revocationReason keyCompromise. nonceMatched: false still reports that the response was not bound to this request, and the field is now three-state and always present (true bound, false not bound, null when the client sent no nonce), so a caller can tell a check that ran from one that was never asked for.
+- An OCSP response whose nonce does not echo the request no longer downgrades a revoked verdict to unknown. pki.ocsp.verify applies that downgrade to good only. Revocation does not go stale the way non-revocation does, so discarding a signed, current, authorized revoked response because it was replayed would hand a soft-failing caller the certificate the responder just refused: the anti-replay defense would become the thing that accepts it. The verdict was also self-contradictory, reporting status unknown while carrying revocationReason keyCompromise. nonceMatched: false still reports that the response was not bound to this request, and the field is now three-state and always present (true bound, false not bound, null when the client sent no nonce), so a caller can tell a check that ran from one that was never asked for.
 - Corrections to the repository documentation, each of which would have misled a reader who acted on it. SUPPORT.md described additive APIs as minor releases; pre-1.0 they ship as patches, and a minor is an explicit decision recorded in the release notes. ARCHITECTURE.md, CONTRIBUTING.md and the interop test guide showed pki.x509.parse, which does not exist: parsing is pki.schema.x509.parse, and pki.<format> is the issuing half throughout. ARCHITECTURE.md listed namespaces as future that have shipped, and omitted the schema, guard and validator families entirely. THREAT-MODEL.md marked path validation, signature verification, CMS decryption and ML-KEM decapsulation as targeted when all four have shipped, and linked to a section that no longer exists. ROADMAP.md reported CRL reason-shard accumulation and delta-CRL merge as planned in one entry while describing them as shipped in another. ML-KEM encapsulation and decapsulation were described as roadmap items; both ship and are what the CMS KEMRecipientInfo arm rides on. The interoperability acceptance gate was described as running against NSS, Windows CAPI and macOS Keychain alongside OpenSSL; only the OpenSSL cross-checks are wired, and the others are roadmap. The format detectors behind pki.schema.parse were described as mutually exclusive regardless of registration order; order is load-bearing where two overlap, so a CMP PKIMessage sits ahead of the OCSP-request probe and a v1 attribute certificate ahead of X.509. The fuzzing guide listed 27 of the 55 harnesses. The README carried two separate entries for pki.tls. The published pki.transport response contract named three fields where the transport returns four: the omitted tls field is what pki.est.serverkeygen reads to assert the channel can protect a server-generated private key, and a transport that reports no cipher is trusted, so an operator injecting a substitute built to the documented contract silently skipped that check. EST channel binding was described as shipped; the challengePassword builder and the server-instruction flag ship, but nothing produces the RFC 5929 tls-unique value and the shared transport does not expose it, so the attribute cannot be driven end to end.
 
 ## v0.4.15 — 2026-08-10
@@ -251,7 +263,7 @@ Every key-establishment secret this library allocates is now wiped when it stops
 
 ### Changed
 
-- Raw secret key material is now reached through a single path that clears the copy it hands out, so a new operation cannot obtain that material without the wipe. Behaviour of the public API is unchanged.
+- Raw secret key material is now reached through a single path that clears the copy it hands out, so a new operation cannot obtain that material without the wipe. Behavior of the public API is unchanged.
 
 ### Fixed
 
@@ -289,7 +301,7 @@ A KEM shared secret and the key it derives are now wiped as soon as they stop be
 ### Changed
 
 - The ML-KEM ciphertext-length check FIPS 203 sec. 7.3 requires of a decapsulating party is now performed by the crypto engine, so a caller reaching decapsulateBits directly is covered too; before, only the CMS path that happens to call it today was. It reports webcrypto/bad-kem-ciphertext, naming the parameter set and both lengths, where the failure was previously indistinguishable from any other decapsulation fault; a ciphertext whose length is valid for some other parameter set is refused on those terms, and no longer reads as merely short. The check is on length alone: a correct-length ciphertext that has been tampered with still resolves to a pseudo-random shared secret, because turning that into an error would give an attacker a decryption oracle. No engine detail reaches a CMS caller: a structurally valid message whose decryption fails for any secret-dependent reason still reports the single uniform cms/decrypt-failed verdict. A message whose ML-KEM ciphertext length does not match the parameter set the message itself declares is a separate case and always was (including a length that would be valid for a different set), because the strict parser rejects it up front and names it: the mismatch is a structural fault, decidable from the message alone, with nothing about it depending on a key.
-- The ML-KEM parameter sizes resolve from one registry instead of three separate tables in three modules. The encapsulation-key lengths were already duplicated verbatim in two of them, and each new consumer meant another copy that could drift; a parameter set is a property of the algorithm identifier, so it now lives beside the registry that resolves one. Behaviour is unchanged.
+- The ML-KEM parameter sizes resolve from one registry instead of three separate tables in three modules. The encapsulation-key lengths were already duplicated verbatim in two of them, and each new consumer meant another copy that could drift; a parameter set is a property of the algorithm identifier, so it now lives beside the registry that resolves one. Behavior is unchanged.
 
 ### Fixed
 
@@ -312,7 +324,7 @@ A CMS message can no longer declare one content cipher and be opened with anothe
 
 ### Fixed
 
-- A CMS content cipher is now bound to the container that declares it. An EnvelopedData must name a CBC cipher and an AuthEnvelopedData an AEAD one, checked before the content-encryption key is used; a mismatch is refused as an unsupported algorithm naming both the cipher and the container. Previously only the cipher's key length was resolved, and because AES-CBC and AES-GCM share key lengths, an EnvelopedData whose algorithm identifier had been changed to the same-size AES-GCM identifier decrypted successfully as unauthenticated CBC while reporting the AEAD algorithm in its result. A caller inspecting contentEncryptionAlgorithm to establish that the content was authenticated was answered from a field the decryption had not honoured. The reverse pairing was refused only incidentally, by a later dereference of parameters the AEAD path expects, and no stated rule refused it.
+- A CMS content cipher is now bound to the container that declares it. An EnvelopedData must name a CBC cipher and an AuthEnvelopedData an AEAD one, checked before the content-encryption key is used; a mismatch is refused as an unsupported algorithm naming both the cipher and the container. Previously only the cipher's key length was resolved, and because AES-CBC and AES-GCM share key lengths, an EnvelopedData whose algorithm identifier had been changed to the same-size AES-GCM identifier decrypted successfully as unauthenticated CBC while reporting the AEAD algorithm in its result. A caller inspecting contentEncryptionAlgorithm to establish that the content was authenticated was answered from a field the decryption had not honored. The reverse pairing was refused only incidentally, by a later dereference of parameters the AEAD path expects, and no stated rule refused it.
 - The password-recipient inner cipher is resolved through the same identifier-keyed table. It previously required a CBC mode by matching the algorithm identifier's display name, which pki.oid.register can rebind, so a caller that had registered a name over a built-in one could change which ciphers that check admitted.
 
 ## v0.4.11 — 2026-08-09
@@ -323,20 +335,20 @@ A WebAuthn attestation can now be bound to the roots the authenticator's own mod
 
 - pki.webauthn.verifyMetadataBlob reads a FIDO Metadata Service (MDS v3) BLOB and returns its entries indexed by aaguid. The BLOB is a JWS: its signature is checked under the certificate in its own header, that chain is validated to one of the roots the caller pins, and only then is the payload parsed. The ordering is the point, because a reader that parses first hands an attacker every structure behind the signature.
 - The catalogue's freshness is enforced, and enforced again wherever it is used. A BLOB whose sequence number does not exceed the one the caller already holds is refused as a rollback, and requireRollbackCheck makes supplying that number mandatory so the check cannot be skipped by forgetting the option. A BLOB past its nextUpdate is refused as stale. A verified result is an ordinary object a relying party may cache, so its expiry is re-checked each time it is passed to verify, and a catalogue fetched while current cannot keep authorizing an authenticator whose status reports have since revoked it. Both checks fail closed, and the caller's own allowStale decision rides on the result, so it need not be repeated.
-- Passing the verified result to pki.webauthn.verify as opts.metadata binds the attestation to its own model: the authenticator's registered attestation roots are resolved from its identifier, and its trust path must fully validate to one of them. That means signature chaining, validity and constraints: the same path validation any certificate chain gets. An authenticator whose model the catalogue does not list, whose entry registers no attestation root, or whose status reports disqualify it, is refused. Which reports disqualify is selectable: any report ever filed, only the most recent one so that a later remediation clears an earlier revocation, or a predicate of the caller's own. An unrecognised status is ignored by default, as the specification requires, or treated as disqualifying on request.
+- Passing the verified result to pki.webauthn.verify as opts.metadata binds the attestation to its own model: the authenticator's registered attestation roots are resolved from its identifier, and its trust path must fully validate to one of them. That means signature chaining, validity and constraints: the same path validation any certificate chain gets. An authenticator whose model the catalogue does not list, whose entry registers no attestation root, or whose status reports disqualify it, is refused. Which reports disqualify is selectable: any report ever filed, only the most recent one so that a later remediation clears an earlier revocation, or a predicate of the caller's own. An unrecognized status is ignored by default, as the specification requires, or treated as disqualifying on request.
 - Authenticators that carry no aaguid are covered too. A U2F authenticator declares no model identity, and the catalogue keys it by the key identifiers of its attestation certificates instead; both key spaces are indexed and looked up, so a U2F registration binds to its registered roots and is not refused as unlisted. The identifier is read from the entry and from its metadata statement, since live entries populate both, and is computed as RFC 5280 sec. 4.2.1.2 method 1 defines it. A compound attestation is covered as well: its elements carry independent trust paths, and every one of them must reach a registered root.
 - Which identifier is allowed to select an entry depends on what the attestation signature covers. The fido-u2f signature is computed over named fields and does not include the aaguid, so for that format the certificate decides and the declared aaguid is ignored; otherwise setting it to a listed model that shares the vendor's registered root would resolve to that model's entry and skip the real one's status reports. For relying parties: res.aaguid reports what the authenticator presented and is not signature-bound for that format; res.metadata.aaguid names the entry that actually matched.
-- Only a catalogue this library verified can decide anything. A metadata result is recognised by its provenance. Shape is not enough on its own, so an object restored from a cache is refused as a catalogue. It has been through none of the signature and chain checks, and its contents are whatever an attacker able to write that cache chose. Re-verify the BLOB instead, which the freshness rule asks for anyway. The verified result is also frozen. The catalogue that decides a later verification is therefore the one the signature covered, unedited.
+- Only a catalogue this library verified can decide anything. A metadata result is recognized by its provenance. Shape is not enough on its own, so an object restored from a cache is refused as a catalogue. It has been through none of the signature and chain checks, and its contents are whatever an attacker able to write that cache chose. Re-verify the BLOB instead, which the freshness rule asks for anyway. The verified result is also frozen. The catalogue that decides a later verification is therefore the one the signature covered, unedited.
 - A stored attestation is anchored at the instant its own format judged it. An android-safetynet response carries its signing time and its service chain has usually expired since, so the metadata anchor check reuses that instant in place of the current clock; otherwise it would refuse the very registration the format verifier had just accepted. An explicit opts.time still takes precedence.
 - Status reports are read against the instant being judged: a report dated in the future has not taken effect, so it cannot displace a revocation that is in force now, and a deliberately historical verification does not see reports filed after the time it asks about.
-- A status report that names a single certificate is judged against the certificate actually presented. A whole batch of authenticators is commonly listed under one entry, so a key-compromise report naming one attestation certificate denies only that one, whatever else the entry covers; a report that names nothing, or names something that does not decode, still applies to the entry as a whole. Trust anchors are recognised by name and public key. Self-issuedness is not the test, so a chain terminating in a cross-signed form of a root you supplied still anchors to it.
+- A status report that names a single certificate is judged against the certificate actually presented. A whole batch of authenticators is commonly listed under one entry, so a key-compromise report naming one attestation certificate denies only that one, whatever else the entry covers; a report that names nothing, or names something that does not decode, still applies to the entry as a whole. Trust anchors are recognized by name and public key. Self-issuedness is not the test, so a chain terminating in a cross-signed form of a root you supplied still anchors to it.
 - The BLOB's own signing certificate must be permitted to sign. A certificate that carries a key-usage extension omitting digitalSignature is refused before its key is used to check the BLOB signature, so a certificate restricted to some other purpose cannot confer metadata-signing authority just because it chains to the root you supplied.
 - pki.webauthn.metadataFor looks an entry up against a verified result only, never raw bytes, so a lookup cannot be answered out of a catalogue nobody verified. It takes either identifier (an aaguid or an attestation-certificate key identifier), dispatching on the form, which are disjoint by shape. pki.webauthn.metadataAnchors decodes an entry's registered attestation roots one entry at a time, since a handful of certificates in the live metadata do not parse under a strict decoder and decoding everything up front would let one vendor's malformed root refuse the entire catalogue for every other authenticator in it.
 
 ### Changed
 
-- pki.webauthn.verify now rejects an unrecognised option key, where it used to ignore one, and validates opts.time at the boundary. Every option it takes either gates the verdict or supplies the trust material a gate needs, so a misspelled key was not harmless: asking for metadata enforcement and mistyping the key left the gate switched off and returned a pass the caller believed had been checked against the catalogue. An invalid time is now reported as the configuration fault it is, and no longer surfaces later as an authenticator trust failure.
-- Configuration objects across certificate, CRL, attribute-certificate, CSR, and CMP issuance now reject an unrecognised option key through one shared check, replacing a dozen separate ones. Two cases that a hand-written check gets wrong are fixed everywhere at once: a key that every JavaScript object inherits, such as constructor or toString, is no longer accepted as a recognised option name, and an option object built by parsing JSON that carries its own __proto__ key is now inspected; it used to be skipped. The wording of every rejection is unchanged. This matters because the failure is silent in the quietest possible way: a misspelled option key leaves the default in force, so a caller who asked for a stricter check gets the looser behaviour and no error anywhere.
+- pki.webauthn.verify now rejects an unrecognized option key, where it used to ignore one, and validates opts.time at the boundary. Every option it takes either gates the verdict or supplies the trust material a gate needs, so a misspelled key was not harmless: asking for metadata enforcement and mistyping the key left the gate switched off and returned a pass the caller believed had been checked against the catalogue. An invalid time is now reported as the configuration fault it is, and no longer surfaces later as an authenticator trust failure.
+- Configuration objects across certificate, CRL, attribute-certificate, CSR, and CMP issuance now reject an unrecognized option key through one shared check, replacing a dozen separate ones. Two cases that a hand-written check gets wrong are fixed everywhere at once: a key that every JavaScript object inherits, such as constructor or toString, is no longer accepted as a recognized option name, and an option object built by parsing JSON that carries its own __proto__ key is now inspected; it used to be skipped. The wording of every rejection is unchanged. This matters because the failure is silent in the quietest possible way: a misspelled option key leaves the default in force, so a caller who asked for a stricter check gets the looser behavior and no error anywhere.
 
 ### Fixed
 
@@ -351,7 +363,7 @@ A TPM attestation now reports the credential key's own object attributes and acc
 - A verified TPM attestation reports the credential key's object attributes as named flags, the raw attribute word, and the key's access-policy digest. Previously both fields were read past and discarded, so a relying party that wanted to know whether the key was bound to its TPM had to re-parse the public area itself.
 - opts.tpmPolicy requires any of those attributes by name, in either direction, since an attribute may be required set or required clear; it refuses the attestation naming which one disagreed. A single profile, hardware-bound, is the shorthand for the six attributes every genuine attestation examined agrees on: the key is bound to one TPM and one parent, the TPM generated it, it can sign, and it is neither a restricted key nor an X.509 signing key. An explicit attribute layers over the profile, so one flag can be overridden without losing the rest. Three attributes are deliberately absent from it, because they differ across genuine authenticators and requiring any of them would reject working hardware.
 - The policy also covers the key's access policy: requiring that one is present at all and is not the empty policy, and requiring it to be one of an allow-list of digests, compared in constant time. Two structural opt-ins are available for callers who want them: rejecting an attribute word that sets a bit the specification reserves, and rejecting attribute combinations the specification does not define.
-- A mistyped policy is refused when it is set: an unknown key at any level, an unknown profile, an unknown attribute name, a non-boolean value, or an allow-list entry that is not a certificate digest all fail immediately, so a typo can never silently disable the check a caller believes they enabled. Names that every JavaScript object inherits are not accepted as policy names either, since a lookup would otherwise report them as recognised and leave the policy applying nothing. Requiring that the TPM generated the key without also requiring the key be non-duplicable is refused for the same reason. On its own it establishes nothing, because the key could have been imported.
+- A mistyped policy is refused when it is set: an unknown key at any level, an unknown profile, an unknown attribute name, a non-boolean value, or an allow-list entry that is not a certificate digest all fail immediately, so a typo can never silently disable the check a caller believes they enabled. Names that every JavaScript object inherits are not accepted as policy names either, since a lookup would otherwise report them as recognized and leave the policy applying nothing. Requiring that the TPM generated the key without also requiring the key be non-duplicable is refused for the same reason. On its own it establishes nothing, because the key could have been imported.
 - Requesting a TPM policy also requires an attestation that can satisfy it. The policy is evaluated against the TPM public area, which only a TPM attestation carries, so an attestation in any other format would never reach it, and a relying party that demanded a TPM-bound key would have accepted a credential with no attestation at all. Such a request is now refused up front, naming the format, and a compound attestation qualifies only when it actually contains a TPM statement.
 
 ### Fixed
@@ -445,7 +457,7 @@ pki.tls encodes and decodes RFC 8879 compressed certificate messages (the larges
 
 ### Changed
 
-- pki.cms.sign and pki.cms.verify compute their message digests through the crypto engine; neither holds a private digest table any more. Behaviour is unchanged; the digest algorithms a signer and a verifier accept are now defined in one place.
+- pki.cms.sign and pki.cms.verify compute their message digests through the crypto engine; neither holds a private digest table any more. Behavior is unchanged; the digest algorithms a signer and a verifier accept are now defined in one place.
 
 ### Fixed
 
@@ -1400,7 +1412,7 @@ SLH-DSA signatures verify in certification-path validation, and the post-quantum
 ### Fixed
 
 - The shared AlgorithmIdentifier decoder now rejects a present parameters field on the algorithms whose parameters MUST be absent, namely ML-DSA, SLH-DSA, Ed25519, Ed448, X25519, and X448 (RFC 9909 §3, RFC 9814 §4, RFC 9881 §2, RFC 8410 §3), failing closed with a <format>/bad-algorithm-parameters code. Previously a stray explicit NULL or arbitrary bytes in that field were surfaced raw. The rule is enforced once in the shared decoder, so every format that names an algorithm inherits it; a conforming identifier, which omits the field, is unaffected.
-- Certification-path validation now enforces issuer-key / signature-algorithm consistency for the one-shot families whose public-key OID equals the signature OID (EdDSA, ML-DSA, and SLH-DSA), rejecting a mismatch with a path/algorithm-mismatch reason (RFC 9814 §4). Because the underlying WebCrypto import binds a public key of a different type to the requested algorithm name and verifies with the real key, a certificate or CRL signed by one key type but labelling its signatureAlgorithm as another one-shot type could otherwise validate; the check closes that algorithm-confusion path for both the certificate signature and the CRL revocation checker.
+- Certification-path validation now enforces issuer-key / signature-algorithm consistency for the one-shot families whose public-key OID equals the signature OID (EdDSA, ML-DSA, and SLH-DSA), rejecting a mismatch with a path/algorithm-mismatch reason (RFC 9814 §4). Because the underlying WebCrypto import binds a public key of a different type to the requested algorithm name and verifies with the real key, a certificate or CRL signed by one key type but labeling its signatureAlgorithm as another one-shot type could otherwise validate; the check closes that algorithm-confusion path for both the certificate signature and the CRL revocation checker.
 
 ## v0.1.20 — 2026-07-09
 
@@ -1580,7 +1592,7 @@ A PKCS#10 certification-request parser joins the pki.schema family.
 
 ### Changed
 
-- C.TIME.ms is renamed to C.TIME.milliseconds, so every C.TIME duration helper now reads as a full word (milliseconds, seconds, minutes, hours, days, weeks). The behaviour is unchanged: it still returns an integer millisecond count.
+- C.TIME.ms is renamed to C.TIME.milliseconds, so every C.TIME duration helper now reads as a full word (milliseconds, seconds, minutes, hours, days, weeks). The behavior is unchanged: it still returns an integer millisecond count.
 
 ### Security
 
@@ -1650,7 +1662,7 @@ WebCrypto EC key import validates the curve against the key material.
 
 ### Security
 
-- pki.webcrypto.subtle.importKey now derives an imported EC key's named curve from the key material and enforces it across the spki, pkcs8 and jwk formats. Previously it trusted the caller-supplied namedCurve without checking it against the key, so a key on an unsupported curve (for example secp256k1) imported as an approved curve, and a key on one curve could be labelled as another, an algorithm-confusion vector in which the CryptoKey's algorithm disagreed with its key material. A curve the framework does not support is now rejected (NotSupportedError) and a namedCurve that does not match the key is rejected (DataError); generateKey already enforced this, and import now matches it. The raw-key format was already validated against its declared curve and is unchanged.
+- pki.webcrypto.subtle.importKey now derives an imported EC key's named curve from the key material and enforces it across the spki, pkcs8 and jwk formats. Previously it trusted the caller-supplied namedCurve without checking it against the key, so a key on an unsupported curve (for example secp256k1) imported as an approved curve, and a key on one curve could be labeled as another, an algorithm-confusion vector in which the CryptoKey's algorithm disagreed with its key material. A curve the framework does not support is now rejected (NotSupportedError) and a namedCurve that does not match the key is rejected (DataError); generateKey already enforced this, and import now matches it. The raw-key format was already validated against its declared curve and is unchanged.
 
 ## v0.1.2 — 2026-07-04
 

package/README.md

@@ -225,7 +225,7 @@ comment blocks, is at [pkijs.com](https://pkijs.com).
 | `pki.jose` | Flattened JWS (RFC 7515) and JWK thumbprints (RFC 7638). `sign` and `verify` run a Flattened JWS against declarative profiles (ACME outer, EAB inner, keyChange inner) that carry the required and forbidden header rules as data. `base64url` is the strict RFC 4648 §5 codec, rejecting padding, non-alphabet characters, and non-canonical trailing bits. `parseJson` is a bounded reader that refuses duplicate members at any depth. `thumbprint` is the RFC 7638 / 8037 / 9964 canonical digest. The algorithm registry binds each `alg` to its key type (ES/RS/PS/EdDSA/ML-DSA), leaving no code path for `alg:none`, an RS256→HS256 key confusion, or an all-zero ECDSA signature; `assertPublicJwk` refuses a JWK carrying private material, so an exported private key is never published. `opts.key` names the key a message must be signed under and governs: where the profile also permits an embedded header `jwk`, the two must be the same key — compared as RFC 7638 thumbprints, so member order cannot make equal keys differ — and a disagreement is refused rather than resolved in the message's favor. `keySource` reports which key answered, since a signature checked against a key you named is a different claim from one checked against the key the message carried — `sign`, `verify`, `base64url`, `parseJson`, `thumbprint`, `assertPublicJwk` |
 | `pki.acme` | ACME (RFC 8555 / 8737 / 8738 / 9773). `client(directoryUrl, opts)` is a stateful client driving a live CA directory over `pki.transport`: `newAccount`, `newOrder`, `newAuthz`, `getOrder`, `getAuthorization`, `getChallenge`, `respondToChallenge`, `finalize`, `pollOrder`, `pollAuthorization`, and `downloadCertificate` walk the issuance flow, with `newAuthz` pre-authorizing a single identifier (§7.4.1) and `downloadCertificate` choosing among alternate chains (`Link rel="alternate"`, §7.4.2, via a `selectChain` predicate bounded by `maxAlternates`). `revokeCert` (account-key or certificate-key signed), `keyChange`, `deactivateAccount`, `deactivateAuthorization`, `renewalInfo` (ARI), and `renewalWindow` (the RFC 9773 §4.2/4.3 renewal decision) complete the lifecycle. Every URL is HTTPS only, an explicit trust anchor is required, each request carries a fresh single-use nonce with a bounded badNonce retry, reads are POST-as-GET, polling is bounded and sleeps on a Retry-After via an injectable sleeper capped by a poll count and a total-wait budget, and every response body is size-capped. The transport is injectable via `opts.transport`. Over the message layer it composes resource-object validators (closed status enums, conditional-required fields, unknown fields ignored), the three §7.1.6 state machines, the request builders (newAccount with External Account Binding, newOrder with `replaces`, finalize with a CSR identifier-set match and account-key-reuse rejection, challenge responses, deactivation, revokeCert in both key modes, the keyChange nested JWS, POST-as-GET), the http-01 / dns-01 / tls-alpn-01 challenge computations, the dns and ip identifier validators, and the ARI certID with serial sign-padding preserved — `client`, `validate`, `identify`, `assertTransition`, the builders, `keyAuthorization`, `http01`, `dns01`, `tlsAlpn01Extension`, `verifyTlsAlpn01`, `ariCertId` |
 | `pki.schema.smime` | S/MIME ESS signed-attribute values (RFC 5035 / RFC 8551). `parseSigningCertificate` and `parseSigningCertificateV2` bind a signature to its signing certificate (cert hash, hash algorithm, issuer `GeneralNames` and serial); `parseSmimeCapabilities` decodes the ordered capability list; `decodeAttribute` dispatches a CMS attribute by OID, enforcing the single-value rule and deferring on unknown types. A companion decoder for CMS signed attributes rather than an auto-routed format — `parseSigningCertificate`, `parseSigningCertificateV2`, `parseSmimeCapabilities`, `decodeAttribute` |
-| `pki.cmc` | Build and interpret CMC messages (RFC 5272). `build(spec, signer)` assembles a Full PKI Request across all three request arms (PKCS#10, CRMF, other) and signs it through `pki.cms.sign` under `id-cct-PKIData`. Body-part identifiers are unique across the whole message and never the reserved 0; a caller's clash is refused rather than renumbered, since a control may already reference it. An Identity Proof V2 witness is computed over the `reqSequence` bytes exactly as emitted (§6.2.1 step 1) rather than a re-serialization, a POP Link Witness is emitted only alongside the POP Link Random control §6.3.1.1 requires beside it, and a renewal carries neither Identification nor Identity Proof in either version. `verify(response, sent)` takes what the CA returned plus the state the client retained and reduces it to one terminal outcome: `issued`, `pending`, `confirm-required`, `pop-required`, or `rejected`. It binds the exchange first — Transaction Identifier, the Sender and Recipient Nonce echo compared in constant time and by full value so a truncation cannot match, and the Data Return echo — with each check applying only if the client sent that half, and, once sent, an absent or differing echo being a refusal, which is the replay defence. `bodyPartIDs` extends the same rule to what the response is about: a status reporting on a body part the request never sent is refused, which the transaction and nonce cannot catch, because a server can echo both correctly while answering about a different message. Several status controls are permitted and the worst governs, so a failure cannot hide behind an earlier success; the absence of any status control is success, per §6.1.2. The carrier's signature must verify (§3.2.1.3.4): a conforming SignedData carries its own signer certificate, so the ordinary build-then-verify flow needs nothing extra and the verdict reports `signatureVerified: true`. Where the signer is found nowhere the posture is fail-closed with a named opt-out — supply `certs` with the responder's certificate, or `allowUnverified: true`, in which case the verdict reports `signatureVerified: false`. Doing neither is refused, the opt-out never excuses a signature that is present and wrong, and a carrier with no signer at all is refused outright. The response's own `cmsSequence` and `otherMsgs` come back raw, since a request whose only arm was the other-message form has no certificate to return and §4.1 puts its answer there. Nothing is trusted: issued certificates are read from the CMS certificate bag (§4.2) and surfaced raw for `pki.path.validate`, and a Publish Trust Anchors control is surfaced with `trusted: false` rather than added to a store — `build`, `verify` |
+| `pki.cmc` | Build and interpret CMC messages (RFC 5272). `build(spec, signer)` assembles a Full PKI Request across all three request arms (PKCS#10, CRMF, other) and signs it through `pki.cms.sign` under `id-cct-PKIData`. Body-part identifiers are unique across the whole message and never the reserved 0; a caller's clash is refused rather than renumbered, since a control may already reference it. An Identity Proof V2 witness is computed over the `reqSequence` bytes exactly as emitted (§6.2.1 step 1) rather than a re-serialization, a POP Link Witness is emitted only alongside the POP Link Random control §6.3.1.1 requires beside it, and a renewal carries neither Identification nor Identity Proof in either version. `verify(response, sent)` takes what the CA returned plus the state the client retained and reduces it to one terminal outcome: `issued`, `pending`, `confirm-required`, `pop-required`, or `rejected`. It binds the exchange first — Transaction Identifier, the Sender and Recipient Nonce echo compared in constant time and by full value so a truncation cannot match, and the Data Return echo — with each check applying only if the client sent that half, and, once sent, an absent or differing echo being a refusal, which is the replay defense. `bodyPartIDs` extends the same rule to what the response is about: a status reporting on a body part the request never sent is refused, which the transaction and nonce cannot catch, because a server can echo both correctly while answering about a different message. Several status controls are permitted and the worst governs, so a failure cannot hide behind an earlier success; the absence of any status control is success, per §6.1.2. The carrier's signature must verify (§3.2.1.3.4): a conforming SignedData carries its own signer certificate, so the ordinary build-then-verify flow needs nothing extra and the verdict reports `signatureVerified: true`. Where the signer is found nowhere the posture is fail-closed with a named opt-out — supply `certs` with the responder's certificate, or `allowUnverified: true`, in which case the verdict reports `signatureVerified: false`. Doing neither is refused, the opt-out never excuses a signature that is present and wrong, and a carrier with no signer at all is refused outright. The response's own `cmsSequence` and `otherMsgs` come back raw, since a request whose only arm was the other-message form has no certificate to return and §4.1 puts its answer there. Nothing is trusted: issued certificates are read from the CMS certificate bag (§4.2) and surfaced raw for `pki.path.validate`, and a Publish Trust Anchors control is surfaced with `trusted: false` rather than added to a store — `build`, `verify` |
 | `pki.schema.cmc` | Decode CMC messages (RFC 5272 as updated by RFC 6402): a Full PKI Request (`PKIData`) or Full PKI Response (`PKIResponse`) riding inside a CMS SignedData, reached by the encapsulated content type (`id-cct-PKIData` / `id-cct-PKIResponse`). Controls are surfaced in wire order with their values raw, so an unrecognized one is data rather than a fault. Tagged requests decode across all three arms. The status verdicts (`CMCStatusInfo` v1 and `CMCStatusInfoV2`) are collected as an ordered list, and the RFC 6402 two-module `OtherStatusInfo` ambiguity — `pendInfo` and `extendedFailInfo` are both untagged SEQUENCEs in the 1988 module, told apart only by their first element — is resolved by inspection and refused when it cannot be told apart. Body-part identity is unique across the whole message rather than per sequence, 0 is reserved as the reference to the enclosing PKIData, and the `reqSequence` bytes are surfaced exactly as they appeared so an Identity Proof witness is computed over the wire bytes. A companion decoder for CMS content rather than an auto-routed format — `parse`, `parsePkiData`, `parsePkiResponse` |
 | `pki.schema.engine` | The declarative ASN.1 structure-schema engine every format parser composes — `walk`, `encode`, `embeddedDer`, and the schema combinators |
 | `pki.path` | Certification-path validation (RFC 5280 §6). `validate` runs the §6.1 state machine over an ordered path and a trust anchor: signature chaining across RSA, ECDSA, EdDSA, ML-DSA, SLH-DSA and hybrid composite ML-DSA (a composite is accepted only when both its post-quantum and traditional components verify), validity windows, name chaining, basic constraints and path length, key usage, name constraints, and the certificate-policy tree. It returns a structured verdict with per-check reason codes and enforces a `pki.trust` anchor's per-purpose distrust-after dates and delegator purposes through `checkPurpose` — an anchor that carries either one with no purpose named to select by is refused as a configuration fault rather than validated as though it carried none. The verdict says what was established. `revocationChecked` takes the weakest outcome on the path: `false` with no checker supplied, `"determined"` when every certificate got an explicit good or revoked answer, `"waived"` when `softFail` turned an undetermined one into a pass, and `"undetermined"` when one could not be answered at all — which includes a checker that throws, a fault `softFail` does not waive because `softFail` opts into an undetermined answer, not into a broken checker. `anchorConstraints` names the purpose the anchor was judged under and whether each of its two constraints applied. `crlChecker` supplies CRL-based revocation, covering partitioned and sharded CRLs, whose §6.3.3 Distribution Point ↔ IDP correspondence lets corresponding shards accumulate reason coverage until all eight revocation reasons are covered, and delta CRLs, merged onto the complete CRL they may be combined with (§5.2.4) so a held certificate its delta releases reads good, while a delta that merges with nothing still reports what it lists and still withholds good. `ocspChecker` supplies OCSP-based revocation (RFC 6960: CertID binding, responder authorization, signature, currency) over the same pluggable hook. `build(leaf, opts)` is the discovering complement (RFC 4158): from a leaf, an untrusted pool of candidate CA certificates, and a trust store, it finds the ordered leaf-to-anchor path `validate` accepts, using name chaining plus the RFC 4158 §3.5 sort hints (an AKI/SKI match, an anchor-adjacent issuer, CA plus keyCertSign, validity at the check time — ordering hints, never filters), a depth-first search with backtracking so the first accepted path wins, and a bounded search (chain-length cap, candidate-expansion cap, identity-tuple visited set) so a cross-certificate cycle or Bridge-CA fan-out terminates deterministically. Every accept flows through `validate`, and its verdict is cross-checked against `openssl verify`. Opt-in AIA `caIssuers` fetching (`opts.fetchAia: true`) discovers a missing intermediate from a certificate's Authority Information Access URL (§4.2.2.1) over `pki.transport`, triggered only on a pool miss and bounded against SSRF and amplification: HTTPS only, a total fetch budget that caps fetching silently rather than throwing, a per-cert URL cap, a build-wide URL dedupe, a response-size and certificate-count cap, no redirect following, and every fault a silent skip. The TLS trust (`opts.tls`) stays distinct from the PKI `trustAnchors`, and every fetched certificate remains untrusted pool material that still flows through `validate` (never a trust anchor). It is off by default, so the default build is byte-identical offline. Pure and re-entrant — `validate`, `build`, `crlChecker`, `ocspChecker` |

package/lib/acme.js

@@ -2024,7 +2024,7 @@ function client(directoryUrl, opts) {
         if (!authz.identifier || authz.identifier.type !== canon.type || authz.identifier.value !== canon.value || authz.wildcard === true) throw E("acme/identifier-mismatch", "the returned authorization does not match the requested identifier (RFC 8555 sec. 7.4.1)");
         // A pre-authorization's status "MUST be 'pending' unless the server has out-of-band information about the
         // client's authorization status" (sec. 7.4.1): the normal case is a fresh "pending" authz the caller then
-        // fulfils, but the CA MAY instead return an already-"valid" authz (the identifier is already authorized for
+        // fulfills, but the CA MAY instead return an already-"valid" authz (the identifier is already authorized for
         // this account -- no challenge to answer). Both are usable; only a terminal failed state ("invalid"/
         // "deactivated"/"expired"/"revoked") is not the authorization the pre-auth flow can proceed with.
         if (authz.status !== "pending" && authz.status !== "valid") throw E("acme/unexpected-authorization-status", "newAuthz returned an authorization that is neither pending nor already valid (status " + JSON.stringify(authz.status) + "); RFC 8555 sec. 7.4.1");

package/lib/cmc-build.js

@@ -83,7 +83,7 @@ var KNOWN_SPEC_KEYS = {
   // The exchange binding (RFC 5272 sec. 6.6 / 6.4). First-class here because
   // pki.cmc.verify names these same three when checking the response: a builder
   // that made the caller hand-encode them while the verifier took them by name is
-  // the asymmetry that lets a request ship with no replay defence.
+  // the asymmetry that lets a request ship with no replay defense.
   transactionId: 1, senderNonce: 1, dataReturn: 1,
 };
 
@@ -208,7 +208,7 @@ function encodeRequest(req, ids, index) {
     // A tcr arm is a PKCS#10 CertificationRequest, so it is parsed and never
     // taken on the tag: the readback of the assembled message checks the CMC
     // structure around it, and would pass an empty SEQUENCE here as happily as a
-    // real request. Signing a request body that is not one produces an enrolment
+    // real request. Signing a request body that is not one produces an enrollment
     // no CA can act on, and the producer is where that is cheap to catch.
     try { csr.parse(_der(req.tcr, "a tcr certificationRequest")); }
     catch (e) {
@@ -503,7 +503,7 @@ function _build(spec, signer, opts) {
   // A misspelled or unsupported spec field fails open in the quietest way there is:
   // the message builds, is signed, and simply does not carry what was asked for.
   // That is worst for the exchange-binding fields below: a request built without
-  // them has no replay defence, and pki.cmc.verify cannot enforce a binding the
+  // them has no replay defense, and pki.cmc.verify cannot enforce a binding the
   // client never sent, so the omission is invisible from both ends.
   guard.identifier.assertKnownKeys(spec, KNOWN_SPEC_KEYS, E, "cmc/bad-input", "unknown spec field ");
   var requests = spec.requests || [];
@@ -588,7 +588,7 @@ function _build(spec, signer, opts) {
 
   // The exchange binding (RFC 5272 sec. 6.6 Transaction Identifier / Sender Nonce,
   // sec. 6.4 Data Return). These are what pki.cmc.verify checks the response
-  // against, and a request that omits them has no replay defence, so they are
+  // against, and a request that omits them has no replay defense, so they are
   // named fields here and not something the caller hand-encodes into
   // spec.controls and can silently get wrong.
   // A named field and a hand-encoded control of the same type would emit the
@@ -797,7 +797,7 @@ function _assertKeyOnlySignerBinding(so, requests) {
     var req = requests[i];
     // Both key-bearing arms: sec. 3.2 says the signing key may belong to a request
     // "included in the TaggedRequest tcr or crm fields", so reading only PKCS#10
-    // would reject every conforming CRMF enrolment of a brand-new key.
+    // would reject every conforming CRMF enrollment of a brand-new key.
     var declaredBy;
     try {
       declaredBy = req && req.tcr != null ? _csrKeyIdentity(req.tcr)

package/lib/cmc-verify.js

@@ -139,7 +139,7 @@ function _assertBound(body, sent) {
     var got = asn1.read.integer(asn1.decode(_singleValue(txControl, "Transaction Identifier")));
     // Compared against the value the authoring guard validated, never a fresh
     // conversion of the caller's input -- a number too large to hold an integer
-    // exactly has already lost the digits that distinguish it from its neighbour.
+    // exactly has already lost the digits that distinguish it from its neighbor.
     if (got !== sent.transactionIdValue) {
       throw E("cmc/transaction-mismatch",
         "the response Transaction Identifier " + got + " does not match the request's " + sent.transactionId);
@@ -226,7 +226,7 @@ function _assertBound(body, sent) {
   // caller who retained nothing runs none of them and still gets a full verdict
   // (`issued`, signature verified, certificates surfaced) off a Full PKI Response
   // captured from any earlier exchange with the same CA. That is the CWE-294 this
-  // module names as its defence, and leaving it opt-in leaves the defence off for
+  // module names as its defense, and leaving it opt-in leaves the defense off for
   // whoever did not know to ask.
   //
   // The posture here is the one _assertAuthentic already takes for the carrier
@@ -244,7 +244,7 @@ function _assertBound(body, sent) {
   if (!bound.boundToRequest && sent.allowUnbound !== true) {
     throw E("cmc/unbound-response",
       "nothing ties this response to a request. Pass what the request retained (`transactionId`, " +
-      "`senderNonce`, whose echo is the replay defence of RFC 5272 sec. 6.6, or `dataReturn`) so the " +
+      "`senderNonce`, whose echo is the replay defense of RFC 5272 sec. 6.6, or `dataReturn`) so the " +
       "echo can be checked, or `allowUnbound: true` to interpret a response that could be a replay of " +
       "any earlier exchange with this CA");
   }
@@ -288,7 +288,7 @@ function _governingStatus(statuses, outcome) {
  * none. `sent` is what the client retained from its request --
  * `transactionId`, `senderNonce`, `dataReturn`, and `bodyPartIDs` (every identifier the request
  * carried). Each of those is checked only if it was sent, and once sent an absent or differing
- * echo is a refusal: that asymmetry is the replay defence. `bodyPartIDs` is the same rule applied
+ * echo is a refusal: that asymmetry is the replay defense. `bodyPartIDs` is the same rule applied
  * to what the response is ABOUT -- a status naming a body part the request never sent is refused
  * with `cmc/body-part-unknown`, which the transaction and nonce cannot catch, since a server can
  * echo both correctly while reporting on something else.
@@ -429,7 +429,7 @@ function _snapshotSent(sent) {
   // integer through. A Transaction Identifier is an unbounded INTEGER on the wire,
   // so one above Number.MAX_SAFE_INTEGER has already been rounded by the time it
   // arrives as a `number` -- 9007199254740993 is 9007199254740992 before this code
-  // sees it, and a response echoing that NEIGHBOURING identifier would compare
+  // sees it, and a response echoing that NEIGHBORING identifier would compare
   // equal. Held here rather than converted, so a value too large to be a number is
   // refused with the shape to use instead (a bigint) rather than silently bound to
   // something adjacent.
@@ -599,7 +599,7 @@ function _assertAuthentic(body, sent, responseBytes) {
       .then(function (res) {
         if (res.valid) return true;
         // EVERY failing signer, not just the first. A response may carry several,
-        // and the opt-out may only be honoured when none of them was actually
+        // and the opt-out may only be honored when none of them was actually
         // checked and rejected: one signer whose certificate is missing must not
         // let a DIFFERENT signer's failed signature through beside it.
         var failed = (res.signers || []).filter(function (s) { return !s.ok; });
@@ -710,7 +710,7 @@ function _shape(body, sent, signatureVerified, bound) {
  * `spec.transactionId` (number|bigint), `spec.senderNonce` and `spec.dataReturn` (bytes) attach the
  * exchange-binding controls (RFC 5272 sec. 6.6 / 6.4), the same three `pki.cmc.verify` checks the
  * response against. They are named fields, not something to hand-encode into
- * `spec.controls`, because a request that quietly omits them has no replay defence and neither end
+ * `spec.controls`, because a request that quietly omits them has no replay defense and neither end
  * can tell: the verifier only enforces the halves the client says it sent. An unrecognized spec
  * field is refused for the same reason: a misspelling would otherwise build and sign a message
  * that simply does not carry what was asked for.

package/lib/cms-decrypt.js

@@ -131,7 +131,7 @@ function _toDer(input) {
 
 // ---- stage 1: recipient selection (not secret-dependent) -------------------
 // Returns every recipient the key material may target. An explicit recipientIndex or an rid match
-// yields exactly one; unlabelled pwri / kekri recipients yield all matches for the caller to try.
+// yields exactly one; unlabeled pwri / kekri recipients yield all matches for the caller to try.
 function _selectCandidates(recips, km, opts) {
   if (!recips.length) throw _err("cms/no-matching-recipient", "the message carries no RecipientInfos");
   if (opts.recipientIndex != null) {
@@ -741,7 +741,7 @@ async function _verifyAuthenticatedData(parsed, km, opts) {
 //     || macAlg.oid` and `digestAlgorithm.name || .oid` never reach the `.oid` fallback because the
 //     algorithm name was already validated against MAC_HASH / DIGEST_WC above.
 //   * the `macKey == null` half of the random-key substitution fires only for a hand-crafted RSA v1.5
-//     ktri (this producer emits OAEP); its behaviour is identical to the tested below-floor path (a
+//     ktri (this producer emits OAEP); its behavior is identical to the tested below-floor path (a
 //     random key -> the MAC verify fails uniformly), so the < 16 vector covers the substitution.
 // _normKeyDer(key) -> { der, owned }: the recipient private key as PKCS#8 DER, and whether the
 // buffer is one this module made.

package/lib/cms-verify.js

@@ -579,7 +579,7 @@ function _verifyOneCountersig(vDer, targetSig, parsedCerts) {
   // Coverage residual, and deliberately kept. Every value reaching here was already walked by the
   // decoder, which validates an id-countersignature by content and not by the attribute type. A
   // malformed one therefore refused the whole message before verify was entered, so this catch
-  // cannot be reached through the public path. That is settled behaviour: a message the decoder
+  // cannot be reached through the public path. That is settled behavior: a message the decoder
   // has found to be malformed has no sound remainder to report a verdict over, so it is refused
   // whole instead of surfaced as one failed countersignature.
   // cms-verify.test.js pins that through the shipped verbs; this stays because the walk is also
@@ -744,7 +744,7 @@ function _verify(input, opts) {
   // read a promise turn later, and everything in it stays caller-owned across that gap: the array
   // can be re-pointed, an anchor's DER rewritten, the validation instant moved. Any of those would
   // have the chain judged against a configuration the caller never asked for while the verdict
-  // reports the one they did. The same defence the input and the certificates already have.
+  // reports the one they did. The same defense the input and the certificates already have.
   var trustCfg = _snapshotTrust(opts);
   return Promise.all(parsed.signerInfos.map(function (si) {
     // res.valid reflects only the PRIMARY signerInfos; a countersignature / unsigned attribute is

package/lib/constants.js

@@ -165,7 +165,7 @@ var LIMITS = {
   // is copied/tokenized so a hostile server cannot drive unbounded work parsing it
   // (CWE-770). 8 KiB clears any realistic multi-scheme Digest challenge.
   HTTP_AUTH_HEADER_MAX_BYTES: BYTES.kib(8),
-  // Deterministic-CBOR codec ceilings (RFC 8949), the DER neighbours' siblings:
+  // Deterministic-CBOR codec ceilings (RFC 8949), the DER neighbors' siblings:
   // a whole-document cap refused before the walk, a nesting cap, and a per-value
   // bignum ceiling the document cap can't provide. Unlike DER_MAX_INTEGER_BYTES,
   // the bignum cap carries NO +1 sign octet -- a CBOR tag-2/3 bignum body is pure

package/lib/est.js

@@ -1231,7 +1231,7 @@ function fullcmc(baseUrl, request, opts) {
     _knownOpts(opts, FULLCMC_OPTS, "fullcmc");
     der = _cmcRequestDer(request);
     // Confirm this IS a Full PKI Request before any of it goes over the wire. The
-    // bytes are about to be labelled `smime-type=CMC-request`, so a PKIResponse or
+    // bytes are about to be labeled `smime-type=CMC-request`, so a PKIResponse or
     // an unparseable blob handed in by mistake would be POSTed to a CA under a
     // label that does not describe it -- and, since only an `issued` outcome is
     // correlated, could still come back as a pending or rejected verdict, making
@@ -1567,7 +1567,7 @@ function _assertAgrees(name, supplied, carried) {
   } else {
     // Through the shared authoring guard, not a bare BigInt(): a `number` above
     // Number.MAX_SAFE_INTEGER has already lost the digits that distinguish it from
-    // its neighbour, so converting it here would compare a value the caller never
+    // its neighbor, so converting it here would compare a value the caller never
     // wrote. A transaction identifier is an unbounded INTEGER on the wire; large
     // ones are passed as a bigint, and this says so rather than rounding.
     same = carried != null &&
@@ -1671,7 +1671,7 @@ function _fullcmcResult(res, opts, wanted, sent) {
 
   // FC5 admits two smime-types, and the LABEL must agree with the BYTES: a
   // certs-only label over a Full PKI Response (or the reverse) is a server
-  // mislabelling its own body, and accepting either shape under either label
+  // mislabeling its own body, and accepting either shape under either label
   // would make the content-type check decorative.
   // Through the shared case-insensitive accessor: HTTP header names are
   // case-insensitive (RFC 9110 sec. 5.1), the classifier already reads them that

package/lib/guard-all.js

@@ -11,35 +11,35 @@
 // itself, with no guard re-implemented inline:
 //
 //   guard.bytes.view / .source        -- untrusted byte-source -> Buffer re-view
-//                                         (detached-buffer fail-open defence)
+//                                         (detached-buffer fail-open defense)
 //   guard.text.decode                 -- byte-source -> string, cap before copy
-//                                         (parser-DoS string-allocation defence)
+//                                         (parser-DoS string-allocation defense)
 //   guard.limits.cap / .depthCap      -- config-time resource-cap validation
-//                                         (recursion / allocation DoS defence)
+//                                         (recursion / allocation DoS defense)
 //   guard.crypto.constantTimeEqual    -- length-checked constant-time compare
-//                                         (timing side-channel defence)
+//                                         (timing side-channel defense)
 //   guard.range.int / .uint31 / .positiveInt31
 //                                     -- bound a decoded integer before narrowing
-//                                        to Number (silent-narrowing defence)
+//                                        to Number (silent-narrowing defense)
 //   guard.time.assertValid / .within  -- validate a Date-instant before a temporal
-//                                        comparison (NaN-Date fail-open defence)
+//                                        comparison (NaN-Date fail-open defense)
 //   guard.name.dnEqual / .rdnEqual / .assertNoControlBytes / .assertPrintableIa5
 //                                     -- canonical DN identity + name-string integrity
 //   guard.name.escapeControlBytes / .escapeDnValue
 //                                     -- render-side name safety: control-byte + RFC 4514 escaping
-//                                        (CVE-2009-2408 truncation / identity defence)
+//                                        (CVE-2009-2408 truncation / identity defense)
 //   guard.encoding.base64url / .base64 / .hex
 //                                     -- strict textual-encoding decode, canonical
-//                                        + capped (encoding-malleability defence)
+//                                        + capped (encoding-malleability defense)
 //   guard.identifier.assertCanonicalOid
 //                                     -- canonical dotted-decimal OID string form
-//                                        (canonicalization-divergence defence)
+//                                        (canonicalization-divergence defense)
 //   guard.compress.bounded            -- decompress an untrusted stream under a hard
 //                                        output cap, whole-input (decompression-bomb +
-//                                        trailing-frame malleability defence)
+//                                        trailing-frame malleability defense)
 //   guard.header.assertField          -- emitted MIME/RFC 5322 header field name +
 //                                        value integrity (CR/LF/NUL header-injection
-//                                        defence, CWE-93)
+//                                        defense, CWE-93)
 //   guard.parsed.accept               -- a CLAIMED-parsed structure carries every
 //                                        field the consuming code dereferences
 //                                        (type confusion / unverified provenance,
@@ -49,7 +49,7 @@
 // token of a guard (the Buffer.from(x.buffer, byteOffset) re-view, the
 // timingSafeEqual call, the MAX_DECODE_DEPTH_CEILING check) must appear only in
 // its guard module, so a new boundary cannot re-inline the shape and forget the
-// defence.
+// defense.
 
 var bytes  = require("./guard-bytes");
 var text   = require("./guard-text");

package/lib/guard-bytes.js

@@ -11,7 +11,7 @@ var async = require("./guard-async");
 // guard-bytes -- fail-closed coercion of an untrusted byte-source input to a
 // Buffer view. One of the enforced choke points of the guard family: a
 // codebase-patterns detector requires every byte-input boundary to route
-// through here, so the defence below cannot be forgotten at a new boundary.
+// through here, so the defense below cannot be forgotten at a new boundary.
 //
 // Defends the detached-buffer fail-OPEN: a transferred / structuredClone'd
 // Buffer or view has a detached backing ArrayBuffer and reads as ZERO-LENGTH.
@@ -85,7 +85,7 @@ function source(input, ErrorClass, code, label) {
 
 // snapshot(input, ErrorClass, code, label) -> private Buffer copy | throws ErrorClass
 //
-// The parse-then-verify time-of-check/time-of-use defence. A verification entry
+// The parse-then-verify time-of-check/time-of-use defense. A verification entry
 // point that PARSES its input synchronously and then VERIFIES a signature over
 // the same bytes in a later promise turn is reading the caller's memory twice
 // with an await in between. Every byte range the parse surfaced (the signed
@@ -108,7 +108,7 @@ function snapshot(input, ErrorClass, code, label) {
 }
 
 // snapshotSource(input, ErrorClass, code, label) -> private Buffer copy | throws
-// The same parse-then-verify defence as `snapshot`, over the whole W3C BufferSource
+// The same parse-then-verify defense as `snapshot`, over the whole W3C BufferSource
 // (raw ArrayBuffer / DataView / any typed-array view) and not only the
 // Buffer / Uint8Array contract. A parser that accepts a BufferSource must snapshot
 // the same set: leaving an ArrayBuffer or a DataView aliased reopens the window for
@@ -360,7 +360,7 @@ function _copyEntries(src, dst, ErrorClass, code, label, cap, depth, collect) {
 // caller passed disappears from Object.keys and an unknown-option check walks a different object
 // than the verb goes on to read. Shadowing matters for the same reason it is done at all: an own
 // copy is what makes an inherited value stop tracking the caller's prototype. A method is left
-// where it is, since copying a function would only move it, and it is the prototype's behaviour,
+// where it is, since copying a function would only move it, and it is the prototype's behavior,
 // not the caller's data.
 function _copyNamed(src, dst, ErrorClass, code, label, cap, depth, collect) {
   var keys = _namesToCopy(src, dst);

package/lib/guard-compress.js

@@ -22,7 +22,7 @@
 //     unboundedly many encodings, and a digest over the compressed object would
 //     stop identifying what it decompresses to.
 //
-// Both defences are applied here, once, for every algorithm, so a new consumer
+// Both defenses are applied here, once, for every algorithm, so a new consumer
 // cannot pick up one and miss the other. Verified uniform across zlib, brotli
 // and zstd: each reports consumed input as `engine.bytesWritten` under
 // `info: true`, each raises ERR_BUFFER_TOO_LARGE on a cap breach, and each
@@ -125,7 +125,7 @@ function bounded(algorithm, stream, cap, E, codes, label) {
     throw new TypeError("guard.compress.bounded: stream must be a Buffer (route the input through guard.bytes.view first)");
   }
   // The ceiling is an authoring input: an undefined / NaN / fractional / negative
-  // cap would silently disable the bomb defence. It must also be at least 1 --
+  // cap would silently disable the bomb defense. It must also be at least 1 --
   // node rejects maxOutputLength 0 with a different fault than a cap breach, so a
   // zero cap would surface as a malformed-stream verdict instead of a config error.
   if (!Number.isInteger(cap) || cap < 1) {

package/lib/guard-der.js

@@ -26,7 +26,7 @@
 // Every entry point takes the CALLER's error factory and code, so a c509 splice reports in
 // the c509 domain and a certificate builder in the x509 domain.
 // asn1-der composes this guard family, so requiring the codec at module scope would read its
-// exports mid-initialisation and see an empty object. The require and the table it builds are
+// exports mid-initialization and see an empty object. The require and the table it builds are
 // therefore both deferred to first use -- the documented circular-load exception to top-of-file
 // requires. Guards sit BELOW the codec in the dependency order; this is the one place that
 // order is inverted, and it is inverted lazily.

package/lib/guard-identifier.js

@@ -84,9 +84,9 @@ function assertCanonicalOid(str, E, code, label, boundsCode) {
 // The shape this replaces was hand-written in a dozen callers, and it is worth one home because
 // getting it wrong fails open in the quietest possible way: an options object whose key is
 // misspelled silently carries the default, so a caller who asked for a stricter check gets the
-// looser behaviour and no error. Two details are easy to lose in a re-inline and are fixed here.
+// looser behavior and no error. Two details are easy to lose in a re-inline and are fixed here.
 // `known` is consulted with hasOwnProperty and not a truthiness test, so an inherited Object
-// member ("constructor", "toString") cannot read as a recognised key; and the walk is over own
+// member ("constructor", "toString") cannot read as a recognized key; and the walk is over own
 // enumerable keys, so a `__proto__` arriving from JSON is inspected instead of skipped.
 //
 // @enforced-by behavioral -- an options-shape walk has no rename-proof code shape; the RED vectors
@@ -99,7 +99,7 @@ function assertCanonicalOid(str, E, code, label, boundsCode) {
 //
 // @enforced-by guard-shape-reinlined
 // The shape requires the throw: an identical walk whose body filters on the same table (copying the
-// recognised keys onward instead of rejecting the unrecognised ones) is a different operation with
+// recognized keys onward instead of rejecting the unrecognized ones) is a different operation with
 // no fail-open risk, and must not be dragged through a guard that only knows how to reject.
 // @guard-shape Object\.keys\(\w+(?:\.\w+)*\)\.forEach\(function \((\w+)\) \{\s*if \(![\w.]+\[\1\]\) (?:\{\s*)?throw
 function assertKnownKeys(obj, known, E, code, message) {

package/lib/guard-limits.js

@@ -90,7 +90,7 @@ function depthCap(value, key, dflt) {
 function counter(max, E, code, label) {
   // The ceiling is an authoring input: an undefined / NaN / fractional max
   // builds a counter whose `n > max` never fires, leaving a silently dead fanout
-  // defence. Reject at construction (config-time TypeError).
+  // defense. Reject at construction (config-time TypeError).
   if (!Number.isInteger(max) || max < 0) {
     throw new TypeError("guard.limits.counter: max must be a non-negative integer");
   }
@@ -117,7 +117,7 @@ function counter(max, E, code, label) {
 //   over-size RED vectors driving the composing verifiers are the guard.
 function byteCap(buf, max, E, code, label) {
   // The ceiling is an authoring input: an undefined / NaN / fractional / negative
-  // max makes `length > max` never fire, and the size defence is then silently
+  // max makes `length > max` never fire, and the size defense is then silently
   // dead. Reject at config time (TypeError), regardless of the value currency E selects.
   if (!Number.isInteger(max) || max < 0) {
     throw new TypeError("guard.limits.byteCap: max must be a non-negative integer");

package/lib/guard-parsed.js

@@ -44,7 +44,7 @@ var bytes = require("./guard-bytes");
 // ArrayBuffer. Testing `Buffer.isBuffer(x) || x instanceof Uint8Array` is narrower than what the
 // verbs document, and the narrowness is invisible in the good case: an ArrayBuffer would fall
 // through to the object branch and be refused as a rebuilt structure, which reads to the caller as
-// "your certificate is malformed" when what happened is that their container was not recognised.
+// "your certificate is malformed" when what happened is that their container was not recognized.
 // guard.bytes is what finally reads them, and it accepts all four, so the door has to as well.
 function _isBytes(x) {
   return Buffer.isBuffer(x) || ArrayBuffer.isView(x) || x instanceof ArrayBuffer;

package/lib/guard-range.js

@@ -105,7 +105,7 @@ function uint64(value, E, code, label) {
 // take. Accepts a bigint, or a Number that is a safe integer (isSafeInteger, not
 // isInteger, because a Number above 2^53 has already lost precision by the time it
 // arrives), so a large identifier MUST come as a bigint and cannot be silently
-// rounded to a neighbour. Everything else is a config-time reject.
+// rounded to a neighbor. Everything else is a config-time reject.
 //
 // Distinct from int() on purpose: int() BOUNDS a value the wire decoded and narrows
 // it to Number; this one is unbounded and returns BigInt, because the field has no

package/lib/guard-secret.js

@@ -72,7 +72,7 @@ function zeroize(value, ErrorClass, code, label) {
 // @enforced-by behavioral -- this is a loop over zeroize, which carries the family's only
 // rename-proof shape (the `.fill(0)` above). It introduces no shape of its own, so a lexical
 // detector here would anchor on a renameable symbol and go silently green (drift rule sec. 3).
-// The behavioural guards are guard-secret.test.js (holes tolerated, every member cleared) and the
+// The behavioral guards are guard-secret.test.js (holes tolerated, every member cleared) and the
 // CMS vectors that assert the shared secret and KEK are wiped on both the success and failure paths.
 function zeroizeAll(list, ErrorClass, code, label) {
   if (!list) return list;

package/lib/guard-text.js

@@ -50,7 +50,7 @@ function decode(input, maxBytes, ErrorClass, spec) {
   if (Buffer.isBuffer(input)) {
     // Re-view through the byte guard first so a detached backing ArrayBuffer (a
     // transferred / structuredClone'd Buffer, which reads as zero-length) fails
-    // closed here -- the same detached-buffer defence the byte boundaries get --
+    // closed here -- the same detached-buffer defense the byte boundaries get --
     // instead of being decoded as an empty string. Then cap, then decode.
     input = bytes.view(input, ErrorClass, spec.badInput, spec.label);
     if (input.length > maxBytes) throw new ErrorClass(spec.tooLarge, spec.label + " exceeds the size cap");

package/lib/hpke.js

@@ -390,7 +390,7 @@ function _recipPrivate(suite, sk) {
 // psk / auth / auth-psk. An unknown mode must fail closed, never key-schedule
 // with an out-of-registry mode byte.
 // The sender and the recipient read the same option object from OPPOSITE ends, so each direction
-// gets its own table. A shared union recognises every name at both ends and so accepts the one that
+// gets its own table. A shared union recognizes every name at both ends and so accepts the one that
 // cannot do anything there: `senderPublicKey` handed to setupS, or
 // `senderKey` handed to setupR, is silently ignored, which is the exact silence these tables exist
 // to remove, in a wider form. An option that means nothing where it was passed is a misunderstanding

package/lib/http-digest.js

@@ -144,7 +144,7 @@ function _validateDigest(paramText, E, code) {
     ? p.domain.value.replace(/^\s+|\s+$/g, "").split(/\s+/) : null;
   // charset (RFC 7616 sec. 3.3): the one permitted value is the unquoted token "UTF-8". A quoted charset, or any
   // other value, is malformed, since answering it would hash the credentials in the wrong encoding, so it is
-  // rejected (and thus skipped during multi-offer selection in favour of a conforming offer).
+  // rejected (and thus skipped during multi-offer selection in favor of a conforming offer).
   if (p.charset && (p.charset.quoted || String(p.charset.value).toUpperCase() !== "UTF-8")) throw E(code, "the Digest charset must be the unquoted token UTF-8 (RFC 7616 sec. 3.3)");
   // stale (RFC 7616 sec. 3.3) is the unquoted token "true" or "false". A quoted or otherwise invalid value
   // (stale=maybe) is malformed and rejected (thus skipped in selection), never parsed as a false flag that

package/lib/jose.js

@@ -368,7 +368,7 @@ function assertPublicJwk(jwk) {
 // `key` NAMES the key this message must be signed under and `profile` selects which header rules
 // apply -- both narrow what verifies, so a misspelling of either silently widens it back to the
 // default. That is the shape this check exists for: the caller asked for something stricter and got
-// the looser behaviour, with nothing said.
+// the looser behavior, with nothing said.
 var _VERIFY_KEYS = { key: 1, profile: 1 };
 async function verify(jws, opts) {
   opts = opts || {};

package/lib/lint.js

@@ -231,7 +231,7 @@ function _subjectCNs(cert) {
   return out;
 }
 
-// An extension's criticality is honoured (RFC 5280 4.2: a consumer MUST reject a critical extension
+// An extension's criticality is honored (RFC 5280 4.2: a consumer MUST reject a critical extension
 // it cannot process) only when this toolkit actually processes its semantics. That authority is
 // path-validate's PROCESSED_EXTENSIONS (the RFC 5280 sec. 6.1 path-processing set), never the decoder
 // table: certExtensionDecoders also decodes many extensions purely for display (qcStatements, the MS

package/lib/ocsp.js

@@ -530,7 +530,7 @@ function verify(response, opts) {
     // the closed direction for `revoked`: revocation does not expire the way
     // non-revocation does, so discarding a signed, current, authorized revoked
     // verdict because it was replayed would hand a soft-fail caller the certificate
-    // the responder just refused -- turning the anti-replay defence into the thing
+    // the responder just refused -- turning the anti-replay defense into the thing
     // that accepts a revoked certificate. `nonceMatched: false` still reports that
     // this response was not bound to this request.
     if (!matched && verdict.status === "good") {

package/lib/oid.js

@@ -22,7 +22,7 @@
  *   attribute types, `2.5.29` for the extensions, `2.16.840.1.101.3.4` for
  *   the NIST algorithms), and each member names only its trailing arc. The
  *   full OID is derived from base + leaf at load, so the arc hierarchy that
- *   IS the OID namespace is modelled directly instead of re-spelled per
+ *   IS the OID namespace is modeled directly instead of re-spelled per
  *   entry. It covers the RFC 5280 attribute types and extensions, the
  *   classical signature / public-key / digest algorithms, and the
  *   NIST-assigned post-quantum arcs (ML-DSA, ML-KEM, SLH-DSA). Operators

package/lib/path-validate.js

@@ -306,7 +306,7 @@ function resolveDescriptor(sigAlg) {
 // defense). For the one-shot families whose public key shares the signature OID
 // (EdDSA, ML-DSA, SLH-DSA), Node's WebCrypto imports an SPKI of a DIFFERENT type
 // under the requested name and verifies with the real key, so an Ed25519-signed
-// certificate labelled SLH-DSA would otherwise validate. Enforce structurally:
+// certificate labeled SLH-DSA would otherwise validate. Enforce structurally:
 // the issuer SPKI's algorithm OID MUST equal the signature algorithm OID. (For
 // RSA/ECDSA -- different key vs signature OIDs -- WebCrypto's import already rejects
 // a mismatched key type, so `sameKeyOid` is not set and this is a no-op.)
@@ -1753,7 +1753,7 @@ function classifyCrls(parsed) {
       // sec. 5.2.4 @3447 makes deltaCRLIndicator a MUST-be-critical extension. A non-critical one
       // is non-conforming, so it does not earn the NEW capability of being merged -- merging can
       // RELEASE a certificate, and that must rest on a conforming indicator. It is still classified
-      // as a delta and still consulted for revocation, which is the shipped behaviour and the
+      // as a delta and still consulted for revocation, which is the shipped behavior and the
       // conservative direction.
       if (crlNumberWithinBound(n) && deltaCritical) { rec.baseCrlNumber = n; rec.mergeable = true; }
     } catch (_e) {
@@ -2393,7 +2393,7 @@ function ocspChecker(responses) {
  * `pki.schema.ocsp.parseResponse` result. A REBUILT parsed response is refused. A
  * signature check has three parts -- the signature, the algorithm that verifies it,
  * and the bytes it covers -- and on a parsed object all three are separate properties:
- * a genuine CA signature over a certificate that CA issued, relabelled, verifies as a
+ * a genuine CA signature over a certificate that CA issued, relabeled, verifies as a
  * ResponseData signature for a response that never existed. The parser marks what it
  * returns, so those three are known to have been derived together from one byte
  * string; `Object.assign`, spread and a JSON round-trip all drop the mark, which is
@@ -2795,7 +2795,7 @@ async function _fetchAiaIssuers(current, aia) {
     for (var c = 0; c < certs.length; c++) {
       var parsed;
       try { parsed = coerceCert(certs[c]); }
-      catch (_e3) { /* allow:swallow-unverified verified-unreachable: every cert here already passed the IDENTICAL x509.parse in _aiaParseBody (single-DER validates `body`; certs-only validates each via parseCertsOnly), so coerceCert re-parsing the same bytes cannot throw -- the guard stays as defence-in-depth */ continue; }
+      catch (_e3) { /* allow:swallow-unverified verified-unreachable: every cert here already passed the IDENTICAL x509.parse in _aiaParseBody (single-DER validates `body`; certs-only validates each via parseCertsOnly), so coerceCert re-parsing the same bytes cannot throw -- the guard stays as defense-in-depth */ continue; }
       out.push(parsed);
     }
   }
@@ -3111,7 +3111,7 @@ module.exports = {
   // The set of extension OIDs whose CRITICAL semantics this validator processes (RFC 5280 sec. 6.1).
   // Exposed so a linter can distinguish "processed" from "merely decoded" and stay consistent with
   // the path-validation verdict on a critical extension -- a decoder in certExtensionDecoders is NOT
-  // by itself proof the criticality is honoured. Both sets are frozen so a caller cannot mutate them.
+  // by itself proof the criticality is honored. Both sets are frozen so a caller cannot mutate them.
   PROCESSED_EXTENSIONS: PROCESSED_EXTENSIONS,
   // Extensions that ARE processed for an intermediate CA but are unprocessed on the target/leaf, so a
   // critical instance on the target fails closed (RFC 5280 sec. 6.1.5(f)) -- policyMappings is

package/lib/schema-c509.js

@@ -1650,7 +1650,7 @@ function _sdaToDer(node, isNative) {
       if (tname === undefined) throw _err("c509/bad-extensions", "a subjectDirectoryAttributes attribute type int " + ti + " has no C509 sec. 8.6 registry row");
       // countryName / serialNumber carry a CHARACTER restriction (draft sec. 3.1.4 "SHALL contain only
       // characters from the 74-character ASCII subset permitted by PrintableString"), and not a sign override --
-      // _reconAttrValue asserts the charset and honours the declared string type. Requiring the negative sign
+      // _reconAttrValue asserts the charset and honors the declared string type. Requiring the negative sign
       // here would also make these attributes unrepresentable in a NATIVE certificate, whose ints SHALL all be
       // non-negative (same sec.), so the rule is the charset, not the sign.
       for (var vi = 0; vi < valuesNode.children.length; vi++) {
@@ -1846,7 +1846,7 @@ function _reconAttrValue(rdn) {
   if (rdn.type === "emailAddress") return b.ia5(s);
   // serialNumber / countryName carry a CHARACTER restriction, not a string-type override: draft sec. 3.1.4
   // "SHALL contain only characters from the 74-character ASCII subset permitted by PrintableString". Enforce
-  // that on the CHARACTERS and still honour the sign for the string type. Coercing them to PrintableString
+  // that on the CHARACTERS and still honor the sign for the string type. Coercing them to PrintableString
   // regardless of sign would make the +N and -N encodings of one value reconstruct IDENTICAL DER, so a single
   // X.509 signature would cover two distinct C509 encodings (a malleability window in the type-3 transform).
   // b.printable IS the PrintableString charset authority -- run it for the assert even when the sign selects

package/lib/schema-cmp.js

@@ -460,7 +460,7 @@ var CERT_RESPONSE = schema.seq([
     // accepted (0) or grantedWithMods (1). Any other status (rejection, waiting,
     // the revocation / keyUpdate warnings) denies or defers the request, so a
     // certificate under it is a malformed response even when no explicit failInfo
-    // bit is set (a rejection is commonly signalled by status alone). Keying the
+    // bit is set (a rejection is commonly signaled by status alone). Keying the
     // rule off failInfo presence alone would let a bare-rejection status ship a
     // certificate (RFC 9810 sec. 5.3.4).
     if (certifiedKeyPair !== null && status.status.code !== 0 && status.status.code !== 1) {

package/lib/schema-crl.js

@@ -41,7 +41,7 @@ var CRL_REASONS = pkix.CRL_REASON_NAMES;
 
 // Extension-value decoding is keyed off the stable dotted OID (resolved once at
 // load from the canonical name) and not the mutable display name, so a caller's
-// pki.oid.register() display override cannot change parse behaviour.
+// pki.oid.register() display override cannot change parse behavior.
 var OID_CRL_NUMBER = oid.byName("cRLNumber");
 var OID_REASON_CODE = oid.byName("reasonCode");
 var OID_INVALIDITY_DATE = oid.byName("invalidityDate");

package/lib/schema-engine.js

@@ -40,11 +40,11 @@ function _fail(ctx, code, message) {
 }
 
 // ---- shape assertions ------------------------------------------------
-// A schema's `assert` mode is a real behaviour-preservation control: some
+// A schema's `assert` mode is a real behavior-preservation control: some
 // hand-written guards checked the universal SEQUENCE tag (algorithmIdentifier,
 // Name), others checked only that the node had children (Validity, SPKI, the
 // tbs body, an AttributeTypeAndValue). Collapsing them to one "is a SEQUENCE"
-// check would silently change behaviour on SET-wrapped input, so each is kept.
+// check would silently change behavior on SET-wrapped input, so each is kept.
 
 function _assertShape(schema, node, ctx) {
   var mode = schema.assert || "sequence";

package/lib/schema-pkix.js

@@ -1228,7 +1228,7 @@ function certExtensionDecoders(ns) {
 
   // qcStatements ::= SEQUENCE OF QCStatement (RFC 3739 sec. 3.2.6). QCStatement ::= SEQUENCE {
   // statementId OBJECT IDENTIFIER, statementInfo ANY DEFINED BY statementId OPTIONAL }. Known statementIds
-  // (RFC 3739 id-qcs + the ETSI EN 319 412-5 esi4 catalog) decode their statementInfo; an unknown statementId
+  // (RFC 3739 id-qcs + the ETSI EN 319 412-5 esi4 catalogue) decode their statementInfo; an unknown statementId
   // is preserved OPAQUE (the RFC 3739 open type), never rejected. The DEFINED-BY selection is an OID re-dispatch.
   function _qcStr(node, tag, C, what) {
     if (!node || node.tagClass !== "universal" || node.tagNumber !== tag) throw ns.E(C, what);

package/lib/smime.js

@@ -846,7 +846,7 @@ function _capped(msg) {
  * compared under RFC 5280 sec. 7.5: the local-part exactly, the host-part case-insensitively. The
  * address is read from the `subjectAltName` `rfc822Name` entries (RFC 8550 sec. 4.4.3) and, where the
  * extension carries none, from the subject DN's PKCS #9 `emailAddress` attribute, which RFC 8550 sec. 3
- * requires a receiving agent to recognise. Where both are present the extension wins. Only a signer
+ * requires a receiving agent to recognize. Where both are present the extension wins. Only a signer
  * whose signature verified contributes an identity, so a tampered message cannot report a binding. `match` is THREE-valued and a caller enforcing sender binding tests
  * `match === true` -- `false` means every identity was comparable and none matched, and `null` means the
  * question was not answered (no `expectedSender` and no single outer `From`, a signer certificate

package/lib/validator-cose.js

@@ -8,7 +8,7 @@
 // validator-cose -- the SINGLE home for "is this a conformant WebAuthn credential
 // COSE_Key" (RFC 9052 sec. 7 structure + RFC 9053 EC2/OKP/RSA key parameters + the
 // CTAP2 canonical-CBOR profile WebAuthn sec. 6.5.1 imposes). Sibling to the guard
-// family: where a guard owns a CVE-class fail-closed defence once, a validator owns a
+// family: where a guard owns a CVE-class fail-closed defense once, a validator owns a
 // decoded TYPE's COMPLETE conformance rule set once, so a format module composes the
 // family instead of re-deriving a partial subset inline (the drift that leaks MUSTs
 // out one review round at a time). Enforced by the validator-shape-reinlined
@@ -242,10 +242,10 @@ function assertKeyMaterial(key, E, code, unsupportedCode) {
   // PROFILE: the declared alg must match the key type (and, for EC2, the curve).
   var prof = ALG_PROFILE[String(key.alg)];
   // An algorithm this verifier does not implement is not a malformed key. The key can be perfectly
-  // well-formed (the same bytes may parse under a neighbouring algorithm id), and a relying
+  // well-formed (the same bytes may parse under a neighboring algorithm id), and a relying
   // party migrating credential rows written elsewhere needs to tell "I cannot check this
   // algorithm" from "these bytes are wrong", since only one of those is fixable by re-registering.
-  // Callers that do not distinguish the two pass one code and keep the previous behaviour.
+  // Callers that do not distinguish the two pass one code and keep the previous behavior.
   if (!prof) throw new E(unsupportedCode || code, "unsupported credential key algorithm " + key.alg);
   if (prof.kty !== key.kty) throw bad("credential key algorithm " + key.alg + " is inconsistent with key type " + key.kty);
   if (prof.crv != null && prof.crv !== key.crv) throw bad("credential key algorithm " + key.alg + " requires a different curve");

package/lib/webauthn-mds.js

@@ -85,7 +85,7 @@ function _schemeE(kind, message, cause) { return new WebauthnError("webauthn/" +
 // WebCrypto algorithms.
 //
 // Null-prototype: `alg` is attacker-supplied, and an inherited Object member would otherwise
-// resolve to a truthy non-row and read as a recognised algorithm.
+// resolve to a truthy non-row and read as a recognized algorithm.
 function _deriveBlobAlgs() {
   var out = Object.create(null);
   jose.sigAlgs().forEach(function (row) {
@@ -120,7 +120,7 @@ function _blobAlgParams(algRow, leafAlgName) {
 
 // The status values that deny trust (MDS v3.0 sec. 3.1.4). An unknown status is IGNORED for the
 // gate and surfaced raw -- the specification requires that a verifier not fail on a status it does
-// not recognise -- unless the caller opts into refusing them.
+// not recognize -- unless the caller opts into refusing them.
 var DISQUALIFYING = Object.assign(Object.create(null), {
   REVOKED: 1, ATTESTATION_KEY_COMPROMISE: 1, USER_KEY_REMOTE_COMPROMISE: 1,
   USER_KEY_PHYSICAL_COMPROMISE: 1, USER_VERIFICATION_BYPASS: 1,
@@ -140,7 +140,7 @@ var _BLOB_OPTS = Object.assign(Object.create(null), {
 function _isPlainObject(v) { return !!v && typeof v === "object" && !Array.isArray(v); }
 
 // The results this module actually produced. Membership is the PROVENANCE check: a metadata object
-// is only allowed to decide trust if verifyMetadataBlob made it. Recognising it by shape instead
+// is only allowed to decide trust if verifyMetadataBlob made it. Recognizing it by shape instead
 // would accept anything carrying the right property names, including a catalogue deserialized
 // from a cache, where nothing establishes that the signature and chain were ever checked, and an
 // attacker who can write that cache chooses which roots an authenticator is allowed to chain to.
@@ -207,7 +207,7 @@ function _isAnchorItself(cert, anchor) {
 //
 // An already-parsed certificate is taken as-is, never re-encoded and re-parsed, but the
 // recognition test names every field the anchor is later read for: the subject name, the public
-// key bytes, and the signature algorithm OID. Recognising an object on a looser test lets something
+// key bytes, and the signature algorithm OID. Recognizing an object on a looser test lets something
 // that is merely certificate-SHAPED through: a parsed CSR satisfies "has a subject and an SPKI", and
 // a hand-built object literal satisfies it too and then raises a raw TypeError from deep inside the
 // path validator, which is an untyped throw escaping a public verb.
@@ -250,8 +250,8 @@ function _verifyMetadataBlob(blob, opts) {
     throw _err("webauthn/bad-input", "opts.previousNo must be a non-negative safe integer");
   }
   // The boolean options are checked for TYPE, not merely compared against true. A caller who wrote
-  // `rejectUnknownStatus: "true"` from a config file is asking for the stricter behaviour; comparing
-  // against `true` silently records the policy as off and the authenticator carrying an unrecognised
+  // `rejectUnknownStatus: "true"` from a config file is asking for the stricter behavior; comparing
+  // against `true` silently records the policy as off and the authenticator carrying an unrecognized
   // status is then accepted -- the fail-open the option exists to prevent.
   ["requireRollbackCheck", "allowStale", "rejectUnknownStatus"].forEach(function (k) {
     if (opts[k] !== undefined && typeof opts[k] !== "boolean") {
@@ -326,7 +326,7 @@ function _verifyMetadataBlob(blob, opts) {
       maxBytes: C.MDS_BLOB_HEADER_MAX_BYTES, maxDepth: C.JSON_MAX_DEPTH,
       tooLarge: "webauthn/too-large", badJson: "webauthn/bad-metadata-blob",
       // Every code the guard can raise is named. An omitted one falls back to the framework default
-      // and the module's own defences -- duplicate-member smuggling, the depth cap -- surface under
+      // and the module's own defenses -- duplicate-member smuggling, the depth cap -- surface under
       // a generic code no webauthn/* consumer can switch on.
       tooDeep: "webauthn/bad-metadata-blob", duplicateMember: "webauthn/bad-metadata-blob",
       badInput: "webauthn/bad-metadata-blob", label: "the metadata BLOB header",
@@ -449,7 +449,7 @@ function _verifyMetadataBlob(blob, opts) {
 // anchors through this same walk while keeping the verdict its own callers already handle. A second copy
 // of the walk is not merely duplication: the anchor-stripping rule is subtle (a terminal
 // certificate that IS the anchor is identified by subject name AND public key, which is what
-// recognises a cross-signed root), and a copy that got it slightly differently would refuse a valid
+// recognizes a cross-signed root), and a copy that got it slightly differently would refuse a valid
 // chain in one place and accept a self-validated one in another.
 function _chainToAnchor(chain, anchors, at, what, code) {
   var subject = what || "metadata BLOB certificate chain";
@@ -509,7 +509,7 @@ function _staleAfter(nextUpdate) {
 // has to be re-established every time it decides something, not only when it was parsed. A
 // catalogue fetched before its nextUpdate and reused a month later would otherwise keep authorizing
 // an authenticator whose status reports have since revoked it, which is precisely what nextUpdate
-// exists to prevent. The caller's original allowStale decision is carried on the result and honoured
+// exists to prevent. The caller's original allowStale decision is carried on the result and honored
 // here, so opting out stays opted out and never silently reappears at the point of use.
 function assertFresh(metadata, at, label) {
   if (!metadata || metadata.allowStale === true || typeof metadata.nextUpdate !== "string") return;
@@ -696,7 +696,7 @@ function metadataFor(metadata, identifier) {
   return null;
 }
 
-// The options metadataAnchors recognises. Null-prototype for the same reason every other
+// The options metadataAnchors recognizes. Null-prototype for the same reason every other
 // caller-keyed table in this namespace is: a supplied key must not resolve to an inherited member.
 var _ANCHOR_OPTS = Object.assign(Object.create(null), { metadata: 1, time: 1, certificate: 1 });
 
@@ -846,13 +846,13 @@ function statusDenied(entry, metadata, leaf, at) {
     if (s === null) return false;
     // Scope was settled above, so anything still here applies to this authenticator.
     if (DISQUALIFYING[s]) return true;
-    // An unrecognised status is IGNORED for the gate unless the caller opted in: the specification
+    // An unrecognized status is IGNORED for the gate unless the caller opted in: the specification
     // requires a verifier not to fail on a status value it does not know.
     return rejectUnknown && !_KNOWN_STATUS[s];
   });
 }
 
-// Status values this library recognises as non-disqualifying, so `rejectUnknownStatus` can tell an
+// Status values this library recognizes as non-disqualifying, so `rejectUnknownStatus` can tell an
 // unknown value from a known-good one.
 var _KNOWN_STATUS = Object.assign(Object.create(null), {
   NOT_FIDO_CERTIFIED: 1, SELF_ASSERTION_SUBMITTED: 1, FIDO_CERTIFIED: 1, FIDO_CERTIFIED_L1: 1,

package/lib/webauthn.js

@@ -474,8 +474,8 @@ var ATT_STMT_MAJOR = { compound: 4 };
 var _AAGUID_SIGNED_BY_FMT = Object.assign(Object.create(null), { "fido-u2f": false });
 function _aaguidIsSigned(fmt) { return _AAGUID_SIGNED_BY_FMT[fmt] !== false; }
 
-// The options pki.webauthn.verify recognises. Null-prototype, so a caller-supplied key cannot
-// resolve to an inherited Object member and read as recognised.
+// The options pki.webauthn.verify recognizes. Null-prototype, so a caller-supplied key cannot
+// resolve to an inherited Object member and read as recognized.
 var _VERIFY_OPTS = Object.assign(Object.create(null), {
   time: 1, metadata: 1, tpmPolicy: 1, safetyNetRoots: 1, verifySafetyNetJws: 1, requireCtsProfileMatch: 1,
   expectedRpId: 1, requireUserPresence: 1, requireUserVerification: 1, allowedAlgorithms: 1,
@@ -511,7 +511,7 @@ var _FORMAT_SCOPED_BOOLEAN_OPTS = ["verifySafetyNetJws", "requireCtsProfileMatch
 // so a caller that recycles the array or overwrites a certificate's bytes in between
 // would have the attestation anchored against the replacement roots while the verdict
 // still reports `anchoredTo: "rootCertificates"` (CWE-367 reaching a wrong trust
-// decision). Same defence, and the same reason, as the assertion input's snapshot.
+// decision). Same defense, and the same reason, as the assertion input's snapshot.
 // Shape faults are NOT raised here: the array is validated where it is consumed, so
 // supplying a malformed pin alongside a metadata catalogue that answers keeps failing
 // exactly where it did before.
@@ -645,7 +645,7 @@ function _applyCallerRoots(res, supplied, vopts, onlyPaths) {
   var at = vopts.time !== undefined ? vopts.time : new Date();
   // EVERY path, not merely one: a compound's elements are independent claims, and
   // accepting the whole because one element anchored would let an unanchored element
-  // ride along on its neighbour's trust.
+  // ride along on its neighbor's trust.
   return paths.reduce(function (p, info) {
     return p.then(function () {
       var pathAt = vopts.time !== undefined ? vopts.time : (info.at || at);
@@ -1114,7 +1114,7 @@ var VERIFIERS = {
           });
       });
     }, Promise.resolve()).then(function () {
-      // sec. 8.9 lists the supported attestation type as "Any" and authorises returning
+      // sec. 8.9 lists the supported attestation type as "Any" and authorizes returning
       // "implementation-specific values representing any combination of outputs". A distinct type
       // rather than a merge: collapsing to the strongest element would let a wrapper upgrade a
       // caller's attestationType check, and collapsing to the weakest would spuriously fail one.
@@ -1388,7 +1388,7 @@ function verify(attestationObject, clientDataHash, opts) {
   // Every option here either GATES the verdict or supplies the trust material a gate needs, so a
   // misspelled key is not a harmless no-op: `metdata` leaves the metadata gate switched off and the
   // call returns a pass the caller believes was checked against the catalogue. Reject an
-  // unrecognised key at the boundary, and validate the one shared option every arm reads, so a bad
+  // unrecognized key at the boundary, and validate the one shared option every arm reads, so a bad
   // instant is a config fault here rather than a trust failure reported from deep inside a chain.
   try {
     if (!_isPlainObject(opts)) throw _err("webauthn/bad-input", "opts must be an object");
@@ -1406,7 +1406,7 @@ function verify(attestationObject, clientDataHash, opts) {
     // The boolean switches are typed HERE rather than in the arm that reads them. Validated only
     // inside the android-safetynet arm, `requireCtsProfileMatch: "true"` reaching any other format
     // is never examined at all -- a truthy string that demands nothing, silently accepted. A
-    // recognised key with an unusable value is the same class of caller mistake as an unrecognised
+    // recognized key with an unusable value is the same class of caller mistake as an unrecognized
     // key, and belongs at the same boundary.
     _FORMAT_SCOPED_BOOLEAN_OPTS.forEach(function (k) {
       if (opts[k] !== undefined && typeof opts[k] !== "boolean") throw _err("webauthn/bad-input", "opts." + k + " must be a boolean");
@@ -1597,7 +1597,7 @@ function verify(attestationObject, clientDataHash, opts) {
 function _applyMetadata(res, att, opts) {
   var md = opts.metadata;
   // Provenance, not shape: only a catalogue this toolkit actually verified may decide which roots
-  // an authenticator is allowed to chain to. Recognising it by its property names would accept a
+  // an authenticator is allowed to chain to. Recognizing it by its property names would accept a
   // hand-built object, or one restored from a cache an attacker can write -- neither of which has
   // been through the signature and chain checks that give the catalogue its authority.
   if (!mds.isVerifiedResult(md)) {
@@ -1703,7 +1703,7 @@ function _applyMetadata(res, att, opts) {
   mds.assertFresh(md, at, "the metadata supplied as opts.metadata");
   // EVERY path must pass, not merely one of them: for a compound attestation each element is an
   // independent claim, and accepting the whole because one element anchored would let an
-  // unanchored -- or revoked -- element ride along on its neighbour's trust.
+  // unanchored -- or revoked -- element ride along on its neighbor's trust.
   // Govern EVERY path BEFORE any is chain-validated, and let the SEVEREST outcome decide
   // rather than the first one reached. A compound's elements are independent claims and
   // its element order is NOT signed, so aborting on the first failure lets that order pick
@@ -1836,7 +1836,7 @@ void constants;
  *     (the default; any disqualifying report ever filed), `"latest-by-date"` (only the
  *     most recent report counts, so a later remediation clears an earlier revocation),
  *     or a function receiving the raw report array and returning true to deny.
- *   - `rejectUnknownStatus` -- treat a status this toolkit does not recognise as
+ *   - `rejectUnknownStatus` -- treat a status this toolkit does not recognize as
  *     disqualifying. Off by default: the specification requires an unknown status be
  *     ignored, never failed on.
  *
@@ -2146,7 +2146,7 @@ function parseAuthenticatorData(bytes) {
   return _parseAuthData(_bytesArg(bytes, "authenticatorData"), _err);
 }
 
-// The options pki.webauthn.verifyAssertion recognises, null-prototype for the same
+// The options pki.webauthn.verifyAssertion recognizes, null-prototype for the same
 // reason _VERIFY_OPTS is.
 var _ASSERT_OPTS = Object.assign(Object.create(null), {
   authenticatorData: 1, clientDataHash: 1, clientDataJSON: 1, signature: 1,

package/lib/webcrypto.js

@@ -1344,7 +1344,7 @@ function exportAnyKey(key, E, code) {
   // A separately-installed copy of this engine is the same code under a different class identity, so
   // its keys fail the `instanceof` above while carrying the very handle this engine reads -- and no
   // WebCrypto implementation but that copy would accept them. Read the handle directly. The
-  // extractable check above stays AHEAD of this: the handle can always be read, so honouring the
+  // extractable check above stays AHEAD of this: the handle can always be read, so honoring the
   // key's own extractable promise is this branch's responsibility, not the crypto library's.
   var handle = key._handle;
   if (handle instanceof nodeCrypto.KeyObject && handle.type === key.type) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/pki",
-  "version": "0.5.9",
+  "version": "0.5.10",
   "description": "Pure-JavaScript PKI toolkit that owns its stack — X.509, ASN.1/DER, CMS, PQC-first.",
   "license": "Apache-2.0",
   "author": "blamejs contributors",
@@ -68,9 +68,11 @@
     "test": "node test/smoke.js",
     "lint": "eslint --max-warnings 0 .",
     "fuzz": "npm ci --prefix fuzz && npx --prefix fuzz jazzer fuzz/asn1-der.fuzz.js -- -max_total_time=60",
-    "gates": "node test/layer-0-primitives/codebase-patterns.test.js && node scripts/validate-source-comment-blocks.js && node scripts/check-api-snapshot.js",
+    "gates": "node test/layer-0-primitives/codebase-patterns.test.js && node scripts/validate-source-comment-blocks.js && node scripts/check-api-snapshot.js && node scripts/check-spelling-consistency.js",
+    "check:spelling": "node scripts/check-spelling-consistency.js",
     "coverage": "c8 --include=lib/** --include=index.js --reporter=text-summary --reporter=lcov node test/smoke.js",
     "check:prose": "node scripts/check-operator-prose.js",
+    "check:prose:all": "node -e \"process.env.PKI_PROSE_CHECKS='all';var r=require('child_process').spawnSync(process.execPath,['scripts/check-operator-prose.js'],{stdio:'inherit'});if(r.error)throw r.error;process.exit(r.signal?1:r.status)\"",
     "check:swallows": "node scripts/check-swallow-coverage.js",
     "coverage:gated": "npm run coverage && npm run check:swallows",
     "coverage:unified": "node scripts/coverage-unified.js",

package/sbom.cdx.json

@@ -2,10 +2,10 @@
   "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
   "bomFormat": "CycloneDX",
   "specVersion": "1.5",
-  "serialNumber": "urn:uuid:0541b2cd-7339-4ee1-9122-38999da30d35",
+  "serialNumber": "urn:uuid:b51c65a4-3df8-4dec-af37-301d0b285af6",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-08-18T06:52:40.138Z",
+    "timestamp": "2026-08-18T10:39:56.596Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/pki@0.5.9",
+      "bom-ref": "@blamejs/pki@0.5.10",
       "type": "application",
       "name": "pki",
-      "version": "0.5.9",
+      "version": "0.5.10",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "Pure-JavaScript PKI toolkit that owns its stack — X.509, ASN.1/DER, CMS, PQC-first.",
-      "purl": "pkg:npm/%40blamejs/pki@0.5.9",
+      "purl": "pkg:npm/%40blamejs/pki@0.5.10",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/pki@0.5.9",
+      "ref": "@blamejs/pki@0.5.10",
       "dependsOn": []
     }
   ]