--
*Von:* Anthony Scarpino mailto:anthony.scarp...@oracle.com>>
*Gesendet:* Monday, March 28, 2022 6:31:29 AM
*An:* Anders Rundgren mailto:anders.rundgren@gmail.com&
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 certific
ds,
Anders
Thanks,
Xuelei
On Mar 25, 2022, at 11:56 AM, Anders Rundgren
wrote:
Hi Michael & the JDK crypto team,
Although it might be cool writing a JEP it is not really my job. There are
also multiple ways of addressing this issue.
BTW, the COSE/JOSE folks who are about to introduc
JDK folks. In fact, this is the origin of
this request.
It seems that nobody representing JDK crypto is involved in COSE/JOSE.
Thanx,
Anders
On 2022-03-25 18:23, Michael StJohns wrote:
On 3/25/2022 12:33 PM, Anders Rundgren wrote:
On 2022-03-25 17:12, Anthony Scarpino wrote:
When you say
JDK folks. In fact, this is the origin of
this request.
It seems that nobody representing JDK crypto is involved in COSE/JOSE.
Thanx,
Anders
On 2022-03-25 18:23, Michael StJohns wrote:
On 3/25/2022 12:33 PM, Anders Rundgren wrote:
On 2022-03-25 17:12, Anthony Scarpino wrote:
When you say
key does not
support encoding"
With COSE/JOSE there is no longer an obvious primary encoding format.
Anders
Tony
On 3/25/22 1:03 AM, Anders Rundgren wrote:
Hi Mike & the JDK crypto team,
What I'm saying is that key serialization in Java haven't gotten enough
attention. Exam
ds,
Anders
On 2022-03-25 3:12, Michael StJohns wrote:
On 3/24/2022 12:28 PM, Anders Rundgren wrote:
On 2022-03-24 16:59, Michael StJohns wrote:
On 3/24/2022 2:46 AM, Anders Rundgren wrote:
Hi List,
I find it a bit strange that every user of crypto either have to write
or install specific soft
On 2022-03-24 17:27, xueleifan(XueleiFan) wrote:
On Mar 23, 2022, at 11:46 PM, Anders Rundgren
wrote:
Hi List,
I find it a bit strange that every user of crypto either have to write or
install specific software for converting JOSE/COSE/PEM keys back-and-forth to
Java's int
On 2022-03-24 16:59, Michael StJohns wrote:
On 3/24/2022 2:46 AM, Anders Rundgren wrote:
Hi List,
I find it a bit strange that every user of crypto either have to write
or install specific software for converting JOSE/COSE/PEM keys
back-and-forth to Java's internal representation. This re
Hi List,
I find it a bit strange that every user of crypto either have to write or
install specific software for converting JOSE/COSE/PEM keys back-and-forth to
Java's internal representation. This reduces the value of the abstract types as
well.
Now there is whole bunch of new algorithms com
Apparently there was a bug in BC. The GitHub issue has been updated.
Case dismissed :)
thanx,
Anders
On 2021-11-25 4:10, Wei-Jun Wang wrote:
On Nov 24, 2021, at 11:14 AM, Anders Rundgren
wrote:
Hi List,
Although this bug is for BC, I believe the problem is rather in JDK 17:
https
Hi List,
Although this bug is for BC, I believe the problem is rather in JDK 17:
https://github.com/bcgit/bc-java/issues/823#issuecomment-977919380
Thanx,
Anders
Since the JDK bug report tool does not include "keytool" I posted this here.
I believe I saw this a decade ago but it still looks like a bug, albeit a very
minor one :)
SEQUENCE {
OBJECT IDENTIFIER basicConstraints (2.5.29.19)
BOOLEAN true
OCTET STRING, encapsulates {
On 2021-02-01 16:01, Wei-Jun Wang wrote:
On Feb 1, 2021, at 2:32 AM, Anders Rundgren
wrote:
On 2021-01-31 20:00, Wei-Jun Wang wrote:
https://bugs.openjdk.java.net/browse/JDK-8260693 filed.
Thanx!
In the bug report you also write:
We'll also need a way to generate this ki
a key container attestation key for
*all* CSRs which is a more useful method than self-signed CSRs.
Regards,
Anders
Thanks,
Max
On Jan 31, 2021, at 2:12 AM, Anders Rundgren
wrote:
Since the JDK bug report tool does not include "keytool" I posted this here.
Keytool for JDK 15 r
Since the JDK bug report tool does not include "keytool" I posted this here.
Keytool for JDK 15 reports "Subject Public Key Algorithm: XDH key of unknown
size" for a certificate containing the following public key:
148: SEQUENCE {
150: SEQUENCE {
152: OBJECT IDENTIFIER X255
On 2020-09-08 22:05, Anthony Scarpino wrote:
On 9/8/20 11:42 AM, Anders Rundgren wrote:
On 2020-09-08 19:29, Anthony Scarpino wrote:
On 8/30/20 9:51 AM, Anders Rundgren wrote:
Hi,
This applies to JDK 11.
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/interfaces
On 2020-09-08 19:29, Anthony Scarpino wrote:
On 8/30/20 9:51 AM, Anders Rundgren wrote:
Hi,
This applies to JDK 11.
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/interfaces/XECKey.html
what is the value of "AlgorithmParameterSpec"?
In JDK 15 the new E
Being an early adopter has its challenges...
https://github.com/cyberphone/openkeystore/blob/master/library/test/org/webpki/crypto/Jdk15XdhSerializationBug.java
This test program verifies that JDK 11 - JDK 15 according to section 3 of
RFC 8410 incorrectly add an ASN.1 "NULL" to the AlgorithmI
keystore/blob/427f65df6eb26e9150a1aefd6f0abf3abe761e91/library/src/org/webpki/crypto/CryptoUtil.java#L59
Thanx,
Anders
On 2020-08-31 20:38, Michael StJohns wrote:
On 8/31/2020 2:00 PM, Anthony Scarpino wrote:
On 8/31/20 8:16 AM, Anders Rundgren wrote:
On
https://tools.ietf.org/html/rfc8032#page-24
you can find test vec
On
https://tools.ietf.org/html/rfc8032#page-24
you can find test vectors that are also used by rfc8037 (JOSE).
However, there seems to be no information on how to create an EdDSA public key
from such a vector.
Apparently you must be an expert on the inner workings of EdDSA in order to use
this
Hi,
This applies to JDK 11.
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/interfaces/XECKey.html
what is the value of "AlgorithmParameterSpec"?
In JDK 15 the new EdECKey has gotten a more logical solution:
https://download.java.net/java/early_access/jdk15/docs/api/ja
The RFC8410 author claims that the public key featured in the "self-issued"
certificate is NOT related to the signature key.
The answer to my question is thus (?) that "Signature" should (as BC does)
reject X25519 keys.
All is good :-)
Anders
On 2020-08-28 16:07, Anders
25519
signature keys. Probably for a reason.
Regards,
Anders
—Max
On Aug 28, 2020, at 9:55 AM, Anders Rundgren
wrote:
On 2020-08-28 15:41, Weijun Wang wrote:
What version of java are you using and what’s your command to generate the key
pair?
Hi Max,
While waiting for JDK 15, I'm
x
On Aug 28, 2020, at 7:03 AM, Anders Rundgren
wrote:
Hi Crypto Experts,
Please pardon my ignorance regarding curve25519, but I ran into problems [*]
trying to recreate the sample certificate:
https://tools.ietf.org/html/rfc8410#section-10.2
It seems that the certificate is signed wit
;Signature" object supposed to accept X25519 keys?
Personally I don't see any use of a self-signed encryption certificate so maybe
this is just a bad example...kind of edge case.
Regards,
Anders Rundgren
*] java.security.InvalidKeyException: cannot identify EdDSA private key
The command
keytool -genkeypair -keyalg ec -keysize 256 -dname "CN=me" -keystore mycert.jks
using JDK 11 generates the following signature:
220: SEQUENCE
{
222: OBJECT IDENTIFIER ecdsa-with-Sha256 (1.2.840.10045.4.3.2)
232: NULL
}
234: BIT STRING, en
Hi JDK maintainers,
I must admit that I know very little about the policies for backporting and
upgrading LTS versions of JDK but EdDSA is mainstream these days.
https://openjdk.java.net/jeps/339
Any suggestions would be welcome!
thanx,
Anders
On 2018-05-01 17:21, Adam Petcher wrote:
The work for X25519/X448 is wrapping up[1], so I have started thinking
about EdDSA. Please review the draft JEP[2] for EdDSA, and let me know
what you think. I'm not really sure what priority to give the EdDSA
work, and it is optional in TLS 1.3. So if you
ly or through a super interface.
The existing Nashorn method (after upgrade to match ES better) moved to the
Java layer would probably be just fine.
Anders
-Sundar
On 29/01/18, 7:45 PM, Anders Rundgren wrote:
On 2018-01-29 14:52, Hannes Wallnöfer wrote:
Hi Anders,
I think I lack the co
html
https://cyberphone.github.io/doc/security/jose-jef.html
Thanx,
Anders
Thanks,
Hannes
Am 28.01.2018 um 10:48 schrieb Anders Rundgren :
The JSON "clear text" signature initiative seems to (finally) be headed for
IETF standardization. The plan is having a BOF session at the
The JSON "clear text" signature initiative seems to (finally) be headed for
IETF standardization. The plan is having a BOF session at the next IETF in London.
This scheme builds on EcmaScript JSON processing rules for data normalization
which only rely on JSON.parse() and JSON.stringify().
A
On 2018-01-03 17:26, Adam Petcher wrote:
Since this is quite similar to what I proposed some 6 month ago
https://github.com/cyberphone/java-cfrg-spec
I can only give it a +100 :-)
Cheers,
Anders
now looking forward to the signature support.
Now that the JEP[1] for X25519/X448 key agreement is
indows itself deals with smart cards.
My former colleges at PrimeKey AB used PKCS #11 for all their Java applications
for higher flexibility.
HTH
Anders
Jason
____
From: Anders Rundgren
Sent: Friday, December 1, 2017 11:53 PM
To: Bernd Eckenfels; Jason Meh
Unfortunately this is a part of the underlying implementation.
Assuming you use PKCS #11, you could take a look at the code and see what it
does with an externally supplied password.
Anders
On 2017-12-01 23:08, Bernd Eckenfels wrote:
Hm, I remember I had a problem the other way around: I coul
On 2017-09-21 17:25, Adam Petcher wrote:
I would like to leave this open for feedback for another week or so.
Please reply with your comments by Saturday, September 30, end of day,
anywhere on earth. After that time, I plan to move on to the next phase
of the process (group lead and architect rev
Does this mean that the following is correct?
EC public key:
public interface ECPublicKey
extends PublicKey, ECKey
CFRG/RFC 7748 public key:
public class TheActualImplememtationClass
extends PublicKey, ByteArrayKey
If so, it should work. Documentation seems a bit less obvious though
which i
Hi Guys,
whatever you come up with I anticipate it comes with descriptions
of how to use it as well. I would recommend putting the JEP on GitHub
(although this may not be the usual process), since this topic have
bearings on other crypto APIs in the workings.
I really hope that the end-result wi
On 2017-08-08 21:42, Xuelei Fan wrote:
On 8/8/2017 8:45 AM, Anders Rundgren wrote:
Object myOwnEncrypt(PublicKey publicKey) throws SecurityException {
if (publicKey instanceof RSAKey) {
// RSA
} else {
// It should be EC
}
}
The code above is not reliable unless
On 2017-08-08 17:25, Adam Petcher wrote:
It sounds like what you are saying is
that I will need something like XDHPublicKey and XDHPrivateKey in
java.security.interfaces. Can you tell me why? What is it that we can't
do without these interfaces?
Every JOSE Java library I have seen constructs a
On 2017-08-07 23:52, Michael StJohns wrote:
On 8/7/2017 4:37 PM, Adam Petcher wrote:
These two assumptions greatly simplify the API. We won't need classes
that mirror ECParameterSpec, EllipticCurve, ECPoint, ECField,
ECPublicKey, etc. for X25519/X448.
That assumption holds only if your vario
This may not sound like a security related issue but it actually is...
Although entirely uncoordinated, there are several "standards" in the workings
based on creating JSON-based clear text alternatives to IETF's JWS signature scheme
(which encodes data in Base64Url).
All of these schemes shar
On 2017-08-04 21:33, Michael StJohns wrote:
On 8/4/2017 3:05 PM, Anders Rundgren wrote:
https://lists.oasis-open.org/archives/pkcs11/201708/msg6.html
C'mon (Oracle) Guys, what's *your* plan; is JDK open source or not? :-)
Yeah, I know that open source <> open ideas but t
https://lists.oasis-open.org/archives/pkcs11/201708/msg6.html
C'mon (Oracle) Guys, what's *your* plan; is JDK open source or not? :-)
Yeah, I know that open source <> open ideas but the world needs a direction.
Feel completely free dismissing OKP, it is the silence that's killing us.
Cheers
https://mailarchive.ietf.org/arch/msg/curdle/GVHazpHuUxq5H7PShB0AFE8DQZI
Jim Schaad is one of the leading cryptographers in IETF.
Anders
Recently upgraded: https://github.com/cyberphone/java-cfrg-spec
Highly related to https://github.com/cyberphone/java-cfrg-spec (no takers?)
is the fact that quite a lot of code out there depend on
org.bouncycastle.jce.spec.ECNamedCurveSpec
Are there any plans to create a "true" java version of ECNamedCurveSpec or are we stuck
with "workarounds":
https://sta
about private key serialization :-)
Anders
On 2017-06-26 23:44, Michael StJohns wrote:
Inline.
On 6/26/2017 2:56 PM, Anders Rundgren wrote:
On 2017-06-26 17:58, Michael StJohns wrote:
Umm... SHOULD is not a MUST - JDK8 does comply with the RFC, it just
doesn't provide the "conveni
On 2017-06-26 17:58, Michael StJohns wrote:
On 6/25/2017 2:21 AM, Anders Rundgren wrote:
During the work with https://github.com/cyberphone/java-cfrg-spec I had to look
at the PKCS #8 spec as well.
It turns out that JDK 8 does not comply with RFC 5915's SHOULD since EC private
keys creat
During the work with https://github.com/cyberphone/java-cfrg-spec I had to look
at the PKCS #8 spec as well.
It turns out that JDK 8 does not comply with RFC 5915's SHOULD since EC private
keys created by KeyPairGenerator do not contain public key info when
getEncoded().
I didn't check PKCS #8
I turned this topic into a separate GitHub repository instead of a BC issue
(which it really isn't). I would be very happy to get some feedback on this
proposal, including pull requests.
There's a certain urgency, since the BC implementation is just about to start,
while I guess Oracle is targ
The COSE draft also refers to "OKP" keys:
https://tools.ietf.org/html/draft-ietf-cose-msg-24
which in my opinion speaks for separating the CFRG algorithms from EC.
OKP keys have as far as I can tell (I'm not a cryptographer, just an applier of
cryptography), no ECPoint, coFactor, and ECField an
On 2017-06-21 17:31, Adam Petcher wrote:
On 6/21/2017 11:20 AM, Anders Rundgren wrote:
Thanx, but at this stage I'm mainly concerned about the specification.
Is the specification also supposed to be created in the issue above?
There is a JEP in development for RFC 7748, and I expect th
https://github.com/bcgit/bc-java/issues/193#issuecomment-309183825
Regards,
Sean.
On 20/06/17 21:32, Anders Rundgren wrote:
Hi List,
I'm an long time user of Java and JCE.
I've just begun looking into the recently standardized curve25519 crypto.
Since I didn't find any JEP or JSR for thi
ues/193#issuecomment-309183825
WDYT?
Thanx,
Anders Rundgren,
Co-inventor of signed JavaScript/JSON objects:
https://cyberphone.github.io/doc/security/jcs.html
tedCurves")
> .split("\\|");
> for (String curve : curves) {
> System.out.println(curve.substring(1, curve.indexOf(",")));
> }
>
>
>
>
> On 8 Oct 2013, at 13:53, Anders Rundgren wrote:
>
>> If you have the X a
se a serialized named
ECPublicKey in JDK 7 uses a different (and IMHO incorrect) format which
makes it impossible to sign a public key in an interoperable way.
Note: I used Oracle's JDK 7 on Windows but I assume it is the same for OpenJDK.
thanx
Anders Rundgren
>
>
>
>
> On 8 O
)));
> }
Thanx Vicent,
I guess this is new for JDK 7.
Unfortunately I seem to be stuck with BC because a serialized named
ECPublicKey in JDK 7 uses a different (and IMHO incorrect) format which
makes it impossible to sign a public key in an interoperable way.
Note: I used Oracle
If you have the X and Y points and the name of a public key you can create a
ECPublicKey using BouncyCastle.
I cannot find any counterpart in JDK 7. What am I missing?
BC:
return KeyFactory.getInstance ("EC").generatePublic (new ECPublicKeySpec (new
ECPoint (x, y), new ECNamedCurveSpec (name,.
58 matches
Mail list logo
