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 23f3b26
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: docs/releasenotes.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -83,6 +83,8 @@ Date: 2026, TBD
83
83
- 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.
84
84
- TLS: The extensions of the CertificateEntry list in a TLS 1.3 Certificate message were not checked against what the receiving endpoint had asked for, although RFC 8446 sec. 4.4.2 requires those in a server's Certificate to correspond to extensions in the ClientHello and those in a client's Certificate to extensions in the CertificateRequest: a client ignored an OCSP response the server stapled without being asked, and a server accepted whatever a client attached. An unrequested extension in any entry now aborts the handshake with an unsupported_extension alert, as RFC 8446 sec. 4.2 requires. A TLS 1.3 server also now rejects a client Certificate whose certificate_request_context differs from that of its CertificateRequest, with an illegal_parameter alert.
85
85
86
+
- CRL.isRevoked() on the provider's CRLs threw ClassCastException for a certificate whose type is "X.509" but which is not a java.security.cert.X509Certificate, although the method checks only the type and goes on to handle exactly that case: it cast the certificate to X509Certificate for its serial number before looking at any entry, so the branch that reads the issuer from the certificate's encoding could never be reached. Such a certificate now has both its serial number and its issuer read from its encoding, in the provider's X509CRL and in the legacy org.bouncycastle.jce.provider.X509CRLObject alike.
87
+
86
88
### 2.1.3 Additional Features and Functionality
87
89
88
90
- 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).
0 commit comments