- Both copies of PKIXCertPathReviewer (org.bouncycastle.pkix.jcajce and the legacy org.bouncycastle.x509) took the first date-valid CRL issued by the certificate's issuer as an answer about that certificate, applying neither of the RFC 5280 sec. 6.3.3 rules that decide whether a CRL covers it: the (b)(2)(i) match between a name in the CRL's issuing distribution point and a name in the certificate's distribution point, and the (d) intersection of the revocation reasons the two assert. Only the (b)(2)(ii) to (iv) onlyContains booleans were applied. A CA-signed, in-date CRL with no entries, scoped to another distribution point or to a partition of the revocation reasons, was therefore reported as proof of non-revocation - isValidCertPath() true with an empty error list for a certificate its own CA had revoked for key compromise, where CertPathValidator("PKIX") rejects the same chain against the same trust anchor - and it suppressed the distribution point fetch that would otherwise have retrieved the authoritative CRL. Where the reviewer makes the trust decision rather than serving as diagnostics beside a real validation this is a revocation bypass, and SignedMailValidator (bcmail) reaches it with the CRLs carried inside the signed message. Both copies now apply the (b)(2)(i) name match and require a CRL to cover every revocation reason before it can settle the certificate's status, through the public PKIXCRLValidator helpers the validation engine already uses, and keep looking when a candidate does not qualify - falling back, as before, to the distribution point fetch and then to the existing "no valid CRL found" error. A CRL carrying no issuing distribution point, one naming the certificate's own distribution point, and one naming the certificate issuer (the distribution point the engine falls back to) are all still accepted.

- RFC3280CertPathUtilities.checkCRL threw java.lang.NullPointerException rather than a CertPathValidatorException when every candidate CRL for a distribution point was skipped instead of rejected, which is what happens when the reasons a CRL covers add nothing to those already checked - the RFC 5280 sec. 6.3.3 (d) case - since the exception it rethrows is only ever recorded in a catch block. Validation failed closed either way, but outside the declared contract of CertPathValidator.validate(); a run with nothing recorded now reports "No valid CRL found.". All four copies are corrected: pkix, prov, and the prov jdk1.3 and jdk1.4 overlays.

- TupleHash prefixed an element of 2^28 bytes or more with a length computed in int arithmetic: org.bouncycastle.crypto.digests.XofUtils built the encode_string prefix of NIST SP 800-185 sec. 2.3.3 as left_encode(len * 8) with len an int, so the bit length wrapped before it reached the long parameter it was passed to. A single 256 MiB update wrapped it negative, and left_encode sizes its output by shifting its argument right eight bits at a time, which never reaches zero from a negative value, so the call did not return; at 512 MiB the length wrapped to zero and the element carried the prefix of an empty one, letting two different tuples absorb the same byte string - the ambiguity the tuple encoding of sec. 5.3 exists to prevent. The multiply is now widened, as the other left_encode and right_encode call sites in CSHAKEDigest, KMAC, TupleHash and ParallelHash already were, and left_encode and right_encode refuse a negative length rather than spinning on one, so a negative output length handed to the three-argument doFinal of TupleHash, ParallelHash or KMAC reports IllegalArgumentException instead of not returning. An element below 2^28 bytes is unaffected, the two arithmetics agreeing exactly there.

- KeyAgreement.init() reported an initialisation it could not carry out as an unchecked exception for the unified and VKO agreements, where the JCA declares InvalidKeyException and InvalidAlgorithmParameterException. The ECCDHU and X25519U/X448U services took a plain UserKeyingMaterialSpec, or no spec at all, and carried it into the agreement, throwing ClassCastException from the cast that follows; the DHU and DH MQV services accepted the initialisation and then threw NullPointerException from doPhase, where the absent spec is read back; and the ECGOST3410 and ECGOST3410-2012 VKO services put a null where the UKM belongs, although RFC 7836 sec. 4.3 makes the UKM optional with the value 1. Each of them now reports a parameter error as ECMQV already did, and the VKO agreements apply the RFC 7836 default, so an agreement initialised without a UserKeyingMaterialSpec derives the key a UKM of 1 gives rather than failing. The user keying material itself was not being dropped anywhere: every key agreement service carrying a key derivation function was checked for it.

### 2.1.3 Additional Features and Functionality