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

[xueleifan(XueleiFan)]

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.net at 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
> 
>