You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 8bf734b
Browse filesBrowse the repository at this point in the historyBrowse files
Fixed TLS feature (RFC 7633) checks: TLS 1.3 features are satisfied by the end-entity CertificateEntry, status_request_v2 is not enforced under TLS 1.3, and must-staple now requires a stapled response for the end-entity certificate in every version, relates to github #2458.
Copy file name to clipboardExpand all lines: docs/releasenotes.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -76,6 +76,10 @@ Date: 2026, TBD
76
76
- The jdk1.4 and jdk1.3 providers registered the PKCS12-AES256-AES128, PKCS12-AES256-AES128-GCM, PKCS12-DEF-AES256-AES128 and PKCS12-DEF-AES256-AES128-GCM KeyStores against classes those distributions do not contain. They are no longer registered there; the legacy PKCS12 stores can still read PBES2/AES protected files.
77
77
- The OCSPResp(byte[]) and OCSPReq(byte[]) constructors reported a malformed encoding only when the ASN.1 decode raised IllegalArgumentException, ClassCastException or ASN1Exception, so a top-level SEQUENCE that is empty or truncated - which makes OCSPResponse/OCSPRequest read seq.getObjectAt(0) out of bounds - escaped the declared IOException as an ArrayIndexOutOfBoundsException. Both parsers now surface any RuntimeException from the decode as a CertIOException, as X509CertificateHolder and X509CRLHolder already do, so an OCSP client parsing a response and an OCSP responder parsing a request reject malformed input through the contract rather than crashing. The cause was in the ASN.1 types, which read fixed positions of their SEQUENCE without checking its size: OCSPResponse, OCSPRequest, BasicOCSPResponse, ResponseData, TBSRequest and Request now reject a short one with IllegalArgumentException, as SingleResponse and CertID already did. The OCSP ASN.1 types also cast their elements rather than passing them to getInstance(), so an element of the wrong type surfaced as a ClassCastException and a signature BIT STRING in a legal encoding other than DER was refused; they now use getInstance() throughout, and BasicOCSPResponse and Signature accept any BIT STRING encoding. The provider's OCSP revocation checking parses these types directly and let an unchecked exception out of CertPathValidator.validate() for a response that would not decode, whether stapled by the caller or returned by the responder; a stapled one is now rejected with a CertPathValidatorException, and a fetched one is treated as an unreachable responder is, so the check can fall back to CRLs. A successful response carrying no response bytes, which failed with a NullPointerException, is rejected the same way.
78
78
79
+
- TLS: A TLS 1.3 client rejected every server certificate whose TLS feature extension (RFC 7633) listed status_request ("must-staple") whenever it had offered status_request itself, since the feature was looked for only in EncryptedExtensions, where RFC 8446 does not permit it; TLS 1.3 carries the OCSP response in the end-entity certificate's CertificateEntry. A feature is now also satisfied by the extensions of that CertificateEntry, and a feature whose extension has no place in TLS 1.3, such as status_request_v2, is no longer enforced once TLS 1.3 is negotiated (github #2458).
80
+
- (D)TLS: A server certificate whose TLS feature extension listed status_request or status_request_v2 was accepted without any OCSP response for it when the server acknowledged the status request but then sent no CertificateStatus message, which RFC 6066 permits, or sent an ocsp_multi list with no response for the end-entity certificate. Such a certificate now requires a stapled OCSP response for the end-entity certificate, in every protocol version. A TLS feature in force against a (D)TLS 1.2 ServerHello that carried no extensions at all now fails with a certificate_unknown alert rather than a NullPointerException.
81
+
- TLS: A TLS 1.3 client aborted the handshake with an illegal_parameter alert when the server sent the cached_info or record_size_limit extension in EncryptedExtensions, or the server_name extension in a CertificateRequest, since these were missing from the table of extensions permitted in each TLS 1.3 message.
82
+
79
83
### 2.1.3 Additional Features and Functionality
80
84
81
85
- The CRMF certificate request message controls now include the RFC 4211 sec. 6.6 protocolEncrKey control, which names the key a CA is to encrypt its response with: org.bouncycastle.cert.crmf.ProtocolEncrKeyControl carries the SubjectPublicKeyInfo the control is defined to take, and CertificateRequestMessage.getControl() recognises id-regCtrl-protocolEncrKey alongside the regToken, authenticator and pkiArchiveOptions controls it already returned (github PR #2443).
@@ -97,6 +101,8 @@ Date: 2026, TBD
97
101
98
102
- The provider adds ECDHwithSHA256HKDF, ECDHwithSHA384HKDF and ECDHwithSHA512HKDF KeyAgreement algorithms: ECDH followed by HKDF (RFC 5869), the counterparts for elliptic curve keys of the XDHwithSHA\*HKDF agreements used for the RFC 8418 dhSinglePass-stdDH-hkdf schemes. As with those, a UserKeyingMaterialSpec supplies the HKDF info and, optionally, its salt. They are registered by name only; the RFC 8418 scheme object identifiers remain registered to the XDH agreements.
99
103
104
+
- TLS: Added CertificateStatusType.getName and getText, and TlsUtils.hasExtension.
105
+
100
106
### 2.1.4 Additional Notes
101
107
102
108
- The sources and javadoc jars of the Ant-built distributions (jdk14, jdk15to18 and jdk13) no longer carry test material. Each module's javadoc target copies the package documentation it needs - org/bouncycastle/<area>/**/*.html - back into the module source directory that has already been compiled from, and zip-src zips that directory afterwards, so every test package's package.html arrived in the sources jar by that route; javadoc-util additionally copied org/bouncycastle/asn1/isismtt/**/*.java, which put test classes into the bcutil javadoc as generated pages, and javadoc-pg deliberately copied the gpg and bcpg test sources in order to document them. Separately the source copies excluded test material only one directory deep and only for *.java, because Ant reads ** as an any-depth wildcard just where it is a whole path segment, so anything nested further or with another extension - the PEM certificate fixtures under org/bouncycastle/est/test/san corrected in 1.86, and an ICAO master list under org/bouncycastle/asn1/icao/test - went through. The source and javadoc copies of every module now exclude test directories at any depth, and javadoc-pg no longer documents the test packages. org.bouncycastle.util.test is unaffected and still ships in the bcprov binary, sources and javadoc jars, as it does from the Gradle build: it is the SimpleTest framework the light-weight API's own test classes are written against, not test material of the distribution. No binary changes - the classes and resources of every Ant-built jar are identical to those of the 1.86 release - and the Gradle-built jdk18on artifacts never carried any of this.
0 commit comments