Merge branch 'main' of gitlab.cryptoworkshop.com:root/bc-java

Author: dghgit

docs/releasenotes.html

@@ -27,6 +27,7 @@ <h3>2.1.2 Defects Fixed</h3>
 <li>The SecureRandom supplied to org.bouncycastle.cms.jcajce.JceCMSContentEncryptorBuilder.setSecureRandom() did not drive the content IV / nonce for any algorithm other than RC2. EnvelopedDataHelper.generateParameters passed the caller's SecureRandom to the AlgorithmParameterGenerator only in the RC2_CBC branch; every other content-encryption algorithm - AES-CBC, AES-GCM, AES-CCM, Camellia, ARIA, SEED and the rest - reached pGen.generateParameters() on an uninitialised generator, so the IV / nonce was drawn from a default SecureRandom and setSecureRandom() was silently ignored (the builder's javadoc states that random is used for IV/nonce generation). The generator is now initialised with the supplied random on the general path as well, so a caller who provides a specific randomness source - for a controlled or FIPS-approved DRBG, say - has it honoured for the content IV / nonce. The session-key generation path was unaffected and already used the supplied random. Because the content IV / nonce now comes from the supplied SecureRandom, the org.bouncycastle.crypto.util JournalingSecureRandom / JournaledAlgorithm reproducible-encryption support records it in the transcript: a resumed session reproduces the IV / nonce by regenerating it from the replayed randomness - build the resuming encryptor from the content-algorithm OID - rather than by reusing the AlgorithmIdentifier captured from the first encryption, which no longer keeps the transcript aligned.</li>
 <li>The NTRU LPRime, NTRU+ and SMAUG-T KEM generators threw a NullPointerException when constructed with a null SecureRandom, where every other KEM generator - including NTRU LPRime's own SNTRU Prime counterpart in the same package - defaults one through CryptoServicesRegistrar.getSecureRandom(). This is reachable from the lightweight API directly, and from javax.crypto.KEM, whose newEncapsulator() documents a null random as a request for the provider's default.</li>
 <li>FrodoKEMEngine kept a single SHAKE instance in a field, so an engine reached concurrently produced wrong results. It is reached that way through org.bouncycastle.crypto.kems.FrodoKEMExtractor, which holds one engine for its lifetime: two threads extracting through one extractor interleaved the digest's absorb and squeeze phases, yielding shared secrets that silently did not match the sender's, or an IllegalStateException of "attempt to absorb while squeezing" from inside extractSecret. The digest is now built per call, as CMCEEngine's already was, which makes an extractor safe to share. Encapsulation was unaffected, since FrodoKEMGenerator builds an engine per call. Results for any single-threaded use are unchanged - the reference KAT vectors are byte-identical.</li>
