fixed creation of temp dir, relates to github #1246.

update for releasenotes for dnQualifier.

Author: dghgit

docs/releasenotes.html

@@ -49,6 +49,7 @@ <h3>2.1.2 Defects Fixed</h3>
 <li>JceOpenSSLPKCS8DecryptorProviderBuilder cast the PBES2 key-derivation-function parameters blind to PBKDF2Params, so an EncryptedPrivateKeyInfo whose KDF inside PBES2 was scrypt (RFC 7914, e.g. anything produced by "openssl pkcs8 -topk8 -scrypt") failed to decrypt with "DLSequence cannot be cast to PBKDF2Params". The builder now dispatches on the KDF algorithm OID: id-PBKDF2 takes the existing PBKDF2 path, id-scrypt parses the parameters as ScryptParams and derives the key via SCrypt.generate (the password is encoded as UTF-8 to match OpenSSL's raw-bytes treatment). PBKDF2-based PBES2, PKCS#5 PBES1 and PKCS#12 PBE paths are unchanged (issue #400).</li>
 <li>RFC3280CertPathUtilities.processCRLB2 (in both prov and pkix) emitted an opaque AnnotatedException "No match for certificate CRL issuing distribution point name to cRLIssuer CRL distribution point." when the CRL's issuingDistributionPoint did not match the cert's CRL distribution point names, with no way for an operator to tell which CRL had been returned for which DP. The message now appends both name lists, e.g. ". cert DP names: [6: http://crl3.example/foo.crl, 6: http://crl4.example/foo.crl]; CRL IDP names: [6: http://crl4.example/bar.crl]", letting the cause of the mismatch be diagnosed without re-running with extra logging. Existing assertion sites in NistCertPathTest / NistCertPathTest2 / PKITSTest were updated to use prefix-matching against the original message (issue #800).</li>
 <li>JceInputDecryptorProviderBuilder previously assumed the supplied AlgorithmIdentifier parameters were either an ASN1OctetString (raw IV) or GOST28147Parameters, so init() failed with "DLSequence cannot be cast to ASN1ObjectIdentifier" (via the GOST fallback) on an AES-GCM (or AES-CCM) AlgorithmIdentifier carrying GCMParameters / CCMParameters. The builder now dispatches on the algorithm OID: id-aes{128,192,256}-GCM and id-aes{128,192,256}-CCM parse the parameters as GCMParameters / CCMParameters and init the cipher via GCMParameterSpec(icvLen*8, nonce); the existing IV and GOST paths are unchanged (issue #1510).</li>
+<li>BCStyle and RFC4519Style now accept "DN", "DNQ" and "dnQualifier" as parser aliases for the dnQualifier attribute (OID 2.5.4.46), so new X500Name(principal.toString()) round-trips when the underlying JDK stringifies the attribute using any of those short forms (issue #1622).</li>
 <li>Six S/MIME content-handler classes in the bcjmail tree (org.bouncycastle.mail.smime.handlers.{multipart_signed, PKCS7ContentHandler, pkcs7_mime, pkcs7_signature, x_pkcs7_mime, x_pkcs7_signature}) each carried a leftover "import java.awt.datatransfer.DataFlavor;" line that survived the migration to Jakarta Activation 2.x. The import was unused — every reference in the migrated code routes through jakarta.activation.ActivationDataFlavor, which in Jakarta Activation 2.x is a standalone class that no longer extends java.awt.datatransfer.DataFlavor. The stale imports nevertheless forced Android (and other awt-less JVMs) to pull a non-existent class onto the classpath at load time. The imports have been removed; the bcjmail tree now has zero java.awt references across both main and test sources, so Android consumers using bcjmail with a Jakarta Activation 2.x runtime (e.g. Eclipse Angus Activation) no longer need a DataFlavor shim. Note that the legacy bcmail tree (javax.mail / javax.activation 1.x) cannot be cleaned up the same way: legacy javax.activation.ActivationDataFlavor extends java.awt.datatransfer.DataFlavor by upstream contract and the javax.activation.DataContentHandler interface methods take DataFlavor parameters — Android users should consume bcjmail, not bcmail (issue #242).</li>
 <li>CMS EnvelopedData with a BSI TR-03111 ECKA-EG-X963KDF key agreement (BSIObjectIdentifiers.ecka_eg_X963kdf_SHA1/SHA224/SHA256/SHA384/SHA512/RIPEMD160) failed both encode and decode: JceKeyAgreeRecipientInfoGenerator threw "Unknown key agreement algorithm" on generate, and JceKeyAgreeRecipient's parallel branch silently fell through to a null UserKeyingMaterialSpec, producing the wrong shared secret and "checksum failed" on the AES key unwrap. The underlying agreement (ECDHBasicAgreement + KDF2BytesGenerator) is structurally identical to dhSinglePass_stdDH_*kdf_scheme, and BSI TR-03109-3 / ICAO 9303-11 — the canonical consumers of ECKA-EG-in-CMS — specify the RFC 5753 ECC-CMS-SharedInfo format for the KDF input. The six BSI ecka_eg_X963kdf_* OIDs have been added to the EC dispatch table in CMSUtils so both encode and decode route through the existing RFC 5753 KeyMaterialGenerator (issue #790).</li>
 <li>BLS12_381Aggregation.aggregateVerifyHashed previously fed the per-signer (pk_i, H(msg_i)) pairs straight into the multi-pairing, omitting the per-message public-key aggregation and identity-rejection step required by draft-irtf-cfrg-bls-signature §2.9 lines 12-13. An attacker who controlled pk_a and pk_b = -pk_a (each with a valid PoP, since they hold both secret keys) could publish an aggregate over (pk_a, m), (pk_b, m), (pk_c, m') whose pk_a / pk_b contributions cancelled in the pairing equation, reducing it to a check of pk_c on m' while the aggregate still ostensibly claimed contributions from pk_a and pk_b. BLS12_381BasicScheme.aggregateVerify pre-screened by rejecting duplicate messages and BLS12_381MessageAugmentation folded the public key into the hash input so the spec grouping was trivial, but BLS12_381ProofOfPossession.aggregateVerify took the unmodified helper path. The shared helper now groups signers by hashed message, sums the public keys per group, and rejects the aggregate when any per-group key equals the G1 identity (the spec form for §2.9); all three schemes inherit the check.</li>

pkix/src/test/java/org/bouncycastle/tsp/test/ERSTest.java

@@ -7,6 +7,7 @@
 import java.io.IOException;
 import java.io.OutputStream;
 import java.math.BigInteger;
+import java.nio.file.Files;
 import java.security.KeyPair;
 import java.security.MessageDigest;
 import java.security.NoSuchAlgorithmException;
@@ -1130,9 +1131,8 @@ public void test4NodeBuild()
     public void testDirUtil()
         throws Exception
     {
-        File rootDir = File.createTempFile("ers", ".dir");
-        rootDir.delete();
-        if (rootDir.mkdir())
+        File rootDir = Files.createTempDirectory("ers.dir").toFile();
+        try
         {
             DigestCalculatorProvider digestCalculatorProvider = new JcaDigestCalculatorProviderBuilder().build();
             DigestCalculator digestCalculator = digestCalculatorProvider.get(new AlgorithmIdentifier(NISTObjectIdentifiers.id_sha256));
@@ -1173,12 +1173,10 @@ public void testDirUtil()
 
             assertTrue(Arrays.areEqual(Hex.decode("98fbf91c1aebdfec514d4a76532ec95f27ebcf4c8b6f7e2947afcbbfe7084cd4"),
                 tspReq.getMessageImprintDigest()));
-
-            deleteDirectory(rootDir);
         }
-        else
+        finally
         {
-            throw new Exception("can't create temp dir");
+            deleteDirectory(rootDir);
         }
     }