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

From: Mike Jones <[email-masked]>
Date: Fri, 6 Jul 2012 17:31:18 +0000

Thanks for taking the time to provide the detailed feedback.  Responses inline...

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Saturday, May 19, 2012 3:34 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Comments on draft-ietf-jose-json-web-key-02

<no hat>

My apologies for introducing you to the term algorithm families.  We don't use it in the same way and thus I think that you should generally remove it from the text.  To me it is a very wide term and somewhat nebulous.  Thus I think of all of the DH algorithms as being in a family - but that family could also include the ECDH algorithm as well as DSA depending on how one is using it.  Thus for me an algorithm family is not restricted to a specific instance (or small set of instances) such a DH & DSA but could be as large

as all key agreement algorithms.   As such it does not really match how you

are using it in much of the text.

Left in for the current draft for lack of a better term.  I did remove as many uses of the term as possible.

Slightly more detailed:

You can define an RSA key

You can define an RSA-OAEP key

The second one has all of the fields of the first, however it may have additional fields defined that deal specifically with RSA-OAEP.  The difference is going to be a question of restriction of usage of the key to a single algorithm vs allowing for all RSA algorithms.

Parameters could be defined in the JWA spec to specify parameters enabling those possible restrictions if the working group deems it useful/necessary.  The JWK spec already makes it clear that algorithm-specific parameters may be required, so this wouldn't change the model.

Here are some more comments

Abstract

1.  I am not a fan of the word enumerated in the last sentence.  This word implies to me that the list is not expandable.  I would recommend something along the lines of "An initial set of ... can be found in ..."

Done here, plus in JWE, JWS, JWA, JWE-JS, and JWS-JS

2.  JSON needs to be expanded on first use

Done here, plus in JWE, JWS, JWA, JWE-JS, JWS-JS, JWT, OAuth JWT Bearer, and SWD

Section 1

1.  JSON needs to be expanded on first use.  (Doing it on second use should be fine and clearer)

Done

2.  See enumerated comment above

Done

3.  Don't use non-goals.  The wording "The goals of this document do not include ..."  (Minor)

Done

4.  It is fine to tell me what documents they are used in.  I don't know that we need to say what the fields are.  (Minor)

Done

Section 2

1.  The phrase "For the purpose of this document" should be removed unless this term is used in other ways elsewhere.

Not changed, because in some other contexts, the same term is used to refer to the non URL safe encoding.

Section 4

1.  In para #2 - the use of "algorithm family" is incorrect.  They members are going to be required for the specific key being represented not to the family - consider the case of RSA and RSA-OAEP - these are both in the same family, but the fields required are different.

Reworded to not use the term "algorithm family"

2.  Do you believe that all of the algorithm members are defined in the JWA

document - or only for some algorithms.   Text should probably say they are

defined for the algorithms defined for the algorithms in JWA.

Done

3.  I don't believe that para #3 is enforceable by parsers as they have been presented to me.  Please prove me wrong.

Section 2.2 of http://tools.ietf.org/html/rfc4627 says "The names within an object SHOULD be unique."  So this should be enforced by conforming parsers.  I'd be interested in data saying that parsers exist that are non-conforming to this RFC 4627 "SHOULD".  If so, we should add appropriate warnings to the Security Considerations section.

4.  Let's look at the sentence  "If present, they MUST  be understood by implementations using them."  I believe that this is an incorrect assertion.

(Not to mention that it is totally uncheckable.)  Consider the following

situation:

Implementation A creates a JWK and files it with Implementation B.  A does not understand the "exist-date" property.

Implementation B adds the "exist-date" property and puts it at a URL.

Implementation C pulls the JWK from the URL, understand the "exist-date"

property.

According to the MUST, the JWK cannot be used as it is not understood by all of the implementations.

The only entity that you can make the requirement on is the consumer.  One assumes that the "provider" would/might understand the field or it would not be there but it could have been added in transit and thus that is not the case.

I believe that for your example, the text is correct as written, since in context, "them" refers to the additional members, not the JWK as a whole.  At no point in your example did an implementation use a JWK with an additional member that it did not understand.

I understand that the assertion may not be enforceable apart from conformance suites that check what implementations do when given new parameters, and I understand that in the general case, programmatic enforcement would be the equivalent of solving the halting problem.  That's not an argument, however, that in security contexts, that having this requirement isn't the right thing to do.

