Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-01

From: "Jim Schaad" <[email-masked]>
Date: Wed, 2 May 2012 17:23:03 -0700

From: Mike Jones [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2012 9:22 PM
To: Jim Schaad
Cc: [email-masked]
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-key-01

Thanks for the detailed comments, as always, Jim.  Replies inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Schaad
Sent: Wednesday, April 11, 2012 1:07 PM
To: Mike Jones
Cc: [email-masked]
Subject: [jose] Comments on draft-ietf-jose-json-web-key-01

<no hat>

11.  Should the text that is in the signature and encryption dealing with
adding fields (urls vs simple names) be included in this section as well?

Are you thinking of the text about the three classes of names:  reserved,
private, and public?  With the possibility of a registry?  What do people in
the working group think?  I think the chances of this object being extended
are small, especially since we only define one member.  But then, it's
incredibly hard to predict how a standard will be used, if successful.  I'd
be more prone to think that extension made sense if the spec defined more
than one member.

Yes that was what I was thinking of.   If we are going to say don't add
things willy-nilly then we should probably have text saying how to add
things safely.

12.  Should there be an IANA registry for the member names of a container
object.

Per 11, I don't think so.  I think this case is better handled by the
standard JSON "you can add fields if you understand them" logic.

Cost of a registry is low if we think that the IETF is going to want to add
things then we should  setup the registry now.

JWK Key Object Format:

18.  Should the text dealing with adding members be present (copied from
JWS)?  Is it just the key and not the entire key set that is to be ignored?

Again, are you thinking the reserved/private/public treatment?  With a
registry?  Or maybe just a registry?  I didn't find "ignore" in the draft,
so I'm not sure what the second sentence in your remarks is referring to.

The text for Key Object says that if additional members are present they
MUST be understood - hence if not understood the Key Object MUST NOT be
used.  The question is does this propagate up to the Key Container?

Open Issues:

19.  I think that a section on adding key families would be reasonable.

Yes, probably in JWA.

I think this would be better here - specifically requirements on what must
be added to put something into the alg registry. 

Jim

                                                            Thanks again,

                                                            -- Mike

---

From: Mike Jones <[email-masked]>
Date: Sun, 13 May 2012 00:24:04 +0000

Hi Jim,

I've applied your recommendations in the just-published -02 JOSE drafts.  Thanks again for taking the time to provide the detailed critique.  I believe the text is much improved and more usable as a result!

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, May 02, 2012 5:23 PM
To: Mike Jones
Cc: [email-masked]
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-key-01

From: Mike Jones [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, April 25, 2012 9:22 PM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-key-01

Thanks for the detailed comments, as always, Jim.  Replies inline...

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Jim Schaad
Sent: Wednesday, April 11, 2012 1:07 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: [jose] Comments on draft-ietf-jose-json-web-key-01

<no hat>

11.  Should the text that is in the signature and encryption dealing with adding fields (urls vs simple names) be included in this section as well?

Are you thinking of the text about the three classes of names:  reserved, private, and public?  With the possibility of a registry?  What do people in the working group think?  I think the chances of this object being extended are small, especially since we only define one member.  But then, it's incredibly hard to predict how a standard will be used, if successful.  I'd be more prone to think that extension made sense if the spec defined more than one member.

Yes that was what I was thinking of.   If we are going to say don't add things willy-nilly then we should probably have text saying how to add things safely.

12.  Should there be an IANA registry for the member names of a container object.

Per 11, I don't think so.  I think this case is better handled by the standard JSON "you can add fields if you understand them" logic.

Cost of a registry is low if we think that the IETF is going to want to add things then we should  setup the registry now.

JWK Key Object Format:

18.  Should the text dealing with adding members be present (copied from JWS)?  Is it just the key and not the entire key set that is to be ignored?

Again, are you thinking the reserved/private/public treatment?  With a registry?  Or maybe just a registry?  I didn't find "ignore" in the draft, so I'm not sure what the second sentence in your remarks is referring to.

The text for Key Object says that if additional members are present they MUST be understood - hence if not understood the Key Object MUST NOT be used.  The question is does this propagate up to the Key Container?

Open Issues:

Yes, probably in JWA.

I think this would be better here - specifically requirements on what must be added to put something into the alg registry.

Jim

                                                            Thanks again,
                                                            -- Mike