Subject: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial)

From: Mike Jones <[email-masked]>
Date: Fri, 6 Apr 2012 21:05:20 +0000

The JSON Web Key (JWK) spec currently contains the algorithm family definitions and parameter specifications for the RSA and Elliptic Curve algorithm families.  An editorial open issue is whether to leave these in the JWK spec or move them to the JWA spec.

The argument for leaving them in the JWK spec is that removing the definitions of "EC" and "RSA" and the family-specific parameter definitions ("crv", "x", "y", "mod", "exp") would leave very little normative text in the JWK spec itself.  It seemed like doing this would reduce the readability of the JWK spec, and so was not done in -01.

The argument for moving them is that all the algorithm-specific definitions would then be in the JWA spec and good examples of RSA and EC keys could remain in the JWK spec.

References to the pertinent specs are:
http://tools.ietf.org/html/draft-ietf-jose-json-web-key-01
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-01

Feedback?

                                                                -- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 7 Apr 2012 07:25:30 -0700

Please explain why you believe the readability of the document would be
reduced.  There would still be the ability to have examples that referenced
the algorithm draft.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Friday, April 06, 2012 2:05 PM
To: [email-masked]
Subject: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm
family definitions to JWA spec (editorial)

The JSON Web Key (JWK) spec currently contains the algorithm family
definitions and parameter specifications for the RSA and Elliptic Curve
algorithm families.  An editorial open issue is whether to leave these in
the JWK spec or move them to the JWA spec.

The argument for leaving them in the JWK spec is that removing the
definitions of "EC" and "RSA" and the family-specific parameter definitions
("crv", "x", "y", "mod", "exp") would leave very little normative text in
the JWK spec itself.  It seemed like doing this would reduce the readability
of the JWK spec, and so was not done in -01.

The argument for moving them is that all the algorithm-specific definitions
would then be in the JWA spec and good examples of RSA and EC keys could
remain in the JWK spec.

Feedback?

                                                                -- Mike

---

From: John Bradley <[email-masked]>
Date: Sat, 7 Apr 2012 11:45:47 -0300

It is mostly a style question I think.

Given that the elements can be directly embedded in JWE,  as well as being represented externally in a JWK,  I think JWA is probably the correct place for them as it makes it easier to add new crypto algs.

The solution for JWK is good examples I think.

I suppose the downside is an extra level of indirection through the specs for developers.

I don't feel strongly one way or the other, just have a slight preference for JWA. (My track record on document structure is slightly suspect though)

John B.
On 2012-04-07, at 11:25 AM, Jim Schaad wrote:

> Please explain why you believe the readability of the document would be reduced.  There would still be the ability to have examples that referenced the algorithm draft.
>  
> Jim
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
> Subject: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial)
>  
> The argument for leaving them in the JWK spec is that removing the definitions of “EC” and “RSA” and the family-specific parameter definitions ("crv", "x", "y", "mod", "exp") would leave very little normative text in the JWK spec itself.  It seemed like doing this would reduce the readability of the JWK spec, and so was not done in -01.
>  
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Mon, 9 Apr 2012 15:46:41 +0000

The readability would be somewhat reduced by having to refer to the second document.  That being said, I believe this could be mitigated by the use of examples.  Since opinion (of the two participants in the discussion to date) seems to favor moving the algorithm family definitions to JWA, I'll plan on doing that unless others speak up taking the counter position.

                                                            -- Mike

From: John Bradley [mailto:[email-masked]]
Sent: Saturday, April 07, 2012 7:46 AM
To: Jim Schaad
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial)

John B.

Jim

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Friday, April 06, 2012 2:05 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial)

Feedback?

                                                                -- Mike

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Thu, 26 Apr 2012 02:39:20 +0000

Having gone over this in detail while working on producing the next versions of the docs, I now believe that the readability will be fine.  I'm moving the JWK algorithm-specific definitions to the JWA doc, while leaving sufficient examples in the JWK spec to help implementer's "get it" at first glance.

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Saturday, April 07, 2012 7:26 AM
To: Mike Jones; [email-masked]
Subject: RE: [jose] Open Issue for WG Discussion: Whether to move JWK algorithm family definitions to JWA spec (editorial)

Jim

Feedback?

                                                                -- Mike