Hi Anders,
I would like to have look at the COSE/JOSE specs. If it is convenient to you,
any suggestions about where I could start from? RFC 8812? Do you know where
(areas and products) the COSE/JOSE specs are used in practice?
Thanks,
Xuelei
> On Mar 25, 2022, at 11:56 AM, Anders Rundgren <anders.rundgren....@gmail.com>
> 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 introduce new algorithms want to
> overload RFC 8037 which defines a key type OKP.
> I'm not in favor of this idea since breaks existing OKP code.
> I'm suggesting that each new crypto system should get its own name space and
> thus long-term corresponding Java interfaces.
>
> Since this is happening NOW and there is no turning back, it would be useful
> to get some early feedback from the 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 "construct and EC key", do you mean creating an EC key from
>>>> an existing set of values via PKCS8 or X509 encoding? Or are you
>>>> talking about EC key generation?
>>>
>>> I was talking about creating keys from parameter data supplied by for
>>> example JOSE:
>>> {
>>> "kty": "EC",
>>> "crv": "P-256",
>>> "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU",
>>> "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg"
>>> }
>>>
>>> Apparently this particular issue have solution (as Michael StJohns
>>> showed), although it is not particularity intuitive as well as
>>> undocumented.
>>>
>>> Another take on this issue:
>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/Key.html#getEncoded()
>>>
>>> "Returns the key in its primary encoding format, or null if this key
>>> does not support encoding"
>>>
>>> With COSE/JOSE there is no longer an obvious primary encoding format.
>> Of course there is. You may not like that it's not COSE or JOSE, but
>> the encoding spec remains as is and 10s of 1000s of implementations that
>> use that encoding would be annoyed if you tried to claim a new "primary
>> encoding format".
>> The SubjectPublicKeyInfo encoding for PublicKeys, the PKCS8 encoding for
>> private keys, and RAW encoding for SecretKeys is what's there and I'm
>> pretty sure won't change. I occasionally wished for a getEncoded()
>> method that took an encoding type as an argument (e.g.
>> getEncoded("bareXY") or some such), but that's not in the API.
>> What I'd suggest is that you write a JEP for adding EncodedKeySpec
>> classes for COSE and JOSE to the API. I'd probably also add a
>> GenericKeyEncodingSpec class. That should be simple enough as a first step.
>> The second step would be to write and contribute a Jose and Cose
>> KeyFactory implementation that uses those classes.
>> As I noted, it should be possible to externalize any preferred encoding
>> by using the getKeySpec method of KeyFactory rather than just the key
>> types default encoding.
>> Later, Mike
>>>
>>> Anders
>>>
>>>>
>>>> Tony
>
>
