Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA
Thanks for all the info. We don’t have experience with JOSE or COSE, I think we
need to digest some of this data before making a future step
Not knowing this technology until you brought it up a few days ago, a few
questions i have are how is this used and how common? Would I see this used
for more secure sites like banks or shopping through the browser or it more
common sites. Is it only browser-based or are their other used cases? Bernd
mentioned QR codes, is COSE used inside the QR code or the authentication for
the user to get to their QR code?
Thanks
Tony
> On Mar 26, 2022, at 11:48 PM, Anders Rundgren
> wrote:
>
> On 2022-03-26 23:14, Bernd Eckenfels wrote:
>> 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.
>
> Thanx Bernd and Michael for the additional clarifications!
>
> Now to the thing that spurred this discussion:
> https://datatracker.ietf.org/doc/html/rfc8037
>
> This document defines how to use the Diffie-Hellman algorithms
> "X25519" and "X448" as well as the signature algorithms "Ed25519" and
> "Ed448" from the IRTF CFRG elliptic curves work in JSON Object
> Signing and Encryption (JOSE).
>
> When RFC 8037 was created the assumption was that the "OKP" key container
> {sh|c}ould be used for other crypto systems having the same parameter set.
> This is now an active proposal:
> https://www.ietf.org/archive/id/draft-looker-cose-bls-key-representations-00.html
>
> Obviously everything works just fine if you look at the container in
> isolation. However, it means that "OKP" encoder/decoder code must be updated
> for every new reuse ("overloading"). To be meaningful these new algorithms
> would also have to coerced into the existing XEC or EdDSA interfaces.
>
> IMO, this would be VERY UNFORTUNATE since it is incompatible with the
> provider concept as well as with object oriented crypto APIs. I'm therefore
> suggesting that key containers for specific crypto systems should have unique
> names. In this particular case "BLS" seems logical. In Java it could
> eventually be mapped to BLSPublicKey and BLSPrivateKey.
>
> WDYT?
>
> There is no need for a JEP at this stage, only some kind of indication of
> what the JDK crypto team see as the best way forward from your horizon. The
> same discussion has emerged for Post Quantum Crypto algorithms.
>
> Thanx,
> Anders
Re: protecting security-sensitive operations on multi-tenant servers
Thanks, Alan. I don't have a lot of visibility into how Derby's security mechanisms are deployed. We only hear from users when they have problems--and we don't field many security-related issues. I will put your advice into our release notes: move your application into a container so that you will be protected when the Security Manager is removed. Thanks, -Rick On 3/27/22 7:22 AM, Alan Bateman wrote: On 27/03/2022 14:45, Rick Hillegas wrote: From the silence, I assume that there isn't any advice I can give Derby users. At this time the Security Manager is the only mechanism for protecting an application against these threats. Users should ignore the deprecation diagnostics and set -Djava.security.manager=allow. I think it's more that the SM was never the right solution for this type of isolation. Also some of the "operations" that you list, creating class loaders, de-registering JDBC drivers, ... suggest there may be potentially malicious code in these environments too. Do you know if these are legacy deployments or Derby users that haven't explored OS containers to isolate applications on the same hardware? -Alan
Re: RFR: 8283727: P11KeyGenerator has import statement with two semicolons after JDK-8267319
On Sun, 27 Mar 2022 13:07:54 GMT, Sean Mullan wrote: > Regarding the bug, the `noreg-self` label is used for fixes to tests. > `noreg-trivial` seems more appropriate for this issue. You're right, I changed this. Thanks also for the review. - PR: https://git.openjdk.java.net/jdk/pull/7976
Re: protecting security-sensitive operations on multi-tenant servers
On 27/03/2022 14:45, Rick Hillegas wrote: From the silence, I assume that there isn't any advice I can give Derby users. At this time the Security Manager is the only mechanism for protecting an application against these threats. Users should ignore the deprecation diagnostics and set -Djava.security.manager=allow. I think it's more that the SM was never the right solution for this type of isolation. Also some of the "operations" that you list, creating class loaders, de-registering JDBC drivers, ... suggest there may be potentially malicious code in these environments too. Do you know if these are legacy deployments or Derby users that haven't explored OS containers to isolate applications on the same hardware? -Alan
Re: protecting security-sensitive operations on multi-tenant servers
From the silence, I assume that there isn't any advice I can give Derby users. At this time the Security Manager is the only mechanism for protecting an application against these threats. Users should ignore the deprecation diagnostics and set -Djava.security.manager=allow. On 3/24/22 2:27 PM, Rick Hillegas wrote: The Apache Derby community is getting ready to vet a new release which can be used on Java 17. Before buttoning down the release, I wanted to check in on current best practices for defending enterprise applications against the threats which the Java Security Manager parries. There may be some work we could do to better prepare our users for a future without a Security Manager. In particular, what are current best Java practices for protecting a multi-tenant server against abuse of the following security-sensitive operations: o Reading and setting of system properties. o Creation of class loaders. o File access o Network access o De-registration of JDBC drivers Thanks, -Rick
Re: RFR: 8283727: P11KeyGenerator has import statement with two semicolons after JDK-8267319
On Sun, 27 Mar 2022 08:48:12 GMT, Christoph Langer wrote: > Remove double semicolon Marked as reviewed by mullan (Reviewer). Regarding the bug, the `noreg-self` label is used for fixes to tests. `noreg-trivial` seems more appropriate for this issue. - PR: https://git.openjdk.java.net/jdk/pull/7976
RFR: 8283727: P11KeyGenerator has import statement with two semicolons after JDK-8267319
Remove double semicolon - Commit messages: - JDK-8283727 Changes: https://git.openjdk.java.net/jdk/pull/7976/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7976&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283727 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7976/head:pull/7976 PR: https://git.openjdk.java.net/jdk/pull/7976