5.  I find the last sentence of para #4 to be unreadable.  I would start by breaking it into two sentences and potentially move the first one into the JWA document (that about parameters for keys).

Simplified

Section 4.1

1. Do you want to point to the JWA document or to the registry for the set of defined algorithms?

Clarified that some names are defined in JWA whereas all names not containing a collision resistant namespace should be registered.

2. In para #1 I would remove the sentence starting "Specific additional..."

as this is not part of the definition of the "alg" parameter and is covered in section 4.0

Done

3.  The last two sentences in para #1 can be combined together.

This is just a personal stylistic thing I suppose, but I prefer two short declarative sentences to a conjunction of the two.

Section 4.2

1.  Presentation suggestion - if you use a bulleted list for the values it will be easier to see what the list of defined values is.

Done

2.  See point #3 in section 4.1

Ditto

Section 4.3

1.  Is there a requirement that the kid be unique in a JWK Set?  I think that the answer should be called out in text either way.

Good point.  Added text saying that it need not be unique, and providing an example providing rationale for that choice.

2.  Is the string case sensitive?

It is now. :-)

3.  Move the sentence "When used..." to a new paragraph.  (suggestion)

Done

Section 6.1

1. Please make things easy for IANA - create a table with the fields across the top and the values down the table.  This will allow them to do their job without having to go through the entire document and for us to be able to easily validate that they got it correct.

Done here, plus in JWA and JWT

Section 6.2

1. Please put in a registration section for the items you are registering in Section 4 in the JWK table.  You can refer to JWA for creation of the table.

Done here, plus in JWS, JWE, JWA, and JWT

Appendix A

1.  I am not sure why this appendix is in this document.

To give credit to the inventors of the precursor spec that resulted in the JWK spec.  I've added their names to make this intent clearer.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 8 Jul 2012 15:56:19 -0700

Comments on responses and some additional comments as well.

If the security sections references the XML DSig document as having
important security considerations, then it needs to be normative and not
informative.

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, July 06, 2012 10:31 AM
To: Jim Schaad
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-jose-json-web-key-02

Thanks for taking the time to provide the detailed feedback.  Responses
inline.

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Saturday, May 19, 2012 3:34 PM
To: Mike Jones
Cc: [email-masked]
Subject: Comments on draft-ietf-jose-json-web-key-02

<no hat>

My apologies for introducing you to the term algorithm families.  We don't
use it in the same way and thus I think that you should generally remove it
from the text.  To me it is a very wide term and somewhat nebulous.  Thus I
think of all of the DH algorithms as being in a family - but that family
could also include the ECDH algorithm as well as DSA depending on how one is
using it.  Thus for me an algorithm family is not restricted to a specific
instance (or small set of instances) such a DH & DSA but could be as large

Left in for the current draft for lack of a better term.  I did remove as
many uses of the term as possible.

Slightly more detailed:

The second one has all of the fields of the first, however it may have
additional fields defined that deal specifically with RSA-OAEP.  The
difference is going to be a question of restriction of usage of the key to a
single algorithm vs allowing for all RSA algorithms.

Parameters could be defined in the JWA spec to specify parameters enabling
those possible restrictions if the working group deems it useful/necessary.
The JWK spec already makes it clear that algorithm-specific parameters may
be required, so this wouldn't change the model.

Abstract

1.  I am not a fan of the word enumerated in the last sentence.  This word
implies to me that the list is not expandable.  I would recommend something
along the lines of "An initial set of ... can be found in ..."

[JLS] This change was not made in the JWA document.

Section 2

1.  The phrase "For the purpose of this document" should be removed unless
this term is used in other ways elsewhere.

Not changed, because in some other contexts, the same term is used to refer
to the non URL safe encoding.

[JLS] Is it used in a different way in this document?   One can
automatically assumed that if you are defining a term, that it is for the
purposes of this document and, unless generally accepted, is not applicable
to other documents.  

Purely for curiosity, where is the phrase base64url encoding used to mean
something else in a different document?

Section 4

1.  In para #2 - the use of "algorithm family" is incorrect.  They members
are going to be required for the specific key being represented not to the
family - consider the case of RSA and RSA-OAEP - these are both in the same
family, but the fields required are different.

[JLS]   Suggest "In addition to the common parameters, each JWK will have
members that are specific to the key being represented.  These members
represent the parameters of the key.   Section 5 of the JSON Web Algorithm
(JWA) specifies a number of public keys and their associated members."

