Re: [jose] FOR WG DISCUSSION: #82 part A - Possibly changing representation of private JWK fields

["Manger, James H" <[e-mail]>]

> It’s not like the set of “kty” values is a fast-moving target.

A new classes of crypto might appear only occasionally, but I’m not sure that is the only time a new “kty” value will be needed. If your RSA private key is held in a smartcard a JWK representing that key to your software will not have “d”, “p” and “q” fields, but might have a PKCS#15 path and a PIN to unlock the smartcard. When an RSA key in on a TPM chip the JWK may have a TPMKEY URI <draft-mavrogiannopoulos-tpmuri>. When an RSA key is behind a PKCS#11 API the JWK needs the parameters to pass to PKCS#11 functions.

Do these JWKs use “kty”:”RSA”?

--
James Manger

From: [e-mail] [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Thursday, 3 October 2013 7:47 AM
To: Justin Richer; Jim Schaad; [e-mail]
Subject: Re: [jose] FOR WG DISCUSSION: #82 part A - Possibly changing representation of private JWK fields

I agree with Justin that the motivation for the breaking change seems pretty hypothetical to me.  Besides, a new standard key type only tends to be introduced every decade or so, so it *really* wouldn’t be that hard to update the hypothetical key filtering software to correctly filter new key types when needed, should such software ever be written.  It’s not like the set of “kty” values is a fast-moving target.

                                                                -- Mike

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Justin Richer
Sent: Wednesday, October 02, 2013 7:25 AM
To: Jim Schaad; [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] FOR WG DISCUSSION: #82 part A - Possibly changing representation of private JWK fields

I think that the argument below is misleading -- why kind of hypothetical key parsing or filtering program is going to read a JWK that doesn't know the key types it's parsing out? I'm still not seeing the value in having things split out. From my vantage, it seems to be a fairly arbitrary syntax decision, and at this point I'd really rather not change syntax on stuff I'm already using on a daily basis.

 -- Justin
On 10/01/2013 08:38 PM, Jim Schaad wrote:
There is an argument below that it would be more robust to make any filter software know what is public and what is private since that enforces a per-type evaluation.  However I would argue that this is a problem for any new key type that is published after such filter software is done.

The program which is creating the JWK object is going to know what is public and what is private because it must have been updated in order to export the correct fields for the new key type.  However the filter code may not have been updated to understand this new key type and therefore has no ability to know what is public and what is private unless it was also programmed to do a registry lookup in the IANA registry to figure this out.  Even then it would be unable to deal with private key types.

By placing all private fields in a private object, the filter program would always be able to correct do the filtering and make sure that private key material is not published as it would, by definition, be in a single object which is easily identified.  This means that a server would not need to reject any new key types that it does not understand when trying to make sure that private information is not published.

To me this is more robust than not having this indicated by the exporter functions.

This is similar to what is done today in the ASN.1 case.  The ASN.1 structure description is different between the public key and the private key structures for those things you know about.  This makes it easy to do the decode on the public key and ensure that nothing exists that shouldn’t.  It is not possible for us to do a filter based just on the public fields since there are other elements that exist in the JWK object which have nothing to do with the key value.  I would not advocate having both a public and a private member object since that would be slightly ridiculous.

Jim