Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v3]

The change does not seem to be related to your description, and the description does not match the shown exception. In fact the example stacktrace contains the authority value twice and your change adds a diagnostic which is not really helpful for the case of the underscore? I would not be too

Re: [openjdk/jdk] JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider (PR #8211)

Hello, > Correct, it does enable access to certificates and keys that require next > (second) generation, That’s strange, I am quite sure I tried CNG RSA and EC Keys after OpenJDK claimed to support it. So maybe there is more than one condition to it (or the handle just works transparently

Re: zlib before 1.2.12 allows memory corruption (CVE-2018-25032)

Hello Vitaly, (Personal answer not affiliated with OpenJDK members) I had also asked about this before, but there was no answer (which is however not surprising, since it is the policy of OpenJDK and Oracle to not comment on unfixed security issues). My hope was, that by reporting it before

Re: CVE-2022-21449: Psychic Signatures in Java

Hello Michael, thanks for the pointer, interesting read. I think the key takeaway from that discussion is, that the Wycheproof Testcases would have catched this problem and should probably be added to the OpenJDK tests. (I wonder, does Google not run those in qualification builds?) The

Re: A possible JEP to replace SecurityManager after JEP 411

Just to add to the discussion some more, as I understand it the new (Graal based?) multi language environment running inside a Oracle database is exactly what others want to do here: multimtenant untrusted code execution inside a bigger application. There are a number of complications here,

Re: A possible JEP to replace SecurityManager after JEP 411

Hello, I dont agree with the statement that this can be solved on higher level. (Unless higher level means move away from existing architectures which is perfectly fine for some workloads but not for all) IMHO Infrastructure to enforce on lower level is needed either for traditional

Re: JEP Review Request: TLS Certificate Compression

Hello, For multiple connections session- or ticket reuse would be much more efficient. In fact I think cert compression looks like the wrong solution. Having a immutable certificate download Chain would be a cool alternative solution - especially with future large postquantumcrypto

Re: Proposal: Extend Windows KeyStore support to include access to the local machine location

://bernd.eckenfels.net From: Wei-Jun Wang Sent: Monday, April 11, 2022 8:45:12 PM To: Mat Carter Cc: Bernd Eckenfels ; security-dev@openjdk.java.net Subject: Re: Proposal: Extend Windows KeyStore support to include access to the local machine location Sorry for the late

Re: A possible JEP to replace SecurityManager after JEP 411

Hello, I think this proposal be very powerful, it allows completely new models (like custom sandboxed VMs) while still removing many of the complicated classes. I am all for it, but it does limit the actual work saved since the doPriveleged and checkPermission sites are the thing which is the

Re: Proposal: Extend Windows KeyStore support to include access to the local machine location

BTW, since this is Windows specific anyway and since we have also a combining virtual Keystore, why not allow a new naming scheme which allows to access any of the Keystores? like “Windows-ROOT/ADdressbook”? Gruss Bernd -- http://bernd.eckenfels.net Von:

Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA

://bernd.eckenfels.net Von: Anthony Scarpino Gesendet: Monday, March 28, 2022 6:31:29 AM An: Anders Rundgren Cc: Bernd Eckenfels ; security-dev@openjdk.java.net Betreff: Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA Thanks for all the info. We

Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA

Just for completeness, the standard for key transport in JOSE is JWK (RFC7517). In COSE it is a COSE_Key(Set) as defined in RFC8152 sect13. BTW the most widely used CBOR/COSE application are probably the QR codes around Covid and Vaccination certificates of the EU. Gruss Bernd --

Re: RFR: 8282279: Interpret case-insensitive string locale independently

The last replace seems a bit strange, I would expect it should first normalize the case and then the hyphen, otherwise it won’t match the replace? Looks to me like not using toUpperCase in the trace messages would be more efficient and produces shorter code. Isn’t it customary to use the ROOT

Why no JNDI de-ser killswitch

Hello, I can understand that ldapcontext.lookup() still has to use unsafe deserialisation for legacy reasons (JMS factories etc). But it would be really good if there would be a bit more infra like a killswitch or url-prefix filter JNDI for those who don’t need that. It was a rather damaging

Re: previously prevented exploit now possible with JDK 18

Rick if you fear an attacker can modify and install a JAR with a broken signature which you don’t trust anyway, what should stop the attacker to provide a valid but untrusted signature or no checksums at all? It might be a undesirable change for your case but I see no trustmodel where you would

Re: Understanding elliptic curve spec limitations

This should also answer your other Question, if you Register a Provider (like bouncycastle) it should actually provide such curves via the JCE interface. I am not Aware of Bugs in this area (but on the other Hand besides some stupid EA-agency requirements for brainpool curves nobody in their Right

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

Hello, sorry for being unpopular, but I just hate it to waste developer resources, I realy think this deprecation message should be re-considered, it broke a lot of things, the amount of work to implement a caching solution feels like a waste of time and on top of it, there is no clear

Re: JDK 17 EA build 26 - Better debuggability of SecurityManager WARNING messages?

Is it possible to redirect those vm messages with unified logging or vm-error files or similar command line flags to the launcher to keep stdout/stderr clean? Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Sean Mullan Gesendet:

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

Hello, I have to agree with Peter here, we do remove a very valuable asset of the JVM platform. It might not easy to be used and not the most popular technology, but after all it was in the DNA of Java. In this JEP/Discussion there is not a single hesitation to remove it. Please tell me you

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

Just to add another point to this. Today it is quite hard to use operating system facilities like chroot/jails, security tokens, seteuid, dropping priveledges or switching Security tokens which would allow to limit or escalate priveledges in an OS enforced manor. If we would have a bit more

Re: How do I report a potential bug in OpenJDK?

It is nest to post the verbatim error message and maybe also the URL to reproduce. But if you notice a sudden change in behavior and the cert is not expired, then it’s likely a server-side change. Did you try to connect with browser and OpenSSl cli? You can debug JSSE connections but the

Re: RFR: 8264208: Console charset API [v2]

Hello, I like the API, it is useful, however not enough to replace the defaultCharset once the Change to UTF8 is done. You still need a way to query the platforms file encoding (especially on Windows). Also I wonder if the Javadoc needs to discuss platform aspects of console, especially

Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys

Hello, I agree with the need for such a facility. Instead, or in addition to a key log a session handshake listener with access to the handshake result (and the master key) would also be useful for auditing, renegotiation limiting and key logging. It can even be used for things like priming

Re: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module

Hello, Actually, in HTML was a separator, and in xhtml it should enclose paragraphs. However I was under the impression Javadoc always used the separator style (it would be strange to start the first sentence in Javadoc with . Is this doccheck enforcing a new policy? This officially Oracle

Re: RFR: 8217633: Configurable extensions with system properties [v2]

Hello, I wanted to mention again, that all those System property configurations are good, especially to resolve the update pains, but not really useful if you want to make configurations on a per-connection base. If you have to support multiple partners it can be a real pain to setup a common

Re: Java and the NTFS Path weakness

Hello Alan, I don’t think this is a Java vulnerability (but something Java application programmers have to deal with), that’s why I sent it to the mailing list (for lack of better channels). Still there is a lesson to learn, we have two different windows file Name parsing behaviors in the

Re: RFR: 8257769: Cipher.getParameters() throws NPE for ChaCha20-Poly1305 [v2]

BTW stupid - somewhat related - question, why does the nonce to be parsed out of a DER blob, shouldn’t there be an getter on the Parameter Spec object? Many protocols would need the raw array, is there a matching spec - or should we add one? Gruss Bernd -- http://bernd.eckenfels.net

Re: jar signing and verification

Hello, It is a bit unfortunate but the JCE Codesigning Roots are not part of the cacerts file. They are hardcoded in the Oracle JDK and not present in OpenJDK as far as I understand it. It is documented here, that those CAs are not available for general deployments:

Re: RFR: JDK-8255395 Implement Enhanced Pseudo-Random Number Generators (CSR)

Hello, Not sure if it is needed to implement a new RandumGenerator interface instead of extending SecureRandom, but the extensions and the discovery mechanism looks good. One thing I am wondering about is if reseed() and reseed(Param) should be part of the new RandomGenerator interface as

Re: Please add HMAC keygen to SunPKCS11

Hello, I would agree with this request, my usecase would be to use a HSM, where I typically don’t want to import keys but generate them safely on the HSM so not even admins have access to the key material ever (besides maybe having a key handle to wrap it). Isn’t that what the KeyGen

Re: SSLSocket HandshakeCompletionListener Threading

I agree with that statement as an author of applications which have to connect to a wide range of external systems with a wide range of libraries and components. It should be configurable as a parameter on socket, session or factory level. I find a new API is more than welcome, especially if

Re: [TLS-backport8] Does TLSv1.3 work with www.google.com

Jamil, just a folllw up, I noticed in the bug comets that there are multiple conditions where boringSSL fails, seems like OpenJSSE somehow does not trigger the fingerprint match w/ and w/o status request. Gruss Bernd -- http://bernd.eckenfels.net Von: Bernd

Re: [TLS-backport8] Does TLSv1.3 work with www.google.com

Hello Jamil, Thanks for responding, you are correct, this system property resolves my problem (on both the Oracle as well as Azure JRE). There is however something fishy going on. With the OpenJSSE provider (as provided by Zulu) the default for this option seems to be =true, as the extension

Re: NPE in jarsigner -verify for broken TSA

Hello, Just a little update, after implementing a jarsigner -verify after each sign operation and by retrying signatures when it fails, we could resolve the problem, when signing 50 jars one or two failed with NullPointer and worked after immediate retry. Gruss Bernd --

Re: Browser's accepting certificates that Java does not

Note that many browsers also download certs from the AIA and even "well known" mechanisms. It won't help to access more truststores, that would be a function you need to prove directly. Also the dynamic installation from Windows Updates or offline from crypt32.dll is not triggered when only

KWP instead of AESWrap

Hello, JCE implements the AESWrap cipher, but it's does not offer the KWP mode of NIST 800-38F. KW and KWP use the same wrapping algorithm W which is also used by AESWrap, however do to different initialisation vectors the existing implementation can not be used to implement the padded

Re: [RFR] 8229148: SSLSession.invalidate() does not invalidate stateless tickets

Hello, The change seems reasonable, but should there maybe a method to refresh temporary keys used for those session tokens - I.e. "invalidate all" and link to that so specific implementations are encourages to offer such an API. Gruss Bernd -- http://bernd.eckenfels.net

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

LdapCtxt: 2568 /** 2569 * Sets the read timeout value 2570 */ 2571 private void setChannelBindingType(String cbTypeProp) { Not sure if that javadoc is the right one? And I also wonder if enforcing the timeout is needed, and if yes if it should be documented why. Was not

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Not completely sure about which of the involved apIs have what possible extensions. Maybe we can somehow make two mechanisms one which is the compatible default and one would be the rfc compliant method. Then SASL can be configured and use different mechanism names with a new propert? That

Re: NPE is used in javax.security.auth.Subject for flowcontrol

Hello, I would agree with the interpretation that the NPE is not mandatory. But even if we keep it, the actual problem in addAll() should be fixed? There is no point in calling contains(null) on a SecureSet, right? Gruss Bernd -- http://bernd.eckenfels.net

Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms

Hello Valerie. In MacKAT 121 you would get a NPE if the catch prints the skip message, probably needs an additional return; guard? The BAOS default length change in parse() was not immediately clear to me? (Maybe next s. Base64?) BTW It is good to see that you also add truncated SHA512

Re: [15] RFR: 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property

Hello Sean, Are the separate entries for 3DES and DES needed or can they also be collapsed? BTW i am always unsre about the interactions of setting the Protocol and the enabled ciphers so I am in the habit to set the protocols before using getEnabled or setting enabled ciphers. I guess it

Re: LDAP Channel Binding

Just a small addition, cause I found some more details (but still not enough). there seems to be some precedence for tls-server-endpoint instead, which would be I guess a bit easier to produce:

Re: LDAP Channel Binding

happen by extending GSS-SPNEGO, but that would really be a strange layering of multiple security mechanisms. Gruss Bernd -- http://bernd.eckenfels.net Von: Weijun Wang Gesendet: Dienstag, Februar 18, 2020 3:18 PM An: Bernd Eckenfels Cc: security-dev@openjdk.jav

Re: LDAP Channel Binding

be an additional check condition if the new APIs are enough to handle that. Gruss Bernd -- http://bernd.eckenfels.net Von: Michael Osipov <1983-01...@gmx.net> Gesendet: Sunday, February 16, 2020 11:02:16 AM An: Weijun Wang Cc: Bernd Eckenfels ; securi

Re: LDAP Channel Binding

Von: Michael Osipov <1983-01...@gmx.net> Gesendet: Sonntag, Januar 19, 2020 11:15 AM An: Bernd Eckenfels Cc: security-dev@openjdk.java.net Betreff: Re: LDAP Channel Binding Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels: > You said it is confusing, but the bug you mentione

Re: LDAP Channel Binding

r 19, 2020 11:15 AM An: Bernd Eckenfels Cc: security-dev@openjdk.java.net Betreff: Re: LDAP Channel Binding Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels: > You said it is confusing, but the bug you mentioned is only a valid > feature request, it does not talk about failing binds. I would

Re: LDAP Channel Binding

Von: Michael Osipov <1983-01...@gmx.net> Gesendet: Saturday, January 18, 2020 9:39:08 PM An: Bernd Eckenfels ; security-dev@openjdk.java.net Betreff: Re: LDAP Channel Binding Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels: > Hello, > > Some updates

Re: LDAP Channel Binding

Hello, Some updates: Microsoft moved their automatic update of the LDAP policies in Windows Server updates to March 2020 (but still recommend to activate it earlier). And I did some tests: when you turn on the mandatory LDAP Signing, then simple binds or Digest-md5 binds over LDAP are

Re: Microsoft LDAP Channel Binding

reversible (and a new password must be set). Next will be testing with TLS (and channel binding) once I get the LDAP certificate set up for this. -- http://bernd.eckenfels.net Von: Michael Osipov <1983-01...@gmx.net> Gesendet: Mittwoch, Dezember 18, 2019 6:37 PM An:

Re: Microsoft LDAP Channel Binding

Here is a related bug https://bugs.openjdk.java.net/browse/JDK-8208301 for ADFS. Gruss Bernd -- http://bernd.eckenfels.net Von: Bernd Eckenfels Gesendet: Mittwoch, Dezember 18, 2019 4:29 AM An: security-dev@openjdk.java.net Betreff: Microsoft LDAP Channel

Re: Microsoft LDAP Channel Binding

-kerberos/pull/92 Gruss Bernd -- http://bernd.eckenfels.net Von: Michael Osipov <1983-01...@gmx.net> Gesendet: Mittwoch, Dezember 18, 2019 6:37 PM An: Bernd Eckenfels; security-dev@openjdk.java.net Betreff: Re: Microsoft LDAP Channel Binding Am 2019-12-18 um

Microsoft LDAP Channel Binding

Hello, Microsoft just released an Security Advisory, announcing that upcoming Windows Server Versions will turn on mandatory TLS Channel Binding (and turn off simple binds with mandatory SASL signing) on LDAP Servers. They also reminded Administrators to install the KB patch and turn the

Re: RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB from security requirements

Hello, While it is probably a good thing to not use ECB I can imagine you actually need it to implement single-block operations, so I am not sure if it’s a good idea if any general purpose JVM does not provide AES/ECB or RSA/ECB? (Maybe a new raw single block mode instead?) For example TLS1.2

Re: the GMT timestamp given in the trace is sometimes wrong

It would make sense to no longer calculate and print the timestamp in the debug log if we don’t want it to be relied upon. This would be less missleading (and mopst likely the shifting logic can be removed?) -- http://bernd.eckenfels.net Von: security-dev im

Re: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)"

ter > this brainpool support is integrated, it'll be easier to re-evaluate > these. > > > As for PKCS11, Tobias tested this against a 3rd party PKCS11 library and > the result is positive if I recall correctly. > > > Thanks, > Valerie > > > On 6/18/2018

Re: Request for Review [14] JDK-8226976, SessionTimeOutTests uses == operator for String value check

Also the `is*` prefix would point to a boolean, that’s maybe a cleaner data type than a case sensitive string? -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Xuelei Fan Gesendet: Montag, Juli 1, 2019 6:44 PM An: security-dev@openjdk.java.net

Re: Refresh cacert File?

, April 18, 2019 10:34 AM An: Bernd Eckenfels; jdk8u-...@openjdk.java.net Cc: security-dev@openjdk.java.net Betreff: Re: Refresh cacert File? Hi, On Wed, 2019-04-17 at 22:43 +, Bernd Eckenfels wrote: > hello, > > I think it was discussed on security-dev before but did not result

Refresh cacert File?

hello, I think it was discussed on security-dev before but did not result in some action as far as I understand it. Currently the „cacert“ file shipped with 8u upstream builds is a bit outdated. It contains multiple expired certificates and misses latest additions. Also I noted there are

Re: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE

Hello, There are a few places where a synchronized method is freed up w/o new lock, which is generally a good thing but I wonder if there is a justification available why it is no problem (DTLSInputRecord vs. DTLSOutputRecord). Is the DCL In EphemeralKepair Safe, I am not sure how arrays and

Re: RFR 6722928: Support SSPI as a native GSS-API provider

Just to add another aspect to the discussion, there are at least 3 DLLs out there which implement this functionality (Microsoft’s JDBC driver, jTDS driver and Waffle) + commercial solutions as we have heared. All of them are used to allow authenticating the current user against services (mostly

Re: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy

, JDK-8163326, The default enabled cipher suites should prefer forward secrecy Hi, I extended this CSR to cover more update, and update per the comments. Please let me know your concerns by the end of March 21, 2019. Thanks, Xuelei On 3/6/2019 3:41 PM, Bernd Eckenfels wrote: > I am not cl

Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_)ignoresthe provider argument.

, the FIPS provisions are more sad in that case…) Gruss Bernd -- http://bernd.eckenfels.net Von: Jamil Nimeh Gesendet: Donnerstag, 14. März 2019 18:16 An: Bernd Eckenfels; OpenJDK Dev list Betreff: Re: AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_)ignoresthe provider argument

AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument.

a JCE PBKDF2 on a JVM where BC FIPS has higher prio would be wrong anyway. I thin I havent seen what the case for the init falure in BC MAC was, is this also key related? Gruss Bernd -- http://bernd.eckenfels.net Von: Jamil Nimeh Gesendet: Donnerstag, 14. März 2019 17:18 An: Bernd Eckenfels

Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument.

Looking at the patch it seems obvious that this functionality was intentional at least for having a PKCS11 MAC. Do we really want to removbe that Option and if yes des it require some form of aproval? (I think the change is good in General but that case Needs to be decided). Since this is

Re: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy

I am not clear on what would „preferred in current default context“ mean. Does that mean it preferred the PFS ciphers anyway.. for suggested order in client handshake? as server? And what would be the non-Default context. Is this „TLS“ context? Gruss Bernd -- http://bernd.eckenfels.net

Re: Signed JCE and providers jars

The OpenJDK JCA does not do provider signature checking. So you can install your own providers and don’t need to sign them. Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von David Penick Gesendet: Montag, Februar 4, 2019 11:18 AM An:

Re: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after 8211883

Hello Sean, Maybe you also want to change comment and name of the SUPPORTE_DDEFAULT Array to „SUPPORTED_LIMITED“ since Unlimited is now Default? private final static String[] ENABLED_DEFAULT …. // supported ciphersuites using default JCE policy jurisdiction files // AES/256

Re: 12 RFR(M) 8214583: AccessController.getContext may return wrongvalue after JDK-8212605

In a related matter, are the existing tests reliable to detect the Situation (at least for the Default runtime/compiler behavior). i.e. are the testcases covering stack Evaluation in a compiled context where EA would elimiiminate it? Gruss Bernd -- http://bernd.eckenfels.net Von:

Re: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck"

Maybe a comment should point to the description of this pattern (if it applies): https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5 Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Valerie Peng

Re: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs

Actually I was referring to the property name in the issue, did not notice that the description differs from the patch, sorry. Gruss Bernd -- http://bernd.eckenfels.net

Re: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs

Woha, having a specific property named after an brand looks awfully specific and even hostile. (Yes it can be removed in a future version when all existing certs are expected to expire, but having code patches distributed for such policy enforcement does look like a heavy gun) Won’t it be a

Re: AES ctr benchmark performance

Hello, and to partially answer myself: the UnlockDiagnostics is needed for Java 9+ Gruss Bernd -- http://bernd.eckenfels.net Von: Anthony Scarpino Gesendet: Montag, 3. Dezember 2018 21:37 An: Bernd Eckenfels; security-dev@openjdk.java.net Betreff: Re: AES ctr benchmark performance Very slow

Re: AES ctr benchmark performance

Gesendet: Montag, 3. Dezember 2018 21:37 An: Bernd Eckenfels; security-dev@openjdk.java.net Betreff: Re: AES ctr benchmark performance Very slow.. Roughly 181k ops/sec vs 6100 ops/sec, for 16k datasize. As far as why there is a switch, mostly debugging or possible bugs in hotspot that cause

Re: AES ctr benchmark performance

Quick Question, why did you Need to switch it on and out of curiosity how do the times look like when you switch NI off? Greetings Bernd -- http://bernd.eckenfels.net Von: Anthony Scarpino Gesendet: Montag, 3. Dezember 2018 21:13 An: Kasper Janssens; security-dev@openjdk.java.net Betreff: Re:

Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

Hello, What is the purpose of setting some of them to 0 twice? (It’s a new array which should be all-0 anyway.) + for (int i = 1; i < 9 ; i++) { +subkeyHtbl[2*i] = 0; +subkeyHtbl[2*i+1] = 0; +} Also, is the subkeyH no longer be needed (or can be redesigned

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

int nicer validation reports without relying on the message or Stacktraces. Gruss Bernd -- http://bernd.eckenfels.net Von: Seán Coffey Gesendet: Freitag, November 16, 2018 5:15 PM An: Bernd Eckenfels; security-dev@openjdk.java.net Betreff: Re: RFR: 8213952: Relax DNSName

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

You could also add (a..b, false) and (.a, false), (a., false) to the testcases. I noticed that there are different types of Exception messages (DNS name, DNSName, DNS Name or name constrained, DNS name and SAN), would be good if all of them have the same keyword? Gruss Bernd --

Re: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation

Hello, I would agree ignoring an (conflicting) option adds confusion. When specifying a curve is a new feature we don’t need to worry about beeing compatible, therefore I would forbid mixing curve names and keysize at all (even when the size matches). I guess we cannot remove the option to

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html In checkContext should the security manager be null checked first instead of last to optimize for the typical case? (If the side effects in that expression are desired

Re: Fluent builder API for JCA/JSSE classes

Thats very cool! Maybe this is the right thread to discuss the future of the sun.security.x509 package. Currently your implementation will only work if that package is exported. The Depth of implementation of those classes however would be a nice Addition to an (optional?) API. Gruss Bernd

Re: DSA default algorithm for keytool -genkeypair. Bad choice?

It might not apply to this specific default but in the past DSA was often chosen (over RSA) as a default as it was regarded as less suspicious to been understood as an encryption capable algorithm (as opposed to RSA). But of course that thinking was never correct and the justification for

Re: Jar's CodeSigner null on Java 10, non-null on Java 8

What are the Hashes, signatures algorithms and key Sizes? Maybe one of the newer security properties turning those off? Does it have a timestamp? Gruss Bernd -- http://bernd.eckenfels.net Von: -2123340816m Auftrag von Gesendet: Freitag, Oktober 5, 2018 10:13 PM

Re: Conceptual feedback on new ECC JEP

Hello, I think I missed it, but where is the conversion on BigInteger branching on key material? Isn’t this only branching on effective constant values? Or are you concerned about Spectre-type problems? Besides that I totally agree on the idea of having a more secure implementation which can

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

There is another way, by reusing the existing security manager property with a new keyword („default“ is already a well known value) one could implement the stable suppression of the SM without actually needing a new property. It also avoids unclear meaning of denied but specified SM:

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

Hallo Sean, The change looks fine to me, but if you have to roll another version maybe you could add a comment on this line to explain its purpose. Since this line is changed in the patch it would be a good time: System.java:350 sm.checkPackageAccess("java.lang"); Is that some kind of

Re: PKCS11 generateKeyPair with alias

I would expect you can actually store the key on a PKCS11 backed Keystore, what would be the natural API (although it’s hard for the provider to implement it if it can’t use temporary handles like this) Gruss Bernd -- http://bernd.eckenfels.net Von: -989298816m

Re: JDK-6782021

Hello, What also should be mentioned is that the old CAPI clients cannot access CNG Keys. Which is especially a pity since only the new keys benefit from the cryptographic process isolation (not to mention the confusion that it’s hard to see which provide hosts them) Gruss Bernd Gruss Bernd

Re: RFC: Add new JCA provider to support hardware RNGs

Just a FYI under Linux when you read from urandom the Linux kernel will always XOR with random bytes generated with x64 rdrand instruction (arch_get_random_lomg() - if supported). Since it is a XOR it does not have to trust the quality of this black box hardware implementation. I would not

Re: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)"

Hello, not a Reviewer, but some Questions on the CSR: - Are there other CSRs for including in TLS? - I also wonder if PKI (CA Signatures) will work out of the box then (OID aliases?) - Does PKCS11 require additional changes? (especially for the Government use mentioned in the justification

Zip Slip documentation

Hello, according to Snyk’s Zip Slip vulnerability report (the issue with file Name traversal by extracted Archives) was also sent to Oracle and since Java.util.zip.ZipEntry is a low-Level api the proper Action is changes to the documentation. https://github.com/snyk/zip-slip-vulnerability I

Re: [Sandbox]: ChaCha20 cipher suite prototype

Jamil, I was wandering if you have performance test numbers to share yet? Do you have an internal acceptance criteria for it? Do we expect it to beat unaccelerated AES256-GCM or come close to CBC performance? Gruss Bernd -- http://bernd.eckenfels.net From:

Re: JNLP launched legacy app needs to override jdk.tls.disabledAlgorithms

You probably don’t want to hear that, but now is a good time to convert this JNLP App into a stand alone Installer (possibly with updater).that will not only allow you to ship a pre-configured and matching JRE, but it will also solve the problem that you do not get javaws updates starting on

Re: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016

Hello, Is the following comment correct, it looks like it should read „with NUL terminator“ instead? // without a NULL terminator Greetings Bernd Gruss Bernd -- http://bernd.eckenfels.net From: security-dev on behalf of

SHAKE XOFs

Hello, I noticed that the OASIS draft for extending PKCS#11 with SHA-3 also specifies new Mechanisms for SHAKE128/256. They introduce them as Key Derivation functions. I wonder if this would also be the way to introduce this into JCA, at the moment XOFs have been a non-goal of JEP287, but

Re: Integration and Junit test cases for security

Hello Yogesh, I am not sure it is a good method to learn from those test cases, I would start from here: https://docs.oracle.com/javase/tutorial/security/ But here you go, some of the openjdk included Tests for various security aspects:

Re: Algorithm aliases of SHA-1 in DisabledAlgorithmConstraints

I always thought the logic is ‚case insensitive substring of canonical name‘, so it also works with things like ‚DHE‘ in ciphers. In that case ‚SHA‘ would match SHA-1 as well as SHA-xxx. Gruss Bernd -- http://bernd.eckenfels.net From: security-dev

Re: provider registration

Hello Brad, thanks for the answer. Yes I was talking about the security.provider properties. It is good to know that it wont work with jlink/jmod. The JCA/JCE documentation Looks quite good to follow. A text similiar to this would complete the picture: Note when changing the list of

Re: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations

, do we need tp provide it at all? Gruss Bernd -- http://bernd.eckenfels.net Von: Jamil Nimeh Gesendet: Freitag, 26. Januar 2018 22:57 An: Bernd Eckenfels; OpenJDK Dev list Betreff: Re: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations Hi Bernd, thank you for the feedback! On 01

Re: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations

You Hello, The spec should most likely mention AAD data as well and the 12 Byte size of the nonce. And that the plaintext Limit is in blocks (and the AAD Limit is a 64Bit counter) (And yes there is no wrapping to be found, not even in RFC 8103 which discusses key transport,) Does it need to

  1   2   3   >