+<li>The BCJSSE provider carried the TLS 1.2 coupling between the supported_groups extension and ECDSA over into TLS 1.3: an ECDSA signature scheme was treated as usable - offered in the signature_algorithms and signature_algorithms_cert extensions, and eligible when selecting the local credentials - only while the corresponding curve was among the named groups enabled for key exchange, both per context (a group unavailable for key agreement disabled the scheme outright) and per connection (the curve had to be in the supported_groups list about to be sent). RFC 8446 sec. 4.2.7 scopes supported_groups to key exchange only, with signature algorithms negotiated independently (sec. 4.2.3), so this incorrect restriction in TLS 1.3 has been removed. Ed25519, Ed448 and the RSA schemes were unaffected (as well as typical deployments using a default configuration for named groups).</li>
 <li>The bcmail module descriptor did not declare its javax.mail/javax.activation dependences, so a modular (module-path) consumer of the jar hit IllegalAccessError/module-resolution failures when the S/MIME classes touched the mail API. The descriptor now requires them optionally (requires static) under all four module names those libraries are known by - the automatic names mail and activation carried by the javax.mail:mail / javax.activation:activation artifacts, and the explicit names java.mail and java.activation carried by the newer com.sun.mail / com.sun.activation ones - a hard requires on any one name would break users of the others (github #2389).</li>
 <li>Four type-coercion helpers in the OER / IEEE 1609.2 (ITS) decoder tested the wrong type in the identity fast path that lets a getInstance() factory return an argument that is already of the target type. org.bouncycastle.oer.its.ieee1609dot2.basetypes.UINT32.getInstance and org.bouncycastle.oer.its.etsi102941.basetypes.Version.getInstance guarded on UINT8 - a sibling of UINT32 under UintBase, and unrelated to Version - so passing a UINT8 threw ClassCastException, while passing an actual UINT32 or Version missed the fast path and fell through to ASN1Integer.getInstance, which rejects them: neither factory accepted its own type. org.bouncycastle.oer.its.etsi103097.EtsiTs103097DataEncryptedUnicast.getInstance guarded on its sibling EtsiTs103097DataEncrypted and then cast to the unicast type, so an EtsiTs103097DataEncrypted threw ClassCastException. org.bouncycastle.oer.OEROptional.getObject(Class) called value.getClass().isInstance(type) with the arguments transposed, which is always false because the argument is a java.lang.Class, so the cast path was dead and every optional field was resolved reflectively, failing with IllegalStateException for a target type with no static getInstance. Each guard now names the type it returns, matching the sibling UINT8 / UINT16 / UINT64 and EtsiTs103097DataEncrypted factories (github #2373).</li>
 <li>DefaultAlgorithmNameFinder and DefaultSignatureNameFinder had no entries at all for the ShangMi algorithms, so an SM2 signature AlgorithmIdentifier that DefaultSignatureAlgorithmIdentifierFinder itself produces came back named only by its OID string - getAlgorithmName(GMObjectIdentifiers.sm2sign_with_sm3) returned "1.2.156.10197.1.501" and hasAlgorithmName returned false. Both finders now name sm2sign_with_sm3 as SM3WITHSM2 and sm2sign_with_sha256 as SHA256WITHSM2, and DefaultAlgorithmNameFinder additionally names the sm3 digest. All three resolve through the BC provider, as Signature and MessageDigest respectively. The remaining GM arc - the SM4 cipher modes, the sm2encrypt variants, and the SM1 / SM6 / SSF33 ciphers BC does not implement - is still unnamed (github #2377).</li>

tls/src/main/java/org/bouncycastle/jsse/provider/SignatureSchemeInfo.java

@@ -506,7 +506,16 @@ private static void addSignatureScheme(boolean isFipsContext, JcaTlsCrypto crypt
         if (namedGroup13 >= 0)
         {
             namedGroupInfo = NamedGroupInfo.getNamedGroup(ng, namedGroup13);
-            if (null == namedGroupInfo || !namedGroupInfo.isEnabled() || !namedGroupInfo.isSupportedPost13())
+
+            /*
+             * RFC 8446 4.2.7: "supported_groups" applies only to key exchange; signature algorithms
+             * are negotiated independently (see 4.2.3). The availability of the associated named
+             * group therefore places no restriction on a TLS 1.3 signature scheme, EXCEPT that
+             * sm2sig_sm3 is used only as part of the RFC 8998 profile, of which curveSM2 key
+             * exchange is an integral part.
+             */
+            if (SignatureScheme.sm2sig_sm3 == signatureScheme
+                && (null == namedGroupInfo || !namedGroupInfo.isEnabled() || !namedGroupInfo.isSupportedPost13()))
             {
                 disabled13 = true;
             }
@@ -773,15 +782,28 @@ && isNamedGroupOK(post13Active && isSupportedCerts13(), pre13Active && isSupport
 
     private boolean isNamedGroupOK(boolean post13Allowed, boolean pre13Allowed, NamedGroupInfo.PerConnection namedGroupInfos)
     {
-        if (null != namedGroupInfo)
-        {
-                   // TODO[tls13] NOTE: a "restricted group" scheme actually supporting TLS 1.3 usage 
-            return (post13Allowed && NamedGroupInfo.hasLocal(namedGroupInfos, namedGroupInfo.getNamedGroup()))
-                   // TODO[tls13] NOTE: this can result in a "restricted group" scheme being active, but not actually supporting TLS 1.3 
-                || (pre13Allowed && NamedGroupInfo.hasAnyECDSALocal(namedGroupInfos));
+        if (post13Allowed)
+        {
+            /*
+             * RFC 8446 4.2.7: "supported_groups" applies only to key exchange; signature algorithms
+             * are negotiated independently (see 4.2.3). The local named groups therefore place no
+             * restriction on a TLS 1.3 signature scheme, EXCEPT that sm2sig_sm3 is used only as
+             * part of the RFC 8998 profile, of which curveSM2 key exchange is an integral part.
+             */
+            if (SignatureScheme.sm2sig_sm3 != all.signatureScheme
+                || (null != namedGroupInfo
+                    && NamedGroupInfo.hasLocal(namedGroupInfos, namedGroupInfo.getNamedGroup())))
+            {
+                return true;
+            }
         }
 
-        return (post13Allowed || pre13Allowed)
+        /*
+         * RFC 8446 4.2.3: in TLS 1.2 the ECDSA codepoints do not constrain the signing curve; the
+         * peer may sign using any curve we advertised in "supported_groups", so only offer ECDSA
+         * schemes when at least one ECDSA-capable group is advertised.
+         */
+        return pre13Allowed
             && (!isECDSA(all.signatureScheme) || NamedGroupInfo.hasAnyECDSALocal(namedGroupInfos));
     }
 

tls/src/test/java/org/bouncycastle/jsse/provider/test/ECDSACredentialsTest.java

@@ -105,6 +105,25 @@ public void test13_secp521r1() throws Exception
         implTestECDSACredentials("TLSv1.3", NamedGroup.secp521r1);
     }
 
+    /*
+     * RFC 8446 4.2.7: "supported_groups" applies only to key exchange; signature algorithms are
+     * negotiated independently. Restricting the named groups to a set with no ECDSA-capable curve
+     * must not prevent the use of ECDSA credentials in TLS 1.3.
+     */
+    public void test13_brainpoolP256r1tls13_x25519Only() throws Exception
+    {
+        System.setProperty(PROPERTY_NAMED_GROUPS, "x25519");
+
+        implTestECDSACredentials("TLSv1.3", NamedGroup.brainpoolP256r1tls13);
+    }
+
+    public void test13_secp256r1_x25519Only() throws Exception
+    {
+        System.setProperty(PROPERTY_NAMED_GROUPS, "x25519");
+
+        implTestECDSACredentials("TLSv1.3", NamedGroup.secp256r1);
+    }
+
     private void implTestECDSACredentials(String protocol, int namedGroup) throws Exception
     {
         char[] keyPass = "keyPassword".toCharArray();