Done

3.  I don't believe that para #3 is enforceable by parsers as they have been
presented to me.  Please prove me wrong.

Section 2.2 of http://tools.ietf.org/html/rfc4627 says "The names within an
object SHOULD be unique."  So this should be enforced by conforming parsers.
I'd be interested in data saying that parsers exist that are non-conforming
to this RFC 4627 "SHOULD".  If so, we should add appropriate warnings to the
Security Considerations section.

[JLS] Stating that they should be unique is more of a requirement on the
generation side and not the parsing side of the specification.  I do not
believe that this statement in way says that parsers should reject objects
for which duplicate member names exist.

4.  Let's look at the sentence  "If present, they MUST  be understood by
implementations using them."  I believe that this is an incorrect assertion.

situation:

Implementation A creates a JWK and files it with Implementation B.  A does
not understand the "exist-date" property.

property.

According to the MUST, the JWK cannot be used as it is not understood by all
of the implementations. 

The only entity that you can make the requirement on is the consumer.  One
assumes that the "provider" would/might understand the field or it would not
be there but it could have been added in transit and thus that is not the
case.

I believe that for your example, the text is correct as written, since in
context, "them" refers to the additional members, not the JWK as a whole.
At no point in your example did an implementation use a JWK with an
additional member that it did not understand.

[JLS] This is precisely the statement that I made above, the mandating that
the field is understood by consumers of the JWK is possible, but it is not
possible to mandate that all implementations involved in the transaction
understand all of the fields.

I understand that the assertion may not be enforceable apart from
conformance suites that check what implementations do when given new
parameters, and I understand that in the general case, programmatic
enforcement would be the equivalent of solving the halting problem.  That's
not an argument, however, that in security contexts, that having this
requirement isn't the right thing to do.

[JLS] I have not made an argument for removing it, but for stating that it
is the consumer on which the restriction is placed on not on all
implementations.

5.  I find the last sentence of para #4 to be unreadable.  I would start by
breaking it into two sentences and potentially move the first one into the
JWA document (that about parameters for keys).

Simplified

[JLS]  I think it can be simplified even more.  For one thing it is not
clear if the member name must be unique between kinds of keys.  Thus can you
have a "x" for both DH and ECDH (or do they fall into the same family?).

[JLS] Given that only fields dealing with either generic items or a specific
key are represented in a JWK object.  It would make more sense to have the
restriction on member names than on generic members and not on members that
are specific to a public key.

Section 4.1

1. Do you want to point to the JWA document or to the registry for the set
of defined algorithms?

Clarified that some names are defined in JWA whereas all names not
containing a collision resistant namespace should be registered.

[JLS] OK - let me be more pointed in my comment.  I think you should point
at the registry and not at the other document for the list of defined
algorithms.  Additionally, I think you should point at the registry for the
set of generic members defined and ignore the set of key specific members
defined in this document.

as this is not part of the definition of the "alg" parameter and is covered
in section 4.0

Done

This is just a personal stylistic thing I suppose, but I prefer two short
declarative sentences to a conjunction of the two.

[JLS] as oppose to "The "alg" value MUST be a case-sensitive string.

Section 4.2

1.  Presentation suggestion - if you use a bulleted list for the values it
will be easier to see what the list of defined values is.

Done

Ditto

Section 4.3

1.  Is there a requirement that the kid be unique in a JWK Set?  I think
that the answer should be called out in text either way.

Good point.  Added text saying that it need not be unique, and providing an
example providing rationale for that choice.

[JLS]  Ok - I see documentation on how to handle the situation if there are
multiple KIDs that have the same value, but I am missing the rationale that
you have stated as being present.  A rationale would be WHY one would have
multiple keys with the same KID value.

It is now. :-)

Done

Section 6.1

1. Please make things easy for IANA - create a table with the fields across
the top and the values down the table.  This will allow them to do their job
without having to go through the entire document and for us to be able to
easily validate that they got it correct.

[JLS] Section 6.1.1 - Under the Parameter Name: field, you should have a
note for IANA that the name is case-sensitive and have a comment that names
that match in a case-insensitive manner SHOULD or SHOULD NOT be accepted.
(Copy note to all of the reset of the tables as well).

[JLS] Section 6.1.1 - are there any longevity requirements on the URI that
is specified?  If we refer to an RFC then we know that it will "always"
exist.  This is not necessarily true if one refers to a document on a
personal website.

Section 6.2

1. Please put in a registration section for the items you are registering in
Section 4 in the JWK table.  You can refer to JWA for creation of the table.

Appendix A

To give credit to the inventors of the precursor spec that resulted in the
JWK spec.  I've added their names to make this intent clearer.

---

From: Mike Jones <[email-masked]>
Date: Fri, 13 Jul 2012 21:19:52 +0000

Responses inline...

From: Jim Schaad [mailto:[email-masked]]
Sent: Sunday, July 08, 2012 3:56 PM
To: Mike Jones
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-jose-json-web-key-02

If the security sections references the XML DSig document as having important security considerations, then it needs to be normative and not informative.

Will do

Jim

From: Mike Jones [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, July 06, 2012 10:31 AM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on draft-ietf-jose-json-web-key-02

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Saturday, May 19, 2012 3:34 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Comments on draft-ietf-jose-json-web-key-02

<no hat>

Slightly more detailed:

Abstract

Correct, because you wrote "I do not have a problem with enumerate in this document" in your May 21st message on JWA.  I made a typo when I wrote that I applied it to JWA above.  (Also, I actually think that in JWA, the word "enumerates" works well.)

Section 2

[JLS] Is it used in a different way in this document?   One can automatically assumed that if you are defining a term, that it is for the purposes of this document and, unless generally accepted, is not applicable to other documents.

Purely for curiosity, where is the phrase base64url encoding used to mean something else in a different document?

OK, I'll delete the phrase.  The term "base64 encoding" often (usually) means something different, but not the term "base64url encoding".

Section 4

[JLS]   Suggest "In addition to the common parameters, each JWK will have members that are specific to the key being represented.  These members represent the parameters of the key.   Section 5 of the JSON Web Algorithm (JWA) specifies a number of public keys and their associated members."

Good

Done

[JLS] Stating that they should be unique is more of a requirement on the generation side and not the parsing side of the specification.  I do not believe that this statement in way says that parsers should reject objects for which duplicate member names exist.

Parsers that accept input with duplicate member names are violating a SHOULD, as I see it.  In any event, tightening this to "MUST be unique" is appropriate in our specs, since I'll grant you that relying on a SHOULD is inappropriate in a security context.  If this requires secondary parsing or using a hardened parser to ensure member uniqueness, that's part of the price of having a correct implementation.  (And consider the alternative - we *really* don't want to go down the path of having to make statements like "If there are multiple "alg" values, then..."!)

We started talking about these security considerations at http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#section-8.2.  I'll tighten this up.

situation:

property.

[JLS] This is precisely the statement that I made above, the mandating that the field is understood by consumers of the JWK is possible, but it is not possible to mandate that all implementations involved in the transaction understand all of the fields.

Maybe we can talk about this in person in Vancouver, because I think I'm still missing something in what you're trying to achieve here.  In your example, the JWK created by A and the JWK created by B by adding the "exist-date" property to A are different JWKs, because they have different fields.  At no point did any party, producer or consumer, use a JWK whose fields it did not all understand.  (I'll grant you that if A were to use B's JWK, the "must understand" would be violated, but that's exactly the intent.)

[JLS] I have not made an argument for removing it, but for stating that it is the consumer on which the restriction is placed on not on all implementations.

You don't think that's equally important for producers to understand all the fields of the JWKs they're producing?

Simplified

[JLS]  I think it can be simplified even more.  For one thing it is not clear if the member name must be unique between kinds of keys.  Thus can you have a "x" for both DH and ECDH (or do they fall into the same family?).

Agreed.  I'll simplify this further to just say "Member names SHOULD ...".  I'll also add "Member names used for representing key parameters for different kinds of keys need not be distinct", per your question about uniqueness.

[JLS] Given that only fields dealing with either generic items or a specific key are represented in a JWK object.  It would make more sense to have the restriction on member names than on generic members and not on members that are specific to a public key.

Agreed - I believe my wording above addresses this.

Section 4.1

[JLS] OK - let me be more pointed in my comment.  I think you should point at the registry and not at the other document for the list of defined algorithms.  Additionally, I think you should point at the registry for the set of generic members defined and ignore the set of key specific members defined in this document.

OK, I'll reword this (and similar locations) to make the registry be the primary reference and to add, on a secondary basis, that the JWA document provides the initial contents for the registry.  (I believe we continue to need the JWA reference to help reviewers of the current specs, especially since the registry won't be created until the specs are approved as RFCs.)

Done

OK, I agree that that wording's better.  I'll make that change where applicable.

Section 4.2

Done

Ditto

Section 4.3

[JLS]  Ok - I see documentation on how to handle the situation if there are multiple KIDs that have the same value, but I am missing the rationale that you have stated as being present.  A rationale would be WHY one would have multiple keys with the same KID value.

The rationale was in the "for instance" text.  We could beef up the rationale if you have better suggested wording.

As another example, imagine "kid" values like "Current", "Upcoming", and "Deprecated", used for key rollover guidance.  You could apply that label to all keys where the classification fits.  If there are multiple "Current" keys, then in this example they might be differentiated either by having different "alg" or "use" values, or some combination of both.  (There might only be one current RSASA signing key and one current ECDSA signing key, but both would be "Current".)

It is now. :-)

Done

Section 6.1

[JLS] Section 6.1.1 - Under the Parameter Name: field, you should have a note for IANA that the name is case-sensitive and have a comment that names that match in a case-insensitive manner SHOULD or SHOULD NOT be accepted. (Copy note to all of the reset of the tables as well).

Will do (with SHOULD NOT)

[JLS] Section 6.1.1 - are there any longevity requirements on the URI that is specified?  If we refer to an RFC then we know that it will "always" exist.  This is not necessarily true if one refers to a document on a personal website.

Is there best-practice text on this issue that anyone is aware of that we can reuse?  (The current text is reused from the OAuth Core spec, which has already undergone IETF last call, and so seemed like a good place to start from.)

Section 6.2

Appendix A

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 13 Jul 2012 16:39:12 -0700

Additional Notes

From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, July 13, 2012 2:20 PM
To: Jim Schaad
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-jose-json-web-key-02

Responses inline.

Will do

Jim

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Saturday, May 19, 2012 3:34 PM
To: Mike Jones
Cc: [email-masked]
Subject: Comments on draft-ietf-jose-json-web-key-02

<no hat>

Slightly more detailed:

Abstract

Correct, because you wrote "I do not have a problem with enumerate in this
document" in your May 21st message on JWA.  I made a typo when I wrote that
I applied it to JWA above.  (Also, I actually think that in JWA, the word
"enumerates" works well.)

[JLS2] I did not re-read the note on the alg document until after I finished
this review.   I agreed in the other message that it did not need to be
changed, but I was going based on the comment in this message.  It is not a
problem.

Section 2

OK, I'll delete the phrase.  The term "base64 encoding" often (usually)
means something different, but not the term "base64url encoding".

Section 4

Good

Done

Parsers that accept input with duplicate member names are violating a
SHOULD, as I see it.  In any event, tightening this to "MUST be unique" is
appropriate in our specs, since I'll grant you that relying on a SHOULD is
inappropriate in a security context.  If this requires secondary parsing or
using a hardened parser to ensure member uniqueness, that's part of the
price of having a correct implementation.  (And consider the alternative -
we *really* don't want to go down the path of having to make statements like
"If there are multiple "alg" values, then."!)

We started talking about these security considerations at
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#section-8.2
.  I'll tighten this up.

situation:

property.

Maybe we can talk about this in person in Vancouver, because I think I'm
still missing something in what you're trying to achieve here.  In your
example, the JWK created by A and the JWK created by B by adding the
"exist-date" property to A are different JWKs, because they have different
fields.  At no point did any party, producer or consumer, use a JWK whose
fields it did not all understand.  (I'll grant you that if A were to use B's
JWK, the "must understand" would be violated, but that's exactly the
intent.)

[JLS2] So we now have a situation where A publishes, B updates, C encrypts
to the B version and sends to A which then fails the decrypt.

You don't think that's equally important for producers to understand all the
fields of the JWKs they're producing?

[JLS2] What does it mean?  Are we talking about the program that publishes
or the program that decrypts?   I think that a producing program should not
generate something it cannot consume, but that is different that if we are
talking about a person's system.  In this case the production and
consumption programs may be different and have different abilities to
understand fields.  I would be perfectly willing for producers to be able to
publish JWKs with fields that they do not "understand".

Simplified

Agreed.  I'll simplify this further to just say "Member names SHOULD .".
I'll also add "Member names used for representing key parameters for
different kinds of keys need not be distinct", per your question about
uniqueness.

[JLS2] No I don't agree that is true.  I asked what I thought was a question
about changing the requirements.  The current text says that specific
members need to be registered.  I asked if we should only require that
generic members be registered.  This would be a change in policy which might
make the registry cleaner and easier to maintain, at the cost of some
potential issues way down the road.

Section 4.1

OK, I'll reword this (and similar locations) to make the registry be the
primary reference and to add, on a secondary basis, that the JWA document
provides the initial contents for the registry.  (I believe we continue to
need the JWA reference to help reviewers of the current specs, especially
since the registry won't be created until the specs are approved as RFCs.)

Done

OK, I agree that that wording's better.  I'll make that change where
applicable.

Section 4.2

Done

Ditto

Section 4.3

The rationale was in the "for instance" text.  We could beef up the
rationale if you have better suggested wording.

As another example, imagine "kid" values like "Current", "Upcoming", and
"Deprecated", used for key rollover guidance.  You could apply that label to
all keys where the classification fits.  If there are multiple "Current"
keys, then in this example they might be differentiated either by having
different "alg" or "use" values, or some combination of both.  (There might
only be one current RSASA signing key and one current ECDSA signing key, but
both would be "Current".)

[JLS2]  There is a rational about why there exists a kid field.  There is
not a rational about why the kids are not a requirement that they be unique.
I don't know that I have a good reason for why the fields should not be
unique within a single key set.   This is the reason for asking for a
rational to be provided.

It is now. :-)

Done

Section 6.1

Is there best-practice text on this issue that anyone is aware of that we
can reuse?  (The current text is reused from the OAuth Core spec, which has
already undergone IETF last call, and so seemed like a good place to start
from.)

[JLS2] This is a think question and not a requirement to change the
document.

Section 6.2

Appendix A

---

From: Mike Jones <[email-masked]>
Date: Sat, 14 Jul 2012 00:29:51 +0000

[mbj2] Additional responses...

From: Jim Schaad [mailto:[email-masked]]
Sent: Friday, July 13, 2012 4:39 PM
To: Mike Jones
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-jose-json-web-key-02

Additional Notes

Responses inline...

Will do

Jim

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Saturday, May 19, 2012 3:34 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Comments on draft-ietf-jose-json-web-key-02

<no hat>

Slightly more detailed:

Abstract

[JLS2] I did not re-read the note on the alg document until after I finished this review.   I agreed in the other message that it did not need to be changed, but I was going based on the comment in this message.  It is not a problem.

Section 2

Section 4

Good

Done

situation:

property.

[JLS2] So we now have a situation where A publishes, B updates, C encrypts to the B version and sends to A which then fails the decrypt.

[mbj2] Correct.  If A doesn't understand the fields of the JWK that it's using, that's the intended outcome.

[JLS2] What does it mean?  Are we talking about the program that publishes or the program that decrypts?   I think that a producing program should not generate something it cannot consume, but that is different that if we are talking about a person's system.  In this case the production and consumption programs may be different and have different abilities to understand fields.  I would be perfectly willing for producers to be able to publish JWKs with fields that they do not "understand".

[mbj2] The intent is that all programs using any JOSE-specified data structure must understand all of that data structure or reject the input.  I understand that, for extensibility reasons, some may disagree with this requirement, and we could have that discussion, but I don't think there's anything ambiguous about the current "must understand" wording.  (If there is, please let me know, and I'll tighten it up.)

Simplified

[JLS2] No I don't agree that is true.  I asked what I thought was a question about changing the requirements.  The current text says that specific members need to be registered.  I asked if we should only require that generic members be registered.  This would be a change in policy which might make the registry cleaner and easier to maintain, at the cost of some potential issues way down the road.

[mbj2] I would personally prefer that members of both kinds be registered, in part, so people can go to the registry and find references to all the members that they can expect to find in a JWK.  As you wrote, I think this will save potential problems down the road.

Section 4.1

Done

Section 4.2

Done

Ditto

Section 4.3

[JLS2]  There is a rational about why there exists a kid field.  There is not a rational about why the kids are not a requirement that they be unique.  I don't know that I have a good reason for why the fields should not be unique within a single key set.   This is the reason for asking for a rational to be provided.

[mbj2] OK - I can try to add rationale like that above.

It is now. :-)

Done

Section 6.1

[JLS2] This is a think question and not a requirement to change the document.

Section 6.2

Appendix A