@blamejs/pki 0.5.13 → 0.5.15

package/CHANGELOG.md

@@ -4,6 +4,40 @@ 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.15 — 2026-08-19
+
+`pki.attrcert.verify` checks an attribute certificate against the RFC 5755 validation rules, so a consumer reading its privilege attributes is reading ones an issuer actually granted.
+
+### Added
+
+- `pki.attrcert.verify(ac, issuer, opts)` performs the checks of RFC 5755 sec. 5 that an attribute certificate and a named issuer can settle between them: the signature over the exact `AttributeCertificateInfo` bytes, through the one path-validation signature engine with its algorithm-confusion and EdDSA low-order-point gates; the AC naming the issuer this verifier trusts; the evaluation instant lying within the validity, where equality with either bound succeeds as the section states; the sec. 4.3.2 targeting rule, where an AC that names targets is refused at a verifier it does not name; and rejection of any critical extension this verb does not process. Section 5 defines support as parsing the value AND rejecting where the value would reject, so an extension parsed but never evaluated is not supported: targeting is processed and an audit identity states no rule that rejects, while `aaControls` and `acProxying` carry constraints this verb does not evaluate, so a critical one is refused, and a critical extension defined in future defaults to refused. Targeting compares each GeneralName form under its own matching rule: a dNSName folds case across the whole name (RFC 5280 sec. 7.2), a mailbox matches its local-part exactly and its host-part case-insensitively (sec. 7.5), and a directoryName goes through the same distinguished-name comparison the rest of the toolkit uses. A URI compares as encoded, since sec. 7.4 makes URI equality a full RFC 3987 normalization that a partial version could get wrong in the accepting direction; a form with no comparison here reports the check as not performed rather than as a pass. The third Target alternative, targetCert, is one sec. 4.3.2 says "MUST NOT be used", so an attribute certificate carrying one is refused before any match is considered, and a matching entry beside it does not rescue it -- the issuer broke a MUST NOT of its own profile, and letting the verdict turn on which entries rode alongside the forbidden one would leave the outcome to whoever assembled the certificate.
+- `issuer` is `{ name, publicKey }` and is required. Section 5 item 4 makes trusting an AC issuer the verifier's own configuration, so it is an argument this verb refuses to infer from the certificate that wants to be trusted. `issuer.name` takes every form `pki.attrcert.sign` accepts for the issuing authority -- a string, an array of RDNs, or raw `Name` DER -- and is compared as a distinguished name under RFC 5280 section 7.1, so an attribute certificate issued under a multi-RDN authority name is verifiable under that same name. An empty distinguished name names no issuer and is refused, whichever form it arrives in.
+- Revocation is RFC 5755 section 6, outside section 5's seven rules, and it gates every pass. This verb implements the section's "never revoke" scheme, which AC users MUST support: it holds no revocation evidence and follows no pointer out of the certificate. The section states what that obliges -- "If only the 'never revoke' scheme is supported, then all ACs that do not contain a noRevAvail extension, MUST be rejected" -- because an issuer that omits `noRevAvail` is stating that revocation status checks are supported, so a verdict that skipped one would grant privileges the issuer expected to be able to withdraw. An attribute certificate carrying `noRevAvail` verifies and reports `revocationChecked: true` with `noRevAvail: true`. One without it is refused unless the caller passes `opts.revocationStatus` (`"notRevoked"` or `"revoked"`), the status they established through the section's "pointer in AC" scheme; the certificate's own `crlDistributionPoints` and `authorityInfoAccess` reach them on the verdict's `extensions` to follow. The two schemes are alternatives, and section 6 closes by saying so -- "An AC MUST NOT contain both a noRevAvail extension and a 'pointer in AC'" -- so an attribute certificate carrying both tells a verifier two different things about its own revocation and is refused however the caller answers.
+- `opts.time` and `opts.target` are read at the call, before signature verification suspends it. A verdict assembled from options re-read after the signature settles would answer for whatever the caller last wrote, so a caller could hand in an expired instant, replace it while the signature was being checked, and be told the attribute certificate was timely. Mutating the `Date` in place has the same effect and is closed the same way: the instant is taken at the call, and the target is decoded there. `issuer.publicKey` is copied at the call for the same reason. The signature engine holds that buffer across the suspension, and a composite arm keeps slices of it and imports them only once its digest settles, so a caller could otherwise hand in an unrelated key of the same length, overwrite it with the real issuer's while the digest ran, and be told the certificate verified under the key they named.
+- The verdict is `{ verified, signatureValid, validityChecked, targetingChecked, revocationChecked, noRevAvail, holderBindingChecked, issuerPathChecked, holder, issuer, attributes, extensions, notBefore, notAfter, serialNumberHex, reason }`, its fields re-derived from the signed bytes. The two checks needing certificates this verb is not given -- the holder's own certificate and chain, and the AC issuer's chain and sec. 4.5 profile -- report `false` in their own slots rather than leaving their absence to read as a pass; run those through `pki.path.validate` with the certificates you hold. Omitting `opts.time` leaves the validity question unasked, which reports `validityChecked: false` and never `verified: true`.
+
+### Changed
+
+- `pki.attrcert.sign` refuses to issue an attribute certificate carrying both a `noRevAvail` extension and a `crlDistributionPoints` or `authorityInfoAccess` revocation pointer, which RFC 5755 section 6 says an AC MUST NOT do. The rule is held over the extensions the certificate ends up with, so it binds the named-extension form and the pre-encoded DER form alike.
+- `pki.schema.attrcert.parse` now records the bytes it read, joining the certificate, CRL, CMS, certification-request and certificate-request-message parsers, and `pki.attrcert.verify` accepts only a result carrying that record. A parsed attribute certificate presents the signed byte range and the attributes granting the privileges as separate properties, so a rebuilt one can hold a genuine issuer's signed bytes beside substituted attributes. As with those parsers, the raw byte views on a parsed result now read from the parser's own copy of the input; passing DER or PEM is unaffected.
+
+## v0.5.14 — 2026-08-19
+
+`pki.crmf.verifyPop` checks the proof of possession on an inbound certificate request message, the CRMF counterpart to the PKCS#10 check that shipped in 0.5.13.
+
+### Added
+
+- `pki.crmf.verifyPop(messages)` verifies the RFC 4211 proof of possession on each `CertReqMsg`, returning one verdict per message plus a top-level `verified` that is true only when every message carried a proof that held. For the `signature` proof the covered bytes are the ones the RFC names: the DER of `poposkInput` when that field is present, and the DER of `certReq` when it is absent (sec. 4.1, and the ASN.1 module, which is where the two readings of that sentence are settled). Verification composes the one path-validation signature engine, with the same algorithm-confusion (RFC 9814 sec. 4) and EdDSA low-order-point gates as the certificate and CRL paths.
+- The proofs that cannot be checked from the message are reported as such. `raVerified` is an RA's assertion that it confirmed possession out of band, so it yields `verified: false` with `method: "raVerified"`, and a caller who trusts that RA opts in by reading `method`. `keyEncipherment` and `keyAgreement` complete over a later protocol exchange, or need the CA's decryption key, so they yield `verified: false` naming the arm. Each verdict carries only what its preimage covers, re-derived from the message's own bytes, so a CA issues from what was checked. `publicKey` is the key possession was proven for. `subject` is the requested name when the signature was over `certReq`, which covers the whole template; a `poposkInput` preimage covers the key and the sender alone, so a subject sitting beside it in the message is unsigned and is withheld with `subjectBound: false` rather than reported next to a passing verdict.
+
+### Changed
+
+- `pki.schema.crmf.parse` now records the bytes it read, joining the certificate, CRL, CMS and certification-request parsers, and `pki.crmf.verifyPop` accepts only a result carrying that record. A parsed message set presents the byte range a proof covers and the template a certificate would be issued from as separate properties, so a rebuilt one can hold a genuine requester's signed range beside a substituted subject. As with those parsers, the raw byte views on a parsed result now read from the parser's own copy of the input; passing DER is unaffected, and a parse result used as-is still works.
+
+### Fixed
+
+- The `pki.csr.sign` example passed `subject: "CN=device-42"`, which asks for a commonName whose value is the string `CN=device-42` and so issues `CN=CN=device-42`. A bare string is the commonName value throughout the toolkit; the example now says so and passes `"device-42"`.
+
 ## v0.5.13 — 2026-08-19
 
 `pki.csr.verify` checks an inbound certification request's proof of possession, so a CA built on this toolkit can tell that the requester holds the key they are asking it to certify.

package/README.md

@@ -231,8 +231,8 @@ comment blocks, is at [pkijs.com](https://pkijs.com).
 | `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` |
 | `pki.x509` | Certificate issuance (RFC 5280 §4). `sign(spec, issuer, opts)` builds and signs a certificate from a `spec` of subject (a common-name string, an array of RDNs, or raw Name DER), the public key being certified, the validity window, an optional serial, and an optional `extensions` object. The `issuer` is a key alone (self-signed: issuer equals subject, signed with that key), a name plus public key plus key, or an issuing certificate plus key. The signature algorithm is resolved from the signing key through the shared registry, so RSA (PKCS#1 v1.5 or PSS via `opts.pss`), ECDSA P-256/384/521, Ed25519, Ed448, ML-DSA-44/65/87, the twelve SLH-DSA sets, and the composite arms all issue without a per-algorithm branch. It encodes basic constraints, key usage, extended key usage, subject and authority key identifiers (the SKI derived by SHA-1 of the subject key), subject alternative names, and certificate policies from the spec, taking any other extension as pre-encoded DER. It derives the version from the field set and enforces the serial bounds, the UTCTime/GeneralizedTime cutover, the DER default omissions, and the CA cross-field rules; a violation throws a typed `CertificateError`. Returns DER, or a PEM `CERTIFICATE` with `opts.pem`. Every arm is independently verified by OpenSSL. Parsing stays at `pki.schema.x509.parse` — `sign` |
 | `pki.csr` | PKCS#10 certification-request issuance (RFC 2986 / RFC 2985). `sign(spec, key, opts)` builds and signs a `CertificationRequest` from a `spec` of subject (which may be empty), the public key being certified, an optional `extensionRequest` carrying the requested v3 extensions a CA copies into the issued certificate (subject alternative names, key usage, extended key usage, basic constraints, certificate policies, subject key identifier, or an array of pre-encoded Extension DER), and an optional `challengePassword`. `key` (or `{ key }`) is the subject's own private key: the request is self-signed to prove possession of the private half of `subjectPublicKey`, and that proof is verified before the request is returned, which is what `openssl req -verify` checks. The signature algorithm is resolved from the subject key, so RSA (PKCS#1 v1.5 or PSS via `opts.pss`), ECDSA, EdDSA, ML-DSA, SLH-DSA, and the composite arms all sign without a per-algorithm branch. Returns DER, or a PEM `CERTIFICATE REQUEST` with `opts.pem`; malformed input throws a typed `CsrError`. `verify(request)` asks the same question of a request someone else produced, over its exact signed `certificationRequestInfo` bytes under the `subjectPKInfo` inside them, through the one path-validation signature engine. It answers `{ verified, subject, subjectPublicKeyInfo, attributes, certificationRequestInfoBytes }`, all re-derived from the signed bytes, so a CA issues from the fields the signature covers rather than from the object it passed in. A `verified: true` says the producer held that private key and that the subject and requested extensions are the ones they signed; who they are is the enrollment protocol's question, not this one. Parsing stays at `pki.schema.csr.parse` — `sign`, `verify` |
-| `pki.attrcert` | Attribute-certificate issuance (RFC 5755). `sign(spec, issuer, opts)` builds and signs an `AttributeCertificate` as an Attribute Authority: a `spec` of `holder` (exactly one of an entity name, a `baseCertificateID` reference, a `fromCertificate` binding, or an object digest), the validity window as GeneralizedTime, an optional serial (positive, at most 20 octets, randomly generated when omitted), the `attributes` (role, clearance, group, chargingIdentity, accessIdentity, authenticationInfo, or pre-encoded Attribute DER), and optional `extensions` (auditIdentity, targetInformation, noRevAvail, aaControls, acProxying, authorityKeyIdentifier, or pre-encoded Extension DER) each with its RFC 5755 criticality. An attribute certificate is never self-signed, so the `issuer` is the signing AA, supplied as `{ cert, key }` or `{ name, publicKey, key }`. The signature algorithm is resolved from the AA key, so RSA (PKCS#1 v1.5 or PSS via `opts.pss`), ECDSA, EdDSA, ML-DSA, SLH-DSA, and the composite arms all sign without a per-algorithm branch, and the signature is verified under the AA public key before the certificate is returned. Returns DER, or a PEM `ATTRIBUTE CERTIFICATE` with `opts.pem`; malformed input throws a typed `AttrCertError`. Parsing stays at `pki.schema.attrcert.parse` — `sign` |
-| `pki.crmf` | Certificate-request-message issuance (RFC 4211). `build(spec, key, opts)` assembles a `CertReqMessages` from a `spec` of `certReqId` (default 0, with the RFC 9483 `-1` sentinel allowed), a `certTemplate` of the requested fields (`subject`, `publicKey` as the SPKI DER of the key being certified, `validity`, requested `extensions`, an optional `version` 2), optional `controls` and `regInfo` (regToken, authenticator, utf8Pairs, oldCertID, protocolEncrKey, or pre-encoded `AttributeTypeAndValue` DER), and an optional `pop` selector. `key` (or `{ key }`) is the requester's private key: the message carries a `POPOSigningKey` proof of possession signed with the private half of `certTemplate.publicKey` and verified before the message is returned, exactly as a PKCS#10 CSR proves possession. A complete template signs the `CertRequest`; an incomplete one signs a `POPOSigningKeyInput`. The signature algorithm is resolved from the requested public key, so RSA (PKCS#1 v1.5 or PSS via `opts.pss`), ECDSA, EdDSA, ML-DSA, SLH-DSA, and the composite arms all sign without a per-algorithm branch. `key` is optional for a `raVerified` proof. Pass an array of specs for a batch; the CA-assigned template fields are never emitted. Returns DER, or a PEM block with `opts.pem`; malformed input throws a typed `CrmfError`. Parsing stays at `pki.schema.crmf.parse` — `build` |
+| `pki.attrcert` | Attribute-certificate issuance (RFC 5755). `sign(spec, issuer, opts)` builds and signs an `AttributeCertificate` as an Attribute Authority: a `spec` of `holder` (exactly one of an entity name, a `baseCertificateID` reference, a `fromCertificate` binding, or an object digest), the validity window as GeneralizedTime, an optional serial (positive, at most 20 octets, randomly generated when omitted), the `attributes` (role, clearance, group, chargingIdentity, accessIdentity, authenticationInfo, or pre-encoded Attribute DER), and optional `extensions` (auditIdentity, targetInformation, noRevAvail, aaControls, acProxying, authorityKeyIdentifier, or pre-encoded Extension DER) each with its RFC 5755 criticality. An attribute certificate is never self-signed, so the `issuer` is the signing AA, supplied as `{ cert, key }` or `{ name, publicKey, key }`. The signature algorithm is resolved from the AA key, so RSA (PKCS#1 v1.5 or PSS via `opts.pss`), ECDSA, EdDSA, ML-DSA, SLH-DSA, and the composite arms all sign without a per-algorithm branch, and the signature is verified under the AA public key before the certificate is returned. Returns DER, or a PEM `ATTRIBUTE CERTIFICATE` with `opts.pem`; malformed input throws a typed `AttrCertError`. `verify(ac, issuer, opts)` is the receiving side, performing the RFC 5755 sec. 5 checks an attribute certificate and a named issuer can settle between them: the signature over the exact `AttributeCertificateInfo` bytes through the one path-validation signature engine, the AC naming the issuer this verifier trusts (compared as a distinguished name), the evaluation instant lying within the validity with equality at either bound succeeding as the section states, the sec. 4.3.2 targeting rule, and rejection of any critical extension this verb does not process (section 5 defines support as parsing the value AND rejecting where the value would reject, so `aaControls` and `acProxying`, whose constraints it does not evaluate, are refused when critical). It answers `{ verified, signatureValid, validityChecked, targetingChecked, holderBindingChecked, issuerPathChecked, holder, issuer, attributes, extensions, notBefore, notAfter, serialNumberHex, reason }` with the fields re-derived from the signed bytes; the holder's own certificate chain and the AC issuer's chain need certificates the verb is not given, so those slots report `false` rather than letting their absence read as a pass. Parsing stays at `pki.schema.attrcert.parse` — `sign`, `verify` |
+| `pki.crmf` | Certificate-request-message issuance (RFC 4211). `build(spec, key, opts)` assembles a `CertReqMessages` from a `spec` of `certReqId` (default 0, with the RFC 9483 `-1` sentinel allowed), a `certTemplate` of the requested fields (`subject`, `publicKey` as the SPKI DER of the key being certified, `validity`, requested `extensions`, an optional `version` 2), optional `controls` and `regInfo` (regToken, authenticator, utf8Pairs, oldCertID, protocolEncrKey, or pre-encoded `AttributeTypeAndValue` DER), and an optional `pop` selector. `key` (or `{ key }`) is the requester's private key: the message carries a `POPOSigningKey` proof of possession signed with the private half of `certTemplate.publicKey` and verified before the message is returned, exactly as a PKCS#10 CSR proves possession. A complete template signs the `CertRequest`; an incomplete one signs a `POPOSigningKeyInput`. The signature algorithm is resolved from the requested public key, so RSA (PKCS#1 v1.5 or PSS via `opts.pss`), ECDSA, EdDSA, ML-DSA, SLH-DSA, and the composite arms all sign without a per-algorithm branch. `key` is optional for a `raVerified` proof. Pass an array of specs for a batch; the CA-assigned template fields are never emitted. Returns DER, or a PEM block with `opts.pem`; malformed input throws a typed `CrmfError`. `verifyPop(messages)` is the receiving side: for each `CertReqMsg` it verifies the `POPOSigningKey` signature over the bytes RFC 4211 sec. 4.1 names — the DER of `poposkInput` when present, of `certReq` when not — through the one path-validation signature engine, and answers `{ verified, messages: [{ verified, method, cryptographicallyVerified, certReqId, subject, subjectBound, publicKey, reason }] }` with the fields re-derived from the message's own bytes. Each verdict reports only what its preimage covers: `publicKey` is the key possession was proven for, and `subject` is the requested name when the `certReq` was signed. A `poposkInput` preimage covers the key and the sender alone, so any subject beside it is unsigned and is withheld with `subjectBound: false`. A `raVerified` proof is an RA's out-of-band assertion and a `keyEncipherment` or `keyAgreement` proof completes over a later exchange, so each is reported unverified with its `method` named instead of guessed. Parsing stays at `pki.schema.crmf.parse` — `build`, `verifyPop` |
 | `pki.cmp` | CMP message building, transfer, and verification (RFC 9810). `build(message, opts)` assembles a protected `PKIMessage`. `message.header` carries the `sender` and `recipient` GeneralNames (including the anonymous NULL-DN) plus optional transaction metadata; `message.body` is a single-key object naming the arm — request-side `ir`, `cr`, `kur`, `p10cr`, `certConf`, `pollReq`, `genm`, `rr`, and responder-side `ip`, `cp`, `kup`, `ccp`, `rp`, `genp`, `error`, `pollRep`, `krp`, `pkiconf`. Protection is exactly one of `opts.{ key, cert }`, a signature under the sender key with the algorithm resolved from the signer certificate so RSA (PKCS#1 v1.5 / PSS), ECDSA, EdDSA, ML-DSA, SLH-DSA, and the composite arms all sign without a per-algorithm branch, or `opts.mac`, a PBMAC1 shared-secret HMAC (RFC 9481 / 9579, PBKDF2-derived). Protection covers the exact DER of the virtual `ProtectedPart` and is self-verified before the message is returned, and `protectionAlg` is derived rather than caller-set, so the message the parser accepts is coherent by construction. `transfer(url, message, opts)` carries a built message to a CMP endpoint over `pki.transport` (RFC 9811): one POST of the DER PKIMessage, with the response classified fail-closed — 200 only for success, a non-200 2xx or an un-followed 3xx refused, a 4xx or 5xx carrying a CMP error PKIMessage forwarded as the integrity-protected verdict — and protection surfaced rather than verified. `wellKnownUrl(base, opts)` builds the §3.4 `/.well-known/cmp` request-URIs. `verify(message, opts)` checks the protection on an incoming message, either a signature through the same certification-path engine `pki.crl.verify` and `pki.ocsp.verify` use, with the EdDSA low-order-point and algorithm-confusion gates, or a PBMAC1 MAC recomputed from `opts.sharedSecret` and the message's own PBKDF2 parameters and constant-time compared, over the exact `ProtectedPart` reconstructed from the parser's raw slices. It is fail-closed on an unprotected message, a legacy or KEM MAC algorithm, an omitted keyLength, or a SHA-1 PRF, and returns a `{ valid, trusted, protectionType, signer, ... }` verdict. With `opts.trustAnchors` the signer certificate is fully path-validated (RFC 5280 §6.1 plus the RFC 9483 §3.2 `keyUsage.digitalSignature` gate) at a trusted current time, or an explicit `opts.time` for historical verification and never the message's self-asserted `messageTime`, before it is reported trusted; without one the verdict is crypto-only and the signer certificate is surfaced to anchor. `session(opts)` returns a stateful enrollment session whose `enroll(request)` drives a full `ir` / `cr` / `kur` / `p10cr` transaction over the shared transport, composing `build`, `transfer`, and `verify`. Every response is protection-verified, signer-trusted, and bound to the exchange (a stable `transactionID`, a fresh-`senderNonce` and echoed-`recipNonce` chain) before its body is read, with a bounded `pollReq` / `pollRep` loop for a `waiting` status and a `certConf` / `pkiConf` (or implicit) confirmation carrying an explicit `hashAlg` for a signature algorithm that does not convey its hash. It returns a terminal `{ outcome, certificate, chain, status, trusted, confirmed, implicitConfirm, transactionID, polls, transcript }`. The signature flavor requires `opts.trustAnchors` to authenticate the CA; a verified rejection or error and an exhausted poll budget are terminal verdicts, while a tampered, untrusted, or desynchronized response is a typed throw. Returns DER, or a PEM `CMP` block with `opts.pem`; malformed input throws a typed `CmpError`. Parsing stays at `pki.schema.cmp.parse` — `build`, `transfer`, `wellKnownUrl`, `verify`, `session` |
 | `pki.crl` | CRL issuance and verification (RFC 5280 §5). `sign(spec, issuer, opts)` builds and signs a `CertificateList` from a `spec` of `thisUpdate` and `nextUpdate`, an optional `crlNumber`, a `revoked` array (each entry a `serialNumber` and `revocationDate` with an optional `reason` or `invalidityDate`), and an optional `extensions` object (authority key identifier, issuing distribution point, delta-CRL indicator, freshest CRL, authority information access) or an array of pre-encoded Extension DER, with an `issuer` of `{ cert, key }` or `{ name, publicKey, key }`. The signature algorithm is resolved from the issuer key, so RSA (PKCS#1 v1.5 or PSS via `opts.pss`), ECDSA, EdDSA, ML-DSA, SLH-DSA, and the composite arms all sign without a per-algorithm branch. The version is derived from the extension set (v2 when any CRL or entry extension is present, else v1), the outer `signatureAlgorithm` matches `tbsCertList.signature`, an empty revocation list omits the field rather than emitting an empty SEQUENCE, `reasonCode` is an ENUMERATED and `invalidityDate` is always GeneralizedTime, the RFC fixes per-extension criticality, and the produced signature is verified under the issuer key before return. `verify(crl, issuer)` checks a CRL signature through the one path-validation signature engine, algorithm-confusion and EdDSA low-order gates included; handed a certificate rather than a bare key it also asks what only a certificate can answer — that the certificate is the issuer the CRL names, and that its `keyUsage`, when present, asserts `cRLSign` — so a CRL minted under an end-entity certificate of the same CA does not verify as that CA's. `isRevoked(crl, serialNumber, opts)` looks a serial up, and first checks that the CRL is one a serial can be looked up in at all — it is handed a serial and nothing else, so a CRL that speaks for part of its issuer's certificates is refused rather than answered from. A delta CRL lists changes since a base, so an entry recording a release reads as a revocation when read alone; an indirect CRL carries other issuers' entries, whose serials are unrelated to yours; and any other `issuingDistributionPoint` narrows the CRL to one distribution point, one kind of certificate, or a subset of revocation reasons, none of which a serial can be matched against. A CRL speaks for a span as well as a set, so `opts.time` states the instant the question is asked at and a list that has stopped speaking for it — `nextUpdate` passed, `thisUpdate` later, or no `nextUpdate` stated at all — is refused rather than read as a clean bill of health; without `opts.time` the lookup is structural and an absent serial means only that it is not on that list. `pki.path.crlChecker` is the verb for all of them: it is handed the certificate, merges a delta with its base, performs the §6.3.3 correspondence, and decides currency against the material it fetched. Returns DER, or a PEM `X509 CRL` with `opts.pem`; malformed input throws a typed `CrlError`. Parsing stays at `pki.schema.crl.parse` — `sign`, `verify`, `isRevoked` |
 | `pki.key` | Key-material lifecycle (RFC 5958 / RFC 8018). `encrypt(privateKey, password, opts)` wraps a PKCS#8 private key (DER, PEM, or an extractable `CryptoKey`) into an `EncryptedPrivateKeyInfo` under PBES2 (PBKDF2 with AES-CBC-Pad), where `opts` selects the `cipher` (`aes-256-cbc` default, `aes-192-cbc`, `aes-128-cbc`), the `prf` (`hmacWithSHA256` default, SHA-384/512, SHA-1), the `iterations` (default 600000), and the `salt`. The plaintext is validated as PKCS#8 before encryption, a default `prf` and `keyLength` are omitted so the parameters are byte-exact with OpenSSL, and the output is re-parsed before return. `decrypt(encrypted, password, opts)` recovers the inner `PrivateKeyInfo`, re-validated through `pki.schema.pkcs8.parse`: only PBES2 / PBKDF2 / AES-CBC is accepted (PBES1, PBMAC1, and scrypt are refused), the salt and iteration count are bounded before any derivation (`opts.maxIterations` lowers the cap), and a malformed parameter set or wrong-length IV is a distinct typed error. Because a MAC-less PBES2-CBC decrypt must not become a padding oracle (RFC 8018 §8), a wrong password and a valid-pad-but-not-a-key both surface the one uniform `key/decrypt-failed`. `export(key, opts)` and `import(input, opts)` move a private key as PKCS#8 or a public key as SubjectPublicKeyInfo. The key may come from the platform's WebCrypto or from a separately installed copy of this toolkit, and is exported through whichever holds its material; a non-extractable key, or one whose implementation keeps its material out of reach, is refused with that as the reason. Encoding is delegated to WebCrypto, so RSA carries an explicit NULL, EC a named curve, and Ed25519/Ed448/X25519/X448 omit parameters, and an ambiguous RSA or EC import requires `opts.algorithm`. `generate(algorithm, opts)` produces a key pair over RSA, ECDSA/ECDH, the Edwards and Montgomery curves, and the FIPS post-quantum ML-DSA and ML-KEM; `publicFromPrivate(privateKey)` derives the public key. Returns DER or PEM, with a typed `KeyError` on failure. Parsing stays at `pki.schema.pkcs8.parse` — `encrypt`, `decrypt`, `export`, `import`, `generate`, `publicFromPrivate` |

package/lib/attrcert-sign.js

@@ -33,6 +33,9 @@ var x509 = require("./schema-x509");
 var signScheme = require("./sign-scheme");
 var guard = require("./guard-all");
 var pkix = require("./schema-pkix");
+var schema = require("./schema-engine");
+require("./path-validate");   // side-effect: path-validate injects its signature engine into attrcert-verify at load
+var attrcertVerify = require("./attrcert-verify");
 var pkiBuild = require("./pki-build");
 var frameworkError = require("./framework-error");
 
@@ -364,6 +367,21 @@ function _buildAttributes(attrSpec) {
 
 // extensions ::= SEQUENCE OF Extension (RFC 5755 sec. 4.2.9): the recognized object form, or an array
 // of pre-encoded Extension DER. At most one instance of a particular extension OID. Returns a universal
+// RFC 5755 sec. 6 defines two revocation schemes and closes by making them exclusive: "An AC MUST
+// NOT contain both a noRevAvail extension and a 'pointer in AC'." Held over the OIDs an AC ends up
+// carrying, so BOTH extension forms meet it -- the object form and the pre-encoded array form, which
+// is the one that can name a pointer at all. `seen` is the OID-keyed set each branch already builds.
+function _assertRevocationSchemesExclusive(seen) {
+  if (!Object.prototype.hasOwnProperty.call(seen, O("noRevAvail"))) return;
+  var names = Object.keys(REVOCATION_POINTERS);
+  for (var i = 0; i < names.length; i++) {
+    if (Object.prototype.hasOwnProperty.call(seen, names[i])) {
+      throw _err("attrcert/bad-input", "an attribute certificate must not carry both noRevAvail and a " +
+        REVOCATION_POINTERS[names[i]] + " revocation pointer (RFC 5755 sec. 6)");
+    }
+  }
+}
+
 // SEQUENCE OF Extension, or null when none are requested.
 function _buildExtensions(extSpec, aaSpki) {
   if (extSpec == null) return null;
@@ -392,6 +410,7 @@ function _buildExtensions(extSpec, aaSpki) {
       } catch (err) { if (err instanceof AttrCertError) throw err; throw _err("attrcert/bad-input", "pre-encoded " + (oid.name(extnId) || extnId) + " extension value is malformed", err); }
       return b.raw(der);
     });
+    _assertRevocationSchemesExclusive(seenA);
     return b.sequence(exts);
   }
   if (typeof extSpec !== "object") throw _err("attrcert/bad-input", "extensions must be an object or an array of pre-encoded Extension DER");
@@ -406,6 +425,7 @@ function _buildExtensions(extSpec, aaSpki) {
     seen[eOid] = true;
     out.push(_b.ext(eOid, meta.critical, _extensionValue(k, extSpec[k], aaSpki)));
   });
+  _assertRevocationSchemesExclusive(seen);
   if (!out.length) return null;
   return b.sequence(out);
 }
@@ -429,7 +449,10 @@ function _buildExtensions(extSpec, aaSpki) {
  * targetInformation / noRevAvail / aaControls / acProxying / authorityKeyIdentifier, or an array of
  * pre-encoded Extension DER). `issuer` is the signing AA: `{ cert, key }` (the AA certificate DER/PEM
  * and its private key) or `{ name, publicKey, key }` (an explicit issuer DN, AA SPKI DER, and key); an
- * attribute certificate is never self-signed. The signature algorithm is resolved from the AA key (RSA
+ * attribute certificate is never self-signed. RFC 5755 section 6 defines two revocation schemes and
+ * makes them exclusive -- "An AC MUST NOT contain both a noRevAvail extension and a 'pointer in AC'"
+ * -- so `noRevAvail` beside a `crlDistributionPoints` or `authorityInfoAccess` extension is refused,
+ * in the named form and the pre-encoded form alike. The signature algorithm is resolved from the AA key (RSA
  * PKCS#1 v1.5 or PSS, ECDSA, EdDSA, ML-DSA, SLH-DSA, or a composite arm), and the signature is verified
  * under the AA public key before the certificate is returned. Returns DER, or a PEM `ATTRIBUTE
  * CERTIFICATE` with `opts.pem`. Malformed input throws a typed `AttrCertError`; where the spec carries
@@ -517,4 +540,490 @@ function _sign(spec, issuer, opts) {
   });
 }
 
-module.exports = { sign: sign };
+var KNOWN_VERIFY_OPTS = { time: 1, target: 1, revocationStatus: 1 };
+// The two answers a caller can give for RFC 5755 sec. 6, spelled out so a typo is refused instead of
+// read as the safe one. Built without a prototype, so an inherited name cannot answer the lookup.
+var REVOCATION_STATUS = Object.create(null);
+REVOCATION_STATUS.notRevoked = 1;
+REVOCATION_STATUS.revoked = 1;
+var _NAME_SCHEMA = pkix.name(NS);
+
+// A Name DER, read through the one Name reader, so every distinguished name this verb compares is
+// in the shape guard.name.dnEqual takes.
+function _readName(der, what) {
+  try { return schema.walk(_NAME_SCHEMA, asn1.decode(der), NS).result; }
+  catch (e) {
+    if (e instanceof AttrCertError) throw e;
+    throw _err("attrcert/bad-input", what + " is not a readable distinguished name", e);
+  }
+}
+
+// The AC issuer's distinguished name. The parser has already established that issuerName holds
+// exactly one non-empty directoryName [4] (RFC 5755 sec. 4.2.3) and surfaces it as a raw node, so
+// the DN itself is one EXPLICIT unwrap away.
+function _acIssuerName(parsed) {
+  var node = asn1.decode(parsed.issuer.v2Form.issuerName.names[0].bytes);
+  if (!node.children || node.children.length !== 1) {
+    throw _err("attrcert/bad-issuer-name", "the AC issuerName directoryName does not wrap exactly one Name");
+  }
+  return _readName(node.children[0].bytes, "the AC issuer name");
+}
+
+function _coerceAc(input) {
+  return guard.parsed.acceptDerived(input, "attributeCertificate", attrcert.parse, _err,
+    "attrcert/bad-input", "the attribute certificate");
+}
+
+// The AC issuer this caller directly trusts as an AC issuer (RFC 5755 sec. 5, item 4). That is a
+// configuration decision the certificate cannot make for itself, so it is an argument, and an
+// argument this verb refuses to infer.
+function _resolveIssuer(issuer) {
+  if (issuer == null || typeof issuer !== "object" || Buffer.isBuffer(issuer)) {
+    throw _err("attrcert/bad-input", "an issuer { name, publicKey } is required -- RFC 5755 sec. 5 item 4 makes trusting an AC issuer the verifier's own configuration");
+  }
+  guard.identifier.assertKnownKeys(issuer, { name: 1, publicKey: 1 }, _err, "attrcert/bad-input",
+    "the issuer has an unknown key ");
+  if (issuer.publicKey == null) throw _err("attrcert/bad-input", "issuer.publicKey (the AC issuer's SubjectPublicKeyInfo DER) is required");
+  if (issuer.name == null) {
+    throw _err("attrcert/bad-input", "issuer.name (the distinguished name this verifier trusts as an AC issuer) is required");
+  }
+  // Every name form pki.attrcert.sign accepts for the issuing AA is a name this verb has to be able
+  // to trust: a string, an array of RDNs, or raw Name DER. The forms come from the one Name encoder
+  // both sides use, so an AC issued under a multi-RDN AA name is verifiable under that same name.
+  //
+  // The trusted name is compared as a distinguished name, never as a string: RFC 5280 sec. 7.1
+  // identity is not string equality, and guard.name owns that comparison. Encoding the caller's
+  // name and reading it back through the SAME Name reader the parser used puts both sides in the
+  // one shape dnEqual takes.
+  var trustedDer;
+  try { trustedDer = _b.encodeName(issuer.name); }
+  catch (e) {
+    if (e instanceof AttrCertError) throw e;
+    throw _err("attrcert/bad-input", "issuer.name is not a distinguished name", e);
+  }
+  var rdns = _readName(trustedDer, "issuer.name").rdns;
+  // Checked on the decoded name, so every input form is held to it. An empty DN names no issuer, and
+  // RFC 5755 sec. 4.2.3 requires the AC's own issuerName to be a non-empty distinguished name, so an
+  // empty trusted name could never match a conformant AC and would only mask the caller's mistake.
+  if (!rdns.length) {
+    throw _err("attrcert/bad-input", "issuer.name is an empty distinguished name, which names no AC issuer (RFC 5755 sec. 4.2.3)");
+  }
+  return {
+    rdns: rdns,
+    // Copied, never viewed. Signature verification suspends this call, and the signature engine
+    // holds this buffer across that suspension -- a composite arm keeps slices of it and imports
+    // them only after its digest settles. A view would leave the trust key writable for that whole
+    // window, so a caller could hand in an unrelated key of the same length, overwrite it with the
+    // real issuer's while the digest ran, and be told the certificate verified under the key they
+    // named. The verdict answers for the key the call was made with.
+    spki: guard.bytes.snapshot(issuer.publicKey, AttrCertError, "attrcert/bad-input", "issuer.publicKey"),
+  };
+}
+
+// RFC 5755 sec. 4.3.2: a targeted AC is valid only at the servers it names, and "servers not named
+// MUST reject the AC". An absent extension means untargeted, so there is nothing to check.
+//
+// Only the decoded targetName and targetGroup alternatives are compared. Searching the extension's
+// raw bytes for the caller's encoded GeneralName would also match a name nested inside a targetCert,
+// where it identifies the TARGET CERTIFICATE'S ISSUER rather than a target, and would then accept an
+// AC at a server it never named. A match against a targetGroup does count: sec. 4.3.2 targets "named
+// targets or groups", so a verifier presenting its group name is naming itself among them.
+//
+// The caller's GeneralName goes through the shared builder, then back through the SAME GeneralName
+// reader the parser used, so both sides of every comparison are the one decoded shape. Reading it
+// back rather than dereferencing a context node's `content` also keeps this off a field that is
+// null whenever the node is constructed.
+function _callerTarget(target) {
+  return attrcert.readGeneralName(_b.encodeGeneralName(target), "attrcert/bad-input");
+}
+
+// RFC 5280 sec. 7.5: two mailboxes match when the local-part is an exact match AND the host-part
+// matches case-insensitively. The split is on the LAST "@", since a quoted local-part may contain
+// one; a value with no "@" has no host-part to fold and compares exactly.
+function _mailboxEqual(a, bx) {
+  var i = a.lastIndexOf("@"), j = bx.lastIndexOf("@");
+  if (i < 0 || j < 0) return a === bx;
+  return a.slice(0, i) === bx.slice(0, j) &&
+    a.slice(i + 1).toLowerCase() === bx.slice(j + 1).toLowerCase();
+}
+
+// Whether a target the AC names is this verifier, under the matching rule each GeneralName form
+// defines. A form whose rule this build does not implement compares exactly, which can refuse a
+// name a fuller comparison would accept and can never accept one it would refuse.
+function _generalNameMatches(entry, want) {
+  if (!entry || entry.tagNumber !== want.tagNumber) return false;
+  switch (entry.tagNumber) {
+    // RFC 5280 sec. 7.2: "When comparing DNS names for equality, conforming implementations MUST
+    // perform a case-insensitive exact match on the entire DNS name."
+    case 2: return String(entry.value).toLowerCase() === String(want.value).toLowerCase();
+    // sec. 7.5, as above.
+    case 1: return _mailboxEqual(String(entry.value), String(want.value));
+    // A directoryName is a distinguished name, and sec. 7.1 identity is not string equality, so it
+    // goes through the one DN comparator rather than comparing the printed form.
+    case 4:
+      return !!(entry.value && want.value) &&
+        guard.name.dnEqual(entry.value.rdns, want.value.rdns, _err, "attrcert/bad-input", "the target name");
+    // sec. 7.4 makes a URI comparison a full RFC 3987 normalization: percent-encoding, path
+    // segments and scheme-based rules, not merely lowercasing the scheme and host. A partial
+    // normalization would be a guess that could match a URI it should not, so the encoded value is
+    // compared as it stands. Re-open condition: an RFC 3987 normalizer in the toolkit.
+    default:
+      if (Buffer.isBuffer(entry.value) && Buffer.isBuffer(want.value)) return entry.value.equals(want.value);
+      if (typeof entry.value === "string" && typeof want.value === "string") return entry.value === want.value;
+      // A form whose decoded value is neither (otherName, ediPartyName, x400Address) has no
+      // comparison here; the caller is told so rather than given a silent mismatch.
+      return null;
+  }
+}
+
+// `want` is the caller's target already decoded, so this runs against the target the call was made
+// with. See _fixVerifyOptions.
+function _checkTargeting(ac, want) {
+  var ext = null;
+  for (var i = 0; i < ac.extensions.length; i++) {
+    if (ac.extensions[i].name === "targetInformation") ext = ac.extensions[i];
+  }
+  if (!ext) return { checked: true, ok: true };
+  if (want === undefined) {
+    return { checked: false, ok: false,
+      reason: "this attribute certificate is targeted, and no opts.target names this verifier (RFC 5755 sec. 4.3.2)" };
+  }
+  // The extension's syntax is a SEQUENCE OF Targets, and its groups are FLATTENED rather than
+  // required one by one. RFC 5755 sec. 4.3.2: "If more than one Targets element is found in an AC,
+  // the extension MUST be treated as if all Target elements had been found within one Targets
+  // element." An issuer conforming to the same paragraph produces only one group anyway, so the
+  // nesting carries no meaning to honor; requiring a match in every group would refuse ACs the
+  // paragraph says to accept.
+  var groups = ext.decoded || [];
+  // sec. 4.3.2 defines the check exactly: it "passes if the current server (recipient) is one of the
+  // targetName fields in the Targets SEQUENCE, or if the current server is a member of one of the
+  // targetGroup fields". The third arm is excluded by the same section -- "The targetCert CHOICE
+  // within the Target structure is only present to allow future compatibility with [X.509-2000] and
+  // MUST NOT be used" -- and the names inside it identify a certificate, not a target.
+  //
+  // An AC using it is refused before any match is considered, the same way sec. 6's "An AC MUST NOT
+  // contain both a noRevAvail extension and a 'pointer in AC'" is enforced here. Both are MUST NOTs
+  // the issuer broke, and a certificate that breaks its own profile is refused rather than partly
+  // honored: passing it because some OTHER entry happened to match would resolve the violation in
+  // the accepting direction, and would leave the verdict depending on which entries an attacker
+  // chose to include alongside the forbidden one. The targets check itself never runs, so its slot
+  // says so.
+  for (var g0 = 0; g0 < groups.length; g0++) {
+    for (var t0 = 0; t0 < groups[g0].length; t0++) {
+      if (groups[g0][t0].kind !== "targetCert") continue;
+      return { checked: false, ok: false,
+        reason: "this attribute certificate carries a targetCert target, which RFC 5755 sec. 4.3.2 says MUST NOT be used, so the targeting check did not run" };
+    }
+  }
+
+  var uncomparable = null;
+  for (var g = 0; g < groups.length; g++) {
+    for (var t = 0; t < groups[g].length; t++) {
+      var entry = groups[g][t];
+      if (entry.kind !== "targetName" && entry.kind !== "targetGroup") continue;
+      var m = _generalNameMatches(entry.name, want);
+      if (m === true) return { checked: true, ok: true };
+      if (m === null) uncomparable = entry.name && entry.name.tagNumber;
+    }
+  }
+  // A target this build cannot compare leaves the check unperformed, which cannot read as a pass.
+  if (uncomparable !== null) {
+    return { checked: false, ok: false,
+      reason: "this attribute certificate names a target in a GeneralName form ([" + uncomparable +
+        "]) this verifier does not compare, so the RFC 5755 sec. 4.3.2 check did not run" };
+  }
+  return { checked: true, ok: false,
+    reason: "this attribute certificate does not name this verifier among its targets (RFC 5755 sec. 4.3.2)" };
+}
+
+// The critical extensions this verb SUPPORTS, by OID. RFC 5755 sec. 5 defines support in two parts:
+// the verifier must be able to parse the value, AND "where the extension value causes the AC to be
+// rejected, the AC verifier MUST reject the AC". Parsing alone satisfies only the first, so an
+// extension whose constraints this verb never evaluates cannot be called supported however cleanly
+// it decodes.
+//
+//   targetInformation -- evaluated, by the sec. 4.3.2 check below.
+//   acAuditIdentity   -- sec. 4.3.1 is an audit/logging identity and states no rule that rejects an
+//                        AC, so there is no second part to satisfy. It rides out on the verdict's
+//                        `extensions` for the logging the section asks for.
+//
+// Everything else critical is refused, including extensions this build parses but does not act on:
+// aaControls (sec. 7.4) constrains what an AA may delegate and acProxying (sec. 7.2) constrains
+// proxy use, and an unevaluated constraint is exactly what item 7 exists to stop. A critical
+// extension defined in future defaults to refused, which is the safe direction.
+var SUPPORTED_CRITICAL = {};
+SUPPORTED_CRITICAL[O("targetInformation")] = 1;
+SUPPORTED_CRITICAL[O("acAuditIdentity")] = 1;
+
+function _unsupportedCritical(ac) {
+  for (var i = 0; i < ac.extensions.length; i++) {
+    var e = ac.extensions[i];
+    if (e.critical !== true) continue;
+    // Own-property membership, so an extension OID that happens to name something on Object.prototype
+    // cannot read as supported.
+    if (!Object.prototype.hasOwnProperty.call(SUPPORTED_CRITICAL, e.oid)) return e.oid;
+    // A supported OID whose value this build could not interpret is still unusable.
+    if (e.decoded === null || e.decoded === undefined || e.decoded.opaque === true) return e.oid;
+  }
+  return null;
+}
+
+/**
+ * @primitive pki.attrcert.verify
+ * @signature pki.attrcert.verify(ac, issuer, opts) -> Promise<{ verified, signatureValid, validityChecked, targetingChecked, revocationChecked, noRevAvail, holderBindingChecked, issuerPathChecked, holder, issuer, attributes, extensions, notBefore, notAfter, serialNumberHex, reason }>
+ * @since 0.5.15
+ * @status stable
+ * @spec RFC 5755 sec. 5
+ * @defends attribute-certificate-forgery (CWE-347)
+ * @related pki.attrcert.sign, pki.path.validate, pki.schema.attrcert.parse
+ *
+ * Verify an RFC 5755 attribute certificate. An AC carries privilege attributes -- a role, a group, a
+ * clearance -- so a consumer that reads them without this grants privileges on unauthenticated
+ * input. `ac` is a DER `Buffer`, a PEM string, or a parsed attribute certificate; `issuer` is
+ * `{ name, publicKey }`, the AC issuer this verifier trusts as an AC issuer, which section 5 item 4
+ * makes the verifier's own configuration and this verb therefore refuses to infer from the AC.
+ * `issuer.name` takes every form `pki.attrcert.sign` accepts for the issuing AA -- a string, an
+ * array of RDNs, or raw `Name` DER -- and is compared as a distinguished name (RFC 5280 section
+ * 7.1), so an AC issued under a multi-RDN authority name is verifiable under that same name.
+ *
+ * Both options are read at the call, before signature verification suspends it, so a caller that
+ * reuses or rewrites its options object -- including calling `setTime` on the `Date` it passed in --
+ * cannot change the verdict that call returns.
+ *
+ * The checks it performs are section 5's items 2, 4, 5, 6 and 7: the signature over the exact
+ * `AttributeCertificateInfo` bytes through the one path-validation signature engine; the issuer
+ * being the one named; the evaluation instant lying within the validity, where equality with either
+ * bound succeeds as the section states; the targeting rule of section 4.3.2, where an AC naming
+ * targets is refused at a verifier it does not name; and rejection of any critical extension this
+ * verb does not process. Section 5 defines support as parsing the value AND rejecting where the
+ * value would reject, so an extension parsed but never evaluated is not supported: targeting is
+ * processed and an audit identity states no rule that rejects, while `aaControls` and `acProxying`
+ * carry constraints this verb does not evaluate, so a critical one is refused. A critical extension
+ * defined in future defaults to refused. The verdict carries `extensions` so an audit identity
+ * reaches the caller for the logging section 4.3.1 asks for.
+ *
+ * Targeting compares `opts.target` against the `targetName` and `targetGroup` alternatives only,
+ * under each GeneralName form's own matching rule: a dNSName folds case across the whole name
+ * (RFC 5280 sec. 7.2), a mailbox matches its local-part exactly and its host-part case-insensitively
+ * (sec. 7.5), and a directoryName goes through the same distinguished-name comparison the rest of
+ * the toolkit uses (sec. 7.1). A URI compares as encoded, because sec. 7.4 makes URI equality a full
+ * RFC 3987 normalization -- percent-encoding, path segments and scheme-based rules -- and a partial
+ * one could match a URI it should not. A form with no comparison here (otherName, ediPartyName,
+ * x400Address) leaves `targetingChecked: false` and never a pass. Every one of those limits can
+ * refuse a target a fuller comparison would accept, and none can accept one it would refuse.
+ * Re-open condition: an RFC 3987 normalizer, at which point URIs compare under sec. 7.4.
+ *
+ * The third `Target` alternative, `targetCert`, is one section 4.3.2 says "MUST NOT be used", so an
+ * attribute certificate carrying one is refused before any match is considered, with
+ * `targetingChecked: false`. A match on some other entry does not rescue it: the issuer broke a MUST
+ * NOT of its own profile, and letting the verdict turn on which entries rode alongside the forbidden
+ * one would leave the outcome to whoever assembled the certificate.
+ *
+ * Revocation is section 6, outside the seven. This verb implements that section's "never revoke"
+ * scheme, which AC users MUST support: it holds no revocation evidence and follows no pointer out
+ * of the certificate. The section states the consequence -- "If only the 'never revoke' scheme is
+ * supported, then all ACs that do not contain a noRevAvail extension, MUST be rejected" -- because
+ * an issuer that omits noRevAvail is stating that revocation status checks are supported, and a
+ * verdict that skipped one would grant privileges the issuer expected to be able to withdraw. So an
+ * AC carrying `noRevAvail` verifies with `revocationChecked: true` and `noRevAvail: true`, and one
+ * without it is refused unless the caller supplies `opts.revocationStatus`. A caller running the
+ * section's "pointer in AC" scheme reads the certificate's own `crlDistributionPoints` /
+ * `authorityInfoAccess` from the verdict's `extensions`, establishes the status, and passes it back.
+ *
+ * Items 1 and 3, and the issuer path in item 2, need certificates this verb is not given: the
+ * holder's own public-key certificate and its chain, the AC issuer's chain, and the section 4.5
+ * profile of the issuer's certificate. Run those through `pki.path.validate` with the certificates
+ * you hold. The verdict reports them as `holderBindingChecked: false` and `issuerPathChecked:
+ * false` rather than leaving their absence to read as a pass, and `verified` never means more than
+ * the checks whose slots are true. Re-open condition: when a caller can pass the holder and issuer
+ * certificates, both become checks this verb performs and both slots follow the arguments.
+ *
+ * @opts
+ *   time    the instant to evaluate the AC at. Omitting it leaves section 5 item 5 unasked, which
+ *           reports `validityChecked: false` and never `verified: true`.
+ *   target  a GeneralName naming this verifier, for the section 4.3.2 targeting check.
+ *   revocationStatus
+ *           `"notRevoked"` or `"revoked"`, the status the caller established for this AC through
+ *           the section 6 "pointer in AC" scheme. Supplying it answers section 6 for an AC that
+ *           carries no `noRevAvail`; omitting it leaves such an AC refused.
+ *
+ * @example
+ *   var pair = await pki.key.generate("Ed25519");
+ *   var aaSpki = await pki.key.export(pair.publicKey);
+ *   var aaKey = await pki.key.export(pair.privateKey);
+ *   var acDer = await pki.attrcert.sign({
+ *     holder: { entityName: { directoryName: "CN=Alice" } },
+ *     notBeforeTime: new Date("2026-01-01T00:00:00Z"),
+ *     notAfterTime: new Date("2027-01-01T00:00:00Z"),
+ *     attributes: { role: { roleName: { uniformResourceIdentifier: "urn:role:admin" } } },
+ *     // RFC 5755 sec. 6: the issuer states no revocation information will exist for this AC.
+ *     extensions: { noRevAvail: true },
+ *   }, { name: "CN=Example AA", publicKey: aaSpki, key: aaKey });
+ *   var r = await pki.attrcert.verify(acDer, { name: "CN=Example AA", publicKey: aaSpki },
+ *     { time: new Date("2026-06-01T00:00:00Z") });
+ *   r.verified;      // true when every check whose slot is true passed
+ *   r.attributes;    // the privileges, re-derived from the signed bytes
+ */
+function verify(ac, issuer, opts) {
+  return guard.async.deferred(function () { return _verify(ac, issuer, opts); });
+}
+// Every caller-owned value the verdict depends on, read HERE and reduced to a value the caller no
+// longer reaches: the instant rather than the Date (a Date is mutable through setTime even when the
+// property is never reassigned), and the target already encoded and decoded rather than the object.
+// Signature verification suspends this call for at least a turn, and an option re-read after it
+// resumes answers for whatever the caller last wrote, so a caller could hand in an expired instant,
+// replace it while WebCrypto works, and receive `verified: true`. The reduction is returned rather
+// than performed at each use, so reading an option late is not an available mistake.
+function _fixVerifyOptions(opts) {
+  var o = guard.identifier.optionsObject(opts, _err, "attrcert/bad-input", "pki.attrcert.verify options");
+  guard.identifier.assertKnownKeys(o, KNOWN_VERIFY_OPTS, _err, "attrcert/bad-input",
+    "pki.attrcert.verify has an unknown option ");
+  var at = null;
+  if (o.time !== undefined) {
+    guard.time.assertValid(o.time, _err, "attrcert/bad-input", "pki.attrcert.verify opts.time");
+    at = guard.time.instantOf(o.time);
+  }
+  var revocationStatus = null;
+  if (o.revocationStatus !== undefined) {
+    if (typeof o.revocationStatus !== "string" ||
+      !Object.prototype.hasOwnProperty.call(REVOCATION_STATUS, o.revocationStatus)) {
+      throw _err("attrcert/bad-input", 'pki.attrcert.verify opts.revocationStatus must be "notRevoked" or "revoked"');
+    }
+    revocationStatus = o.revocationStatus;
+  }
+  // A supplied target is encoded and read back whether or not the AC turns out to be targeted, so a
+  // malformed one is refused at the call that supplied it.
+  return {
+    at: at, revocationStatus: revocationStatus,
+    target: o.target === undefined ? undefined : _callerTarget(o.target),
+  };
+}
+
+// RFC 5755 sec. 6 "pointer in AC": "ACs may 'point' to sources of revocation status information,
+// using either an authorityInfoAccess extension or a crlDistributionPoints extension within the AC."
+// Named by OID, since the OID is what an issuer signs and a display name is not.
+var REVOCATION_POINTERS = Object.create(null);
+REVOCATION_POINTERS[O("cRLDistributionPoints")] = "crlDistributionPoints";
+REVOCATION_POINTERS[O("authorityInfoAccess")] = "authorityInfoAccess";
+
+// The two revocation schemes an AC declares, read from its extensions. RFC 5755 sec. 4.3.6 / sec. 6:
+// noRevAvail is the issuer stating that no revocation information will ever be made available for
+// this AC, and it is a bare NULL, so its presence is the whole content.
+function _revocationScheme(ac) {
+  var out = { noRevAvail: false, pointer: null };
+  for (var i = 0; i < ac.extensions.length; i++) {
+    var e = ac.extensions[i];
+    if (e.name === "noRevAvail") out.noRevAvail = true;
+    var p = REVOCATION_POINTERS[e.oid];
+    if (p !== undefined && Object.prototype.hasOwnProperty.call(REVOCATION_POINTERS, e.oid)) out.pointer = p;
+  }
+  return out;
+}
+
+function _verify(ac, issuer, opts) {
+  var fixed = _fixVerifyOptions(opts);
+  var parsed = _coerceAc(ac);
+  var trust = _resolveIssuer(issuer);
+
+  var acIssuer = _acIssuerName(parsed);
+  var result = {
+    holder: parsed.holder,
+    issuer: acIssuer,
+    attributes: parsed.attributes,
+    // Carried so a caller can act on what rode along: sec. 4.3.1 asks that an audit identity be
+    // used for audit and logging, which it cannot be if the verdict drops it.
+    extensions: parsed.extensions,
+    notBefore: parsed.validity.notBeforeTime,
+    notAfter: parsed.validity.notAfterTime,
+    serialNumberHex: parsed.serialNumberHex,
+    signatureValid: false,
+    validityChecked: false,
+    targetingChecked: false,
+    revocationChecked: false,
+    noRevAvail: false,
+    holderBindingChecked: false,   // item 1 needs the holder's certificate, which this verb is not given
+    issuerPathChecked: false,      // items 2 and 3 need the issuer's chain, likewise
+    verified: false,
+    reason: undefined,
+  };
+
+  // The signature runs first so `signatureValid` is answered even when a later gate refuses: an
+  // operator reading an out-of-window verdict still learns whether the bytes were authentic.
+  return Promise.resolve(attrcertVerify.verifyAcSignature(parsed, trust.spki)).then(function (sigOk) {
+    result.signatureValid = sigOk === true;
+    var fail = function (reason) { result.reason = reason; return result; };
+    if (!result.signatureValid) return fail("the signature does not verify under the issuer public key");
+
+    // Item 4: the caller trusts a named AC issuer, and this AC must be the one they named.
+    if (!guard.name.dnEqual(acIssuer.rdns, trust.rdns, _err,
+      "attrcert/bad-input", "the AC issuer")) {
+      return fail("this attribute certificate names issuer " + JSON.stringify(acIssuer.dn) +
+        ", which is not the AC issuer this verifier trusts");
+    }
+
+    // Item 7, before the fields are read: an unsupported critical extension makes the whole AC
+    // unusable, so a caller must not act on attributes carried beside one.
+    var badExt = _unsupportedCritical(parsed);
+    if (badExt) return fail("this attribute certificate carries an unsupported critical extension (" + badExt + "), which RFC 5755 sec. 5 item 7 requires be rejected");
+
+    // Item 6.
+    var targeting = _checkTargeting(parsed, fixed.target);
+    result.targetingChecked = targeting.checked;
+    if (!targeting.ok) return fail(targeting.reason);
+
+    // Item 5. An absent instant asks nothing, which cannot read as a pass.
+    if (fixed.at === null) {
+      return fail("no opts.time was supplied, so RFC 5755 sec. 5 item 5 (the evaluation instant lies within the validity) went unasked");
+    }
+    result.validityChecked = true;
+    // "If the evaluation time is equal to either notBeforeTime or notAfterTime, then the AC is
+    // timely and this check succeeds" -- both bounds are inclusive.
+    if (fixed.at < guard.time.instantOf(result.notBefore) || fixed.at > guard.time.instantOf(result.notAfter)) {
+      return fail("the evaluation instant lies outside this attribute certificate's validity");
+    }
+
+    // RFC 5755 sec. 6. This verb implements the "never revoke" scheme: it holds no revocation
+    // evidence of its own and follows no pointer out of the certificate. The section says exactly
+    // what that obliges -- "If only the 'never revoke' scheme is supported, then all ACs that do not
+    // contain a noRevAvail extension, MUST be rejected" -- because where noRevAvail is absent "the
+    // AC issuer is implicitly stating that revocation status checks are supported", so a verdict
+    // that skipped one would grant privileges the issuer expected to be able to withdraw. A caller
+    // who has established the status passes it as opts.revocationStatus; the AC's own
+    // crlDistributionPoints / authorityInfoAccess pointers ride out on the verdict's `extensions`
+    // for them to follow.
+    //
+    // That status is accepted whether or not the AC carries a pointer, because the section closes by
+    // saying where it may come from: "An AC verifier MAY use any source for AC revocation status
+    // information." Requiring a pointer in the certificate would refuse a verifier who obtained the
+    // status from a directory, an out-of-band CRL, or a local record, all of which that sentence
+    // permits. The verdict keeps the two apart: `noRevAvail` says the issuer declared none would
+    // exist, and its absence beside `revocationChecked: true` says the caller supplied one.
+    var scheme = _revocationScheme(parsed);
+    result.noRevAvail = scheme.noRevAvail;
+    // The two schemes are alternatives, and the section closes by saying so: "An AC MUST NOT contain
+    // both a noRevAvail extension and a 'pointer in AC'." An AC carrying both tells the verifier two
+    // different things about its own revocation, and reading the never-revoke claim as settling the
+    // question would resolve that contradiction in the accepting direction. It is refused whichever
+    // way the caller answers, since the certificate itself is the thing that is wrong.
+    if (scheme.noRevAvail && scheme.pointer) {
+      return fail("this attribute certificate carries both noRevAvail and a " + scheme.pointer +
+        " revocation pointer, which RFC 5755 sec. 6 says an AC MUST NOT do");
+    }
+    if (fixed.revocationStatus !== null) {
+      result.revocationChecked = true;
+      if (fixed.revocationStatus === "revoked") {
+        return fail("this attribute certificate is revoked, as opts.revocationStatus reports");
+      }
+    } else if (result.noRevAvail) {
+      // The issuer has stated no revocation information will exist, so there is no status to obtain.
+      result.revocationChecked = true;
+    } else {
+      return fail("this attribute certificate carries no noRevAvail extension, so its issuer supports revocation status checks and RFC 5755 sec. 6 requires one; establish the status from the certificate's own pointers and pass it as opts.revocationStatus");
+    }
+
+    result.verified = true;
+    return result;
+  });
+}
+
+module.exports = { sign: sign, verify: verify };

package/lib/attrcert-verify.js

@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: Apache-2.0
+// Copyright (c) blamejs contributors
+"use strict";
+//
+// @internal -- the RFC 5755 attribute-certificate signature seam, shared by pki.attrcert.verify and
+// by any path that accepts an inbound AC. The slot, the wiring assertion and the octet-alignment
+// refusal are the shared seam (lib/verify-seam.js); what is domain-specific is the error class and
+// the byte range the signature covers. It is not wired into index.js and is reached only by require.
+
+var frameworkError = require("./framework-error");
+var seam = require("./verify-seam");
+
+var _seam = seam.makeSeam("attrcert-verify", frameworkError.AttrCertError, "attrcert/bad-input");
+
+// Verify a parsed attribute certificate's signature over its exact AttributeCertificateInfo bytes
+// under the AC issuer's SubjectPublicKeyInfo DER (RFC 5755 sec. 5, item 2).
+function verifyAcSignature(ac, spkiBytes) {
+  return _seam.verify(ac.signatureAlgorithm, ac.signatureValue, spkiBytes, ac.tbsBytes);
+}
+
+module.exports = { setEngine: _seam.setEngine, verifyAcSignature: verifyAcSignature };

package/lib/crl-verify.js

@@ -4,30 +4,21 @@
 //
 // @internal -- the single CRL signature-verify seam, shared by pki.path.crlChecker and pki.crl.verify
 // so both route through one signature engine (algorithm-confusion + EdDSA low-order + composite
-// gates) and no second, weaker CRL verifier can drift. path-validate owns that engine
-// (_verifyWithSpki) and injects it here at its module load (setEngine). The seam lives in this
-// internal module, not on path-validate's module.exports, which keeps it off the public pki.path
-// surface: it takes the path-internal SubjectPublicKeyInfo bytes, not a documented issuer shape.
-// It is not wired into index.js and is reached only by require.
+// gates) and no second, weaker CRL verifier can drift. The slot, the wiring assertion and the
+// octet-alignment refusal are the shared seam (lib/verify-seam.js). The seam lives in this internal
+// module, not on path-validate's module.exports, which keeps it off the public pki.path surface: it
+// takes the path-internal SubjectPublicKeyInfo bytes, not a documented issuer shape. It is not
+// wired into index.js and is reached only by require.
 
-var guard = require("./guard-all");
 var frameworkError = require("./framework-error");
+var seam = require("./verify-seam");
 
-var CrlError = frameworkError.CrlError;
-var _engine = null;   // path-validate's _verifyWithSpki, injected at path-validate's module load via setEngine.
+var _seam = seam.makeSeam("crl-verify", frameworkError.CrlError, "crl/bad-input");
 
-function setEngine(verifyWithSpki) { _engine = verifyWithSpki; }
-
-// Verify a parsed CRL's signature over its raw tbsCertList bytes under the issuer SubjectPublicKeyInfo DER.
-// Fail-closed to false on a non-octet-aligned signature or any engine fault (the engine never throws out).
+// Verify a parsed CRL's signature over its raw tbsCertList bytes under the issuer
+// SubjectPublicKeyInfo DER.
 function verifyCrlSignature(crl, spkiBytes) {
-  // pki.crl.sign requires path-validate for the injection side-effect, so the engine is set on every
-  // route that reaches here through the public verb. A future internal consumer that requires this
-  // module without it would otherwise call null and surface a raw TypeError out of a verify, which
-  // names neither the defect nor a verdict, so the wiring is asserted rather than assumed.
-  if (_engine == null) throw new CrlError("crl/bad-input", "the crl-verify signature engine is not initialized (require pki before use)");
-  if (!guard.crypto.isOctetAligned(crl.signatureValue)) return Promise.resolve(false);   // non-octet-aligned signature
-  return _engine(crl.signatureAlgorithm, crl.signatureValue.bytes, spkiBytes, crl.tbsBytes);
+  return _seam.verify(crl.signatureAlgorithm, crl.signatureValue, spkiBytes, crl.tbsBytes);
 }
 
-module.exports = { setEngine: setEngine, verifyCrlSignature: verifyCrlSignature };
+module.exports = { setEngine: _seam.setEngine, verifyCrlSignature: verifyCrlSignature };

package/lib/crmf-sign.js

@@ -32,6 +32,8 @@ var pkix = require("./schema-pkix");
 var pkiBuild = require("./pki-build");
 var frameworkError = require("./framework-error");
 var guard = require("./guard-all");
+require("./path-validate");   // side-effect: path-validate injects its signature engine into crmf-verify at load
+var crmfVerify = require("./crmf-verify");
 
 var CrmfError = frameworkError.CrmfError;
 var b = asn1.build;
@@ -310,4 +312,126 @@ function _build(spec, key, opts) {
  */
 function buildCertTemplate(template) { return _encodeCertTemplate(template, { revocation: true }).der; }
 
-module.exports = { build: build, buildCertTemplate: buildCertTemplate };
+function _coerceMessages(input) {
+  return guard.parsed.acceptDerived(input, "crmf", crmf.parse, _err, "crmf/bad-input", "the certificate request messages");
+}
+
+// One CertReqMsg's proof of possession, reduced to a verdict. Every return names a method and
+// reports the requested identity, so a refusal is as informative as an acceptance.
+function _verifyOne(msg) {
+  var t = msg.certReq && msg.certReq.certTemplate;
+  var base = {
+    certReqId: msg.certReq && msg.certReq.certReqId,
+    subject: (t && t.subject) || null,
+    subjectBound: false,
+    publicKey: (t && t.publicKey && t.publicKey.bytes) || null,
+  };
+  function settle(extra) { return Promise.resolve(Object.assign({}, base, extra)); }
+
+  var popo = msg.popo;
+  if (popo == null) {
+    return settle({ verified: false, method: null, cryptographicallyVerified: false,
+      reason: "the request carries no proof of possession" });
+  }
+  if (popo.type === "raVerified") {
+    // sec. 4: an assertion by the RA that it checked possession out of band. It is not a proof and
+    // must not read as one; a caller that trusts its RA opts in by reading `method`.
+    return settle({ verified: false, method: "raVerified", cryptographicallyVerified: false,
+      reason: "raVerified asserts the RA checked possession out of band -- this is not a proof and cannot be verified from the message" });
+  }
+  if (popo.type !== "signature") {
+    // keyEncipherment / keyAgreement complete over a later protocol exchange (a challenge the
+    // verifier does not hold) or need the CA's decryption key, so no verdict is available here.
+    return settle({ verified: false, method: popo.type, cryptographicallyVerified: false,
+      reason: "a " + popo.type + " proof of possession completes over an exchange this verifier does not hold (RFC 4211 sec. 4.2, 4.3)" });
+  }
+
+  // Which bytes the signature covers is fixed by whether poposkInput is present: the DER of
+  // poposkInput when it is, the DER of certReq when it is not (RFC 4211 sec. 4.1, and the ASN.1
+  // module on p.33 -- sec. 4.1's case-3 prose says "certificate template" where the field
+  // definition and the module both say certReq).
+  //
+  // The three conformance rules that decide which of those is legitimate are enforced ONE layer
+  // down, at parse: poposkInput MUST be omitted exactly when the template carries both subject and
+  // publicKey, and poposkInput.publicKey MUST equal the template's (schema-crmf.js, the CertReqMsg
+  // build). A message breaking either never reaches this function, and re-checking here would add
+  // a branch no input can take while implying the parser might let one through.
+  var pin = popo.poposkInput;
+  var preimage = pin ? pin.signedBytes : msg.certReq.certReqBytes;
+  // The key possession is proven for is the one inside the preimage. With poposkInput that is its
+  // own publicKey; sec. 4.1 requires the template to carry the same value, and the parser enforces
+  // that whenever the template has one at all. A template that omits it entirely still parses (the
+  // equality rule has nothing to compare), so reading the template here would report null for a key
+  // whose possession was just proven.
+  var spki = pin ? pin.publicKey : base.publicKey;
+  // Which fields the verdict may report follows from which bytes were signed. The certReq preimage
+  // is the whole CertRequest, so the template's subject rides with it. The poposkInput preimage
+  // covers the key and the authInfo sender and never the template, so a subject sitting in the
+  // message alongside it is unsigned: reporting it beside `verified: true` would let a CA issue a
+  // name the requester proved nothing about. It is withheld, and `subjectBound` says so rather than
+  // leaving the absence to look like a request that named no subject.
+  var bound = !pin;
+  return crmfVerify.verifyPopSignature(popo, spki, preimage).then(function (ok) {
+    return Object.assign({}, base, {
+      verified: ok === true, method: "signature", cryptographicallyVerified: ok === true,
+      subject: bound ? base.subject : null,
+      subjectBound: bound,
+      publicKey: spki || null,
+      reason: ok === true ? undefined : "the proof-of-possession signature does not verify under the requested public key",
+    });
+  });
+}
+
+/**
+ * @primitive pki.crmf.verifyPop
+ * @signature pki.crmf.verifyPop(messages) -> Promise<{ verified, messages: [{ verified, method, cryptographicallyVerified, certReqId, subject, subjectBound, publicKey, reason }] }>
+ * @since 0.5.14
+ * @status stable
+ * @spec RFC 4211 sec. 4.1
+ * @defends crmf-proof-of-possession-bypass (CWE-347)
+ * @related pki.crmf.build, pki.csr.verify, pki.schema.crmf.parse
+ *
+ * Verify the proof of possession on each `CertReqMsg` in a `CertReqMessages`. `messages` is a DER
+ * `Buffer` or a parsed result. A CA or RA that issues without this certifies a key the requester
+ * may not hold. One verdict is returned per message, in order, and the top-level `verified` is true
+ * only when every message carried a proof that verified.
+ *
+ * For the `signature` proof the covered bytes are the ones RFC 4211 names: the DER of `poposkInput`
+ * when that field is present, and the DER of `certReq` when it is absent. Two conformance rules ride
+ * with it, both refusals rather than warnings, because each lets a certificate be issued for
+ * something nobody signed: `poposkInput` MUST be omitted exactly when the template carries both
+ * subject and public key (its preimage covers the key and the sender, never the subject), and
+ * `poposkInput.publicKey` MUST be exactly the template's public key (sec. 4.1). Verification
+ * composes the one path-validation signature engine, with the same algorithm-confusion (RFC 9814
+ * sec. 4) and EdDSA low-order-point gates.
+ *
+ * The other proofs are reported, never guessed. `raVerified` is an RA's out-of-band assertion, so it
+ * returns `verified: false` with `method: "raVerified"` and a caller who trusts that RA opts in by
+ * reading `method`. `keyEncipherment` and `keyAgreement` complete over a later protocol exchange, or
+ * need the CA's decryption key, so they return `verified: false` naming the arm.
+ *
+ * Each verdict carries what the verified preimage covers, so a CA issues from what was checked.
+ * `publicKey` is the key possession was proven for. `subject` is the requested name when the
+ * preimage was the `certReq`, which covers the whole template; when the preimage was `poposkInput`
+ * it covers the key and the sender alone, so any subject in the message is unsigned and is withheld
+ * with `subjectBound: false`. Bind the name by other means before issuing in that case.
+ *
+ * @example
+ *   var pair = await pki.key.generate("Ed25519");
+ *   var spki = await pki.key.export(pair.publicKey);
+ *   var pkcs8 = await pki.key.export(pair.privateKey);
+ *   var req = await pki.crmf.build({ certReqId: 1n,
+ *     certTemplate: { subject: "device-42", publicKey: spki } }, { key: pkcs8 });   // a bare string is the commonName VALUE
+ *   var r = await pki.crmf.verifyPop(req);
+ *   r.verified;                    // true
+ *   r.messages[0].method;          // "signature"
+ */
+function verifyPop(messages) { return guard.async.deferred(function () { return _verifyPop(messages); }); }
+function _verifyPop(messages) {
+  var parsed = _coerceMessages(messages);
+  return Promise.all(parsed.messages.map(_verifyOne)).then(function (out) {
+    return { verified: out.length > 0 && out.every(function (m) { return m.verified === true; }), messages: out };
+  });
+}
+
+module.exports = { build: build, buildCertTemplate: buildCertTemplate, verifyPop: verifyPop };

package/lib/crmf-verify.js

@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: Apache-2.0
+// Copyright (c) blamejs contributors
+"use strict";
+//
+// @internal -- the single RFC 4211 proof-of-possession signature seam for an INBOUND CertReqMsg,
+// shared by pki.crmf.verifyPop and by every enrollment path that accepts one. The slot, the wiring
+// assertion and the octet-alignment refusal are the shared seam (lib/verify-seam.js); what is
+// domain-specific is the error class and which bytes the signature covers. It is not wired into
+// index.js and is reached only by require.
+
+var frameworkError = require("./framework-error");
+var seam = require("./verify-seam");
+
+var _seam = seam.makeSeam("crmf-verify", frameworkError.CrmfError, "crmf/bad-input");
+
+// Verify one CertReqMsg's POPOSigningKey signature over `preimage` under `spkiBytes`.
+//
+// `preimage` is chosen by the caller from the two the RFC defines, because the choice is a
+// conformance rule about the message rather than a property of the signature: the DER of
+// poposkInput when that field is present, and the DER of `CertReqMsg certReq` when it is absent
+// (RFC 4211 sec. 4.1 and the ASN.1 module on p.33).
+function verifyPopSignature(popo, spkiBytes, preimage) {
+  return _seam.verify(popo.algorithmIdentifier, popo.signature, spkiBytes, preimage);
+}
+
+module.exports = { setEngine: _seam.setEngine, verifyPopSignature: verifyPopSignature };

package/lib/csr-sign.js

@@ -219,7 +219,8 @@ function _coerceCsr(request) {
  *   var pair = await pki.key.generate("Ed25519");
  *   var spki = await pki.key.export(pair.publicKey);
  *   var pkcs8 = await pki.key.export(pair.privateKey);
- *   var req = await pki.csr.sign({ subject: "CN=device-42", subjectPublicKey: spki }, { key: pkcs8 });
+ *   // A bare string is the commonName VALUE, so this asks for CN=device-42.
+ *   var req = await pki.csr.sign({ subject: "device-42", subjectPublicKey: spki }, { key: pkcs8 });
  *   var r = await pki.csr.verify(req);
  *   // Issue from r.subject / r.subjectPublicKeyInfo / r.attributes, which are the verified fields.
  *   var issued = r.verified

package/lib/csr-verify.js

@@ -4,41 +4,24 @@
 //
 // @internal -- the single PKCS#10 proof-of-possession signature seam for an INBOUND request, shared
 // by pki.csr.verify and by every enrollment path that accepts one, so all of them route through one
-// signature engine (algorithm-confusion + EdDSA low-order + composite gates) and no second, weaker
-// verifier of untrusted requests can drift. The producing side runs its own check over what it just
-// signed (pki-build's assertSignatureVerifies, called from csr-sign), which is a different question
-// about a key the caller already controls. path-validate owns the engine (_verifyWithSpki) and
-// injects it here at its module load (setEngine). The seam lives in this internal module, not on
-// path-validate's module.exports, which keeps it off the public pki.path surface. It is not wired
-// into index.js and is reached only by require.
-//
-// It deliberately does NOT compose pki-build's assertSignatureVerifies. That helper is a producing-
-// side self-check over a key the caller already controls, and it waives the EdDSA low-order-point
-// gate on exactly that reasoning. An inbound request is untrusted input, where the gate is the
-// point.
+// signature engine and no second, weaker verifier of untrusted requests can drift. The producing
+// side runs its own check over what it just signed (pki-build's assertSignatureVerifies, called
+// from csr-sign), which is a different question about a key the caller already controls. The slot,
+// the wiring assertion and the octet-alignment refusal are the shared seam (lib/verify-seam.js). It
+// is not wired into index.js and is reached only by require.
 
-var guard = require("./guard-all");
 var frameworkError = require("./framework-error");
+var seam = require("./verify-seam");
 
-var CsrError = frameworkError.CsrError;
-var _engine = null;   // path-validate's _verifyWithSpki, injected at path-validate's module load via setEngine.
-
-function setEngine(verifyWithSpki) { _engine = verifyWithSpki; }
+var _seam = seam.makeSeam("csr-verify", frameworkError.CsrError, "csr/bad-input");
 
 // Verify a parsed certification request's signature over its exact certificationRequestInfo bytes
 // under the subjectPKInfo the request carries. A CSR has no issuer: the verifying key is the one
 // inside the signed preimage, which is what makes the signature a proof of possession and nothing
-// more. Fail-closed to false on a non-octet-aligned signature or any engine fault (the engine
-// never throws out).
+// more.
 function verifyCsrSignature(parsed) {
-  // pki.csr.sign requires path-validate for the injection side-effect, so the engine is set on every
-  // route that reaches here through the public verb. A future internal consumer that requires this
-  // module without it would otherwise call null and surface a raw TypeError out of a verify, which
-  // names neither the defect nor a verdict, so the wiring is asserted rather than assumed.
-  if (_engine == null) throw new CsrError("csr/bad-input", "the csr-verify signature engine is not initialized (require pki before use)");
-  if (!guard.crypto.isOctetAligned(parsed.signatureValue)) return Promise.resolve(false);   // non-octet-aligned signature
-  return _engine(parsed.signatureAlgorithm, parsed.signatureValue.bytes,
+  return _seam.verify(parsed.signatureAlgorithm, parsed.signatureValue,
     parsed.subjectPublicKeyInfo.bytes, parsed.certificationRequestInfoBytes);
 }
 
-module.exports = { setEngine: setEngine, verifyCsrSignature: verifyCsrSignature };
+module.exports = { setEngine: _seam.setEngine, verifyCsrSignature: verifyCsrSignature };

package/lib/guard-parsed.js

@@ -508,17 +508,29 @@ function fromTrustedSource(input, kind, claimFields, parse, E, code, why) {
 // The claim fields are the ones a parsed structure has and a byte input does not, so an object that
 // was rebuilt is told what happened, never handed to a byte parser that would report something
 // about its type.
+//
+// This list is a TYPE DETECTOR, not the integrity boundary, and reads as the latter if skimmed.
+// Nothing is trusted because it appears here, and no field is unprotected because it does not:
+// fromTrustedSource re-derives the WHOLE structure from the bytes the provenance record names, so a
+// field edited on a parse result is discarded whether or not it is listed. Adding every
+// security-relevant field would therefore change no verdict. What the list decides is narrower: it
+// separates "an object claiming to be a parse result" from "bytes", so the first gets this domain's
+// typed refusal instead of being handed to a byte parser.
 var _CLAIMS = {
   certificate: ["tbsBytes", "subjectPublicKeyInfo", "serialNumberHex"],
   crl: ["tbsBytes", "revokedCertificates", "crlExtensions"],
   cms: ["signerInfos", "encapContentInfo"],
   csr: ["certificationRequestInfoBytes", "subjectPublicKeyInfo", "attributes"],
+  crmf: ["messages"],
+  attributeCertificate: ["tbsBytes", "holder", "attributes"],
 };
 var _WHY = {
   certificate: "the signed byte range, the signature and the fields that range encodes are separate properties of a parsed object, so a rebuilt certificate (Object.assign, spread, a JSON round-trip) could have them describe different certificates: keep a real CA certificate's signed bytes and signature, replace only its public key, and every field is still well-formed",
   crl: "the signed byte range, the revocation list and the scope extensions are separate properties of a parsed object, so a rebuilt CRL could have them describe different CRLs: empty the revocation list and a correctly signed CRL reports a revoked certificate as good",
   cms: "the signed attribute bytes, the signature, the encapsulated content and the certificates that verify it are separate properties of a parsed object, so a rebuilt SignedData could have them describe different messages: keep a genuine signer's signature and signed attributes, put other content beside them, and every part of the check passes for content that signer never signed",
   csr: "the signed byte range, the key it proves possession of and the subject and requested extensions that range encodes are separate properties of a parsed object, so a rebuilt request could have them describe different requests: keep a genuine requester's signed bytes and signature, replace only the subject or the extensionRequest, and the proof of possession still verifies while the certificate a CA issues from those fields is for a name and a set of extensions nobody signed",
+  crmf: "the byte range a proof of possession covers, the key that possession is proven for and the subject a CA will issue to are separate properties of a parsed object, so a rebuilt message set could have them describe different requests: keep a genuine requester's signed range and signature, replace only the certTemplate subject or public key, and the proof still verifies while the certificate is issued for a name and a key nobody proved anything about",
+  attributeCertificate: "the signed byte range, the holder the privileges attach to and the attributes granting them are separate properties of a parsed object, so a rebuilt attribute certificate could have them describe different grants: keep a genuine issuer's signed bytes and signature, replace only the holder or an attribute, and the signature still verifies while the privileges are read for someone the issuer never granted them to",
 };
 // @enforced-by guard-shape-reinlined -- shares the fromTrustedSource shape it composes: a door that
 //   tests the claim fields itself, instead of routing here, is the re-inline both replace.
@@ -542,7 +554,8 @@ function acceptDerived(input, kind, parse, E, code, label) {
       throw E(code, who + " must be a " + kind + " DER Buffer, a PEM string, or a parsed " + kind);
     }
   }
-  var ns = { certificate: "x509", crl: "crl", cms: "cms", csr: "csr" }[kind];
+  var ns = { certificate: "x509", crl: "crl", cms: "cms", csr: "csr", crmf: "crmf",
+    attributeCertificate: "attrcert" }[kind];
   return fromTrustedSource(input, kind, claims, parse, E, code,
     who + " must be its DER bytes, a PEM string, or an unmodified pki.schema." + ns +
     ".parse result: " + _WHY[kind]);

package/lib/path-validate.js

@@ -41,6 +41,8 @@ var ocsp = require("./schema-ocsp");
 var ocspVerify = require("./ocsp-verify");
 var crlVerify = require("./crl-verify");
 var csrVerify = require("./csr-verify");
+var crmfVerify = require("./crmf-verify");
+var attrcertVerify = require("./attrcert-verify");
 var cmpVerify = require("./cmp-verify");
 var cmsVerify = require("./cms-verify");
 var cmpSession = require("./cmp-session");
@@ -2275,6 +2277,14 @@ crlVerify.setEngine(_verifyWithSpki);
 // EdDSA low-order-point gate because it runs over a key the caller already controls.
 csrVerify.setEngine(_verifyWithSpki);
 
+// And for RFC 4211 proof of possession, so an inbound CertReqMsg is checked through the same one
+// engine as the PKCS#10 form of the same question.
+crmfVerify.setEngine(_verifyWithSpki);
+
+// And for an RFC 5755 attribute certificate, whose AC issuer is an out-of-path signer reached the
+// same way.
+attrcertVerify.setEngine(_verifyWithSpki);
+
 // ---- the OCSP revocation checker (RFC 6960) -------------------------------
 
 // The OCSP response-verification core (responder authorization + CertID binding + currency +

package/lib/schema-attrcert.js

@@ -359,7 +359,7 @@ function _legacyV1Error() {
   return new AttrCertError("attrcert/legacy-v1-not-supported", "AttributeCertificateV1 (X.509-1997) is obsolete and not parsed by this build (RFC 5755 sec. 1)");
 }
 
-function parse(input) {
+function _parseAc(input) {
   var root = pkix.decodeRoot(pkix.coerceToDer(input, PARSE_OPTS), PARSE_OPTS);
   // A well-formed legacy AttributeCertificateV1 gets the advertised, stable
   // attrcert/legacy-v1-not-supported on the DIRECT path too -- not a low-level asn1/*
@@ -369,6 +369,12 @@ function parse(input) {
   return schema.walk(ATTRIBUTE_CERTIFICATE, root, NS).result;
 }
 
+// Recording, because pki.attrcert.verify reaches a verdict from this result: the signed byte range,
+// the holder the privileges attach to and the attributes themselves are separate properties here,
+// so the record is what binds them to one another.
+var parse = guard.parsed.recordingParser("attributeCertificate", _parseAc,
+  AttrCertError, "attrcert/bad-input", "an attribute certificate");
+
 // The obsolete X.509-1997 AttributeCertificateV1 (RFC 5652 sec. 10.2) is recognized and
 // deferred: decode the envelope (so a malformed input still fails as bad DER), then
 // throw the precise diagnostic rather than routing it to a wrong format.
@@ -482,6 +488,17 @@ function _oneGN(node, code) {
   return { tagNumber: gn.tagNumber, value: gn.value };
 }
 
+// readGeneralName(der) -> { tagNumber, value }, the shape every GeneralName in a parsed attribute
+// certificate is surfaced in.
+//
+// @internal -- exported so a verifier comparing a caller's GeneralName against one this module
+// decoded puts BOTH sides through this one decoder. A second decoder would be a second set of
+// per-form conventions, and a comparison whose two halves were produced by different rules is a
+// comparison of the rules rather than of the names.
+function readGeneralName(der, code) {
+  return _oneGN(asn1.decode(der), code || "attrcert/bad-input");
+}
+
 // SvceAuthInfo ::= SEQUENCE { service GeneralName, ident GeneralName, authInfo OCTET STRING OPTIONAL }
 // -- authenticationInfo (sec. 4.4.1) allows authInfo; accessIdentity (sec. 4.4.2) MUST omit it.
 function _svceAuthInfo(authInfoAllowed, code) {
@@ -715,6 +732,7 @@ module.exports = {
   pemEncode: pemEncode,
   matches: matches,
   matchesV1: matchesV1,
+  readGeneralName: readGeneralName,
   validateAttributeValue: validateAttributeValue,
   validateExtensionValue: validateExtensionValue,
 };

package/lib/schema-crmf.js

@@ -489,10 +489,13 @@ var CERT_REQ_MESSAGES = schema.seqOf(CERT_REQ_MSG, {
  *   var m = pki.schema.crmf.parse(der);
  *   m.messages[0].certReq.certTemplate.subject.dn;   // "CN=req.example"
  */
-var parse = pkix.makeParser({
+// Recording, because pki.crmf.verifyPop reaches a verdict from this result: the byte range a
+// proof of possession covers, the key that possession is proven for, and the subject the CA will
+// issue to are separate properties here, so the record is what binds them to one another.
+var parse = pkix.makeRecordingParser({
   pemLabel: null, PemError: PemError, ErrorClass: CrmfError, prefix: "crmf",
   what: "certificate request message", topSchema: CERT_REQ_MESSAGES, ns: NS,
-});
+}, "crmf");
 
 /**
  * @primitive  pki.schema.crmf.pemDecode

package/lib/verify-seam.js

@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: Apache-2.0
+// Copyright (c) blamejs contributors
+"use strict";
+//
+// @internal -- the injected-signature-engine seam, once.
+//
+// A CRL, a PKCS#10 certification request and an RFC 4211 CertReqMsg all verify an untrusted
+// signature through the same path-validation engine, which carries the algorithm-confusion, EdDSA
+// low-order and composite gates. None of them may reach that engine through pki.path's public
+// surface, so each holds a slot that path-validate fills at its module load. Each was writing the
+// same slot, the same wiring assertion and the same octet-alignment refusal. That shape lives here
+// now. A format module supplies what is its own: an error class, a code, and the preimage bytes.
+//
+// The producing side of each format asks a different question, through pki-build's
+// assertSignatureVerifies: whether the signature it has just made verifies under a key the caller
+// already controls. That check waives the EdDSA low-order-point gate for that reason, and is a
+// separate mechanism from this one.
+
+var guard = require("./guard-all");
+
+// makeSeam(name, ErrorClass, code) -> { setEngine, verify }.
+//
+// `verify(sigAlg, signature, spkiBytes, preimage)` takes the signature as the parsed BIT STRING
+// ({ unusedBits, bytes }), because the octet-alignment refusal is part of the contract: a signature
+// carrying unused bits is malformed for every algorithm these formats admit, and a caller that had
+// already discarded `unusedBits` could not be held to it.
+function makeSeam(name, ErrorClass, code) {
+  var engine = null;
+
+  return {
+    setEngine: function (verifyWithSpki) { engine = verifyWithSpki; },
+
+    verify: function (sigAlg, signature, spkiBytes, preimage) {
+      // Each format's producing verb requires path-validate for the injection side-effect, so the
+      // engine is set on every route that reaches here through a public verb. A future internal
+      // consumer that required a seam without it would otherwise call null and surface a raw
+      // TypeError out of a verify, which names neither the defect nor a verdict.
+      if (engine == null) {
+        throw new ErrorClass(code, "the " + name + " signature engine is not initialized (require pki before use)");
+      }
+      if (!guard.crypto.isOctetAligned(signature)) return Promise.resolve(false);
+      return engine(sigAlg, signature.bytes, spkiBytes, preimage);
+    },
+  };
+}
+
+module.exports = { makeSeam: makeSeam };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/pki",
-  "version": "0.5.13",
+  "version": "0.5.15",
   "description": "Pure-JavaScript PKI toolkit that owns its stack — X.509, ASN.1/DER, CMS, PQC-first.",
   "license": "Apache-2.0",
   "author": "blamejs contributors",

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:4bd2d60e-9fd1-4008-8d42-7a9d790812ac",
+  "serialNumber": "urn:uuid:75f14a7c-3b79-4cbc-8db6-fb4987becceb",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-08-19T09:39:41.731Z",
+    "timestamp": "2026-08-19T13:58:32.723Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/pki@0.5.13",
+      "bom-ref": "@blamejs/pki@0.5.15",
       "type": "application",
       "name": "pki",
-      "version": "0.5.13",
+      "version": "0.5.15",
       "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.13",
+      "purl": "pkg:npm/%40blamejs/pki@0.5.15",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/pki@0.5.13",
+      "ref": "@blamejs/pki@0.5.15",
       "dependsOn": []
     }
   ]