@@ -146,8 +146,7 @@ Date: 2026, TBD
 - IEEE 1609.2 (ITS) lets a signer carry the r of an ECDSA signature as rSig of form x-only, or the point R as compressed-y-0, compressed-y-1 or uncompressed, and requires rSig to be taken to be of form x-only whenever a structure is encoded for hashing. ECDSAEncoder.toX962 failed with an IllegalArgumentException on the uncompressed form, so ETSISignedData.signatureValid and ITSCertificate.isSignatureValid could not verify such a signature, and the compressed forms were read without reducing the x coordinate mod n. The Bc and Jca ITSContentSigner and ITSContentVerifierProvider, and ITSImplicitCertificateBuilder, also hashed an issuer or signer certificate exactly as encoded, so a certificate whose signature carried R produced the wrong HashedId8 and signer digest, and signatures made under it did not verify. r is now recovered from every form that carries it, and certificates are hashed through the new ITSCertificate.getCanonicalEncoding(), which converts rSig to x-only (ECDSAEncoder.toXOnly). Certificates already using x-only, as BC produces, hash exactly as before (github #2496).
 - EccP256CurvePoint.createEncodedPoint split a 65 byte uncompressed point encoding at the wrong offsets, taking 33 bytes for x and running one byte past the end for y, so it always failed with "x must be 32 bytes long"; it also accepted compressed encodings of any length. Uncompressed encodings are now split correctly, and both forms must be of the length their curve size requires.
 - CertificateRequestMessageBuilder.build() failed with a NullPointerException for a signing key proof of possession it could not form: one whose certificate template carried no public key, which the POPOSigningKeyInput of RFC 4211 sec. 4.1 must repeat and the signature is verified against, or one whose template carried no subject and for which neither setAuthInfoSender() nor setAuthInfoPKMAC() had been called. Both now fail with a CRMFException saying what is missing.
-- Both copies of PKIXCertPathReviewer (org.bouncycastle.pkix.jcajce and the legacy org.bouncycastle.x509), and so SignedMailValidator, which uses the first by default, have been hardened in how they fetch CRLs from a certificate's CRL distribution points when revocation checking is on. Previously the fetch did not require org.bouncycastle.x509.enableCRLDP, the opt-in CertPathValidator and X509RevocationChecker require before using the network, was also made for certificates that did not chain to a trust anchor, and had no connect or read timeout. The reviewers now fetch from a distribution point only when org.bouncycastle.x509.enableCRLDP is set and the certificate has verified back to a trust anchor, reporting a notification when they decline, and apply a 15 second connect and read timeout as CrlCache does (the jdk1.4 build, which has no timeout API, still sets none). Applications that relied on the reviewer fetching CRLs without the property will need to set it.
-- Following the CRL distribution point hardening of both PKIXCertPathReviewer copies above, the issuer chain condition behind the fetch now requires that no error has been recorded against the trust anchor or against any certificate above the one being checked, where previously it tracked signatures only, so a certificate issued under an end entity certificate from a trusted CA, or under a revoked or expired intermediate, no longer has its distribution points fetched (CertPathReviewer.crlDistPtFetchUntrusted is reported instead). A CRL fetched from a distribution point is now held to the same RFC 5280 sec. 6.3.3 scope rules as one taken from a local store, reported as CertPathReviewer.onlineCRLOutOfScope and passed over when its issuing distribution point does not cover the certificate, where previously an in-date CRL from the right issuer scoped to another distribution point or to some of the revocation reasons was taken as proof of non-revocation. The fetch now closes its input stream and disconnects the connection, which were previously left to garbage collection, and a DistributionPoint carrying only cRLIssuer, which RFC 5280 sec. 4.2.1.13 permits, no longer fails the review with a NullPointerException from getCRLDistUrls() when revocation checking is on.
+- Both copies of PKIXCertPathReviewer (org.bouncycastle.pkix.jcajce and the legacy org.bouncycastle.x509), and so SignedMailValidator, which uses the first by default, have been hardened in how they fetch CRLs from a certificate's CRL distribution points when revocation checking is on. Previously the fetch did not require org.bouncycastle.x509.enableCRLDP, the opt-in CertPathValidator and X509RevocationChecker require before using the network, was also made for certificates that did not chain to a trust anchor, had no connect or read timeout, and left its input stream and connection to garbage collection. The reviewers now fetch from a distribution point only when org.bouncycastle.x509.enableCRLDP is set and no error has been recorded against the trust anchor or against any certificate above the one being checked - so a certificate that does not verify back to a trust anchor, or one issued under an end entity certificate from a trusted CA or under a revoked or expired intermediate, has no distribution point fetched - reporting a notification (CertPathReviewer.crlDistPtFetchDisabled or CertPathReviewer.crlDistPtFetchUntrusted) when they decline, apply a 15 second connect and read timeout as CrlCache does (the jdk1.4 build, which has no timeout API, still sets none), and close the stream and disconnect the connection when the fetch ends. A CRL fetched from a distribution point is now held to the same RFC 5280 sec. 6.3.3 scope rules as one taken from a local store, reported as CertPathReviewer.onlineCRLOutOfScope and passed over when its issuing distribution point does not cover the certificate, where previously an in-date CRL from the right issuer scoped to another distribution point or to some of the revocation reasons was taken as proof of non-revocation, and a DistributionPoint carrying only cRLIssuer, which RFC 5280 sec. 4.2.1.13 permits, no longer fails the review with a NullPointerException from getCRLDistUrls() when revocation checking is on. Applications that relied on the reviewer fetching CRLs without the property will need to set it.
 - With org.bouncycastle.pkcs12.allow_sun_secret_keys set, the PKCS#12 key stores rejected the password for a file with no MAC whose only protected content was a SunJCE-style secret key bag, with "password supplied for keystore that does not require one", although the bag had just been decrypted with that password. Such a bag now counts as protected content, as a shrouded key bag does. A standard secret key bag holds its key in the clear and is unaffected (github #1807).
 - With org.bouncycastle.pkcs12.allow_sun_secret_keys set, a secret key read from a PKCS#12 file written by the JDK could come back with its algorithm OID as its name: the JDK labels AES keys with the bare AES arc, DESede and DES keys with their OIW OIDs, and also stores RC2, Blowfish, HmacSHA512/224 and HmacSHA512/256 keys under OIDs BC did not map. Those keys were rejected by other providers, such as SunJCE. They are now named AES, DESede, DES, RC2, Blowfish, HmacSHA512/224 and HmacSHA512/256 (github #1807).
 - The 1.84 fix to Strings.split for a delimiter at position 0 reached the jdk1.4 copy but not the jdk1.1 and J2ME ones, which still returned ".b.example.com" whole rather than splitting off the leading empty label. PKIXNameConstraintValidator, which those distributions share with the others, splits dNSName and rfc822Name constraints with it, so a subordinate CA narrowing its issuer's permitted subtree - .example.com at the root, .b.example.com below it - left an empty intersection, so host.b.example.com and every other name of that type was rejected. Both copies now split as the others do, and their name-constraint results match them (github #1481).
 
@@ -442,11 +442,11 @@ CertPathReviewer.crlDistPtFetchDisabled.text = No CRL was loaded from the CRL di
 CertPathReviewer.crlDistPtFetchDisabled.summary = No CRL was loaded from the CRL distribution point, as online CRL fetching is not enabled.
 CertPathReviewer.crlDistPtFetchDisabled.details = No CRL was loaded from the CRL distribution point, as online CRL fetching is not enabled. Set org.bouncycastle.x509.enableCRLDP to true to enable it.
 
-# CRL distribution point not fetched, as the certificate does not chain to a trust anchor
+# CRL distribution point not fetched, as the issuer chain failed a check: no trust anchor, or an error recorded against the trust anchor or a certificate above this one
 CertPathReviewer.crlDistPtFetchUntrusted.title = CRL distribution point not used
-CertPathReviewer.crlDistPtFetchUntrusted.text = No CRL was loaded from the CRL distribution point, as the certificate could not be verified back to a trust anchor.
-CertPathReviewer.crlDistPtFetchUntrusted.summary = No CRL was loaded from the CRL distribution point, as the certificate could not be verified back to a trust anchor.
-CertPathReviewer.crlDistPtFetchUntrusted.details = No CRL was loaded from the CRL distribution point, as the certificate could not be verified back to a trust anchor.
+CertPathReviewer.crlDistPtFetchUntrusted.text = No CRL was loaded from the CRL distribution point, as the issuer chain of the certificate did not pass every check: the certificate could not be verified back to a trust anchor, or an error was recorded against the trust anchor or a certificate above this one.
+CertPathReviewer.crlDistPtFetchUntrusted.summary = No CRL was loaded from the CRL distribution point, as the issuer chain of the certificate did not pass every check.
+CertPathReviewer.crlDistPtFetchUntrusted.details = No CRL was loaded from the CRL distribution point, as the issuer chain of the certificate did not pass every check: the certificate could not be verified back to a trust anchor, or an error was recorded against the trust anchor or a certificate above this one.
 
 # no crl found in certstores
 # {0} the issuers which we searched for