Subject: Re: [jose] Appendix D in draft -20

From: Mike Jones <[email-masked]>
Date: Sat, 8 Feb 2014 02:04:25 +0000

Hi Jim,

I've updated my working draft to attempt to address all of your comments below.  Thanks for the thorough read - as always.  Are there any specific remaining edits you'd like to see applied to the following text?

Appendix D.  Notes on Key Selection

This appendix describes a set of possible algorithms for selecting the key to be used to validate the digital signature or MAC of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rather than a single algorithm, because in different contexts, not all the sources of keys will be used, they can be tried in different orders, and sometimes not all the collected keys will be tried; hence, different algorithms will be used in different application contexts.

The steps below are described for illustration purposes only; specific applications can and are likely to use different algorithms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the keys to use, as there may be one or two key selection methods that are profiled for the application's use. This appendix supplements the normative information on key location in Section 6 (Key Identification)<file:///C:\mbj\DSG\JOSE\draft-ietf-jose-json-web-signature.html#IDingKeys>.

These algorithms would typically include these steps:
1.   Collect a set of potentially applicable keys. Sources of keys may include:
o    Keys supplied by the application protocol being used.
o    Keys referenced by the jku (JWK Set URL) Header Parameter.
o    The key provided by the jwk (JSON Web Key) Header Parameter.
o    The key referenced by the x5u (X.509 URL) Header Parameter.
o    The key provided by the x5c (X.509 Certificate Chain) Header Parameter.
o    Other applicable keys available to the application.
2.   Filter the set of collected keys. For instance, only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters might be tried by the application. Keys with inappropriate alg (algorithm), use (public key use), or key_ops (key operations) values would likewise typically be excluded if the application uses those parameters. Keys might be filtered to include or exclude keys with certain other member values. For some applications, no filtering will be applied.
3.   Order the set of collected keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tried before other keys. Likewise, keys with certain member values might be ordered before keys with other member values. For some applications, no ordering will be applied.
4.   Make trust decisions about the keys. Keys not meeting the application's trust criteria would not be used. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application.
5.   Attempt signature or MAC validation for a JWS object or decryption of a JWE object with some or all of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process will normally terminate following a successful validation or decryption.

                                                                -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, January 23, 2014 12:41 PM
To: [email-masked]
Cc: [email-masked]
Subject: [jose] Appendix D in draft -20

I am only marginally happier with this draft of the document.

I do not see how one can possibly state that steps 1, 3 and 4 are in any way optional in this algorithm.  The concept of not gathering keys, filtering out keys that cannot possibly be correct and not checking the signature of keys makes absolutely no sense to me.  If these steps are to be considered optional then the reason for them being option must be clearly documented.

My understanding of x5u says that only a single key referenced by the chain would be eligible for inclusion in the key set.  If this is not true then it needs to clarified in the description of x5u.  If it is true then s/keys/key/ in that description.

I need to have a much better understanding of the statement that you can order based on the value of the kty value.  As it stands I have no idea what this means and why one would do such an ordering.

I would probably swap steps 2 and 3 so that one can order with respect to those keys which are reasonable to look at rather than looking at the entire building of keys.  As part of this I would move the number of keys from current step 3 to step 4.

If you are going to make the statement "Keys with inappropriate "alg" (algorithm), "use" (public key       use), or "key_ops" (key operations) values would likewise       typically be excluded." Then you need to provide text to tell me under what circumstances I would not be excluding them.  My understanding is that they would always be excluded and thus this text makes no sense to me.

I would move the kty filter into the previous sentence.  It them make sense to talk about applications filtering based on other values that might be more application specific.

I would like to see the trust statement moved to a separate item in the list of steps.  Again this is something that needs to be done, but it can be done after step 4 rather than in the filter process.  The trust statement can be made to be more general that what is current stated.  That is the trust decision may be made based on internal application information, generic information or an external certificate validation process.  In some cases the trust decision may be determined to be implicit based on the source of the key.    I would make this general rather than specific.  That is to say I would say that a binding of trust needs to be made, and the following items should be considered in the list of things to be included.  This should not and would not be presented as an exhaustive list but should be somewhat complete.  That is getting this from a jku has a degree of trust that a jkw does not have.

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 12 Feb 2014 15:05:12 -0800

From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 6:04 PM
To: Jim Schaad
Cc: [email-masked]
Subject: RE: [jose] Appendix D in draft -20

Hi Jim,

I've updated my working draft to attempt to address all of your comments
below.  Thanks for the thorough read - as always.  Are there any specific
remaining edits you'd like to see applied to the following text?

This appendix describes a set of possible algorithms for selecting the key
to be used to validate the digital signature or MAC of a JWS object or for
selecting the key to be used to decrypt a JWE object. This guidance
describes a family of possible algorithms, rather than a single algorithm,
because in different contexts, not all the sources of keys will be used,
they can be tried in different orders, and sometimes not all the collected
keys will be tried; hence, different algorithms will be used in different
application contexts. 

The steps below are described for illustration purposes only; specific
applications can and are likely to use different algorithms or perform some
of the steps in different orders. Specific applications will frequently have
a much simpler method of determining the keys to use, as there may be one or
two key selection methods that are profiled for the application's use. This
appendix supplements the normative information on key location in
<file:///C:\mbj\DSG\JOSE\draft-ietf-jose-json-web-signature.html#IDingKeys>
Section 6 (Key Identification). 

These algorithms would typically include these steps.  (Note: The steps can
be performed in any order and do not need to be treated as distinct, that is
keys can be tested as soon as they are found rather than waiting for all
keys to be found): 

1.   Collect  a the set of potentially applicable keys. Sources of keys may
include: 

The order of looking at key sources is frequently application dependent both
for order and inclusion.  Frequently all keys from a one set of locations,
such as local caches, will be checked before looking at other locations.  

2.   Filter the set of collected keys. For instance, some applications will
only use keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1
thumbprint) parameters might be tried by the application. Keys with
inappropriate alg (algorithm), use (public key use), or key_ops (key
operations) values would likewise typically be excluded if the application
uses those parameters. Additionally, keys Keys might be filtered to include
or exclude keys with certain application specific other member values. For
some applications, no filtering will be applied. 

3.   Order the set of collected keys. For instance, keys referenced by kid
(Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be
tried before other keys trying keys without a kid value. Likewise, keys with
certain member values might be ordered before keys with other member values.
For some applications, no ordering will be applied. 

4.   Make trust decisions about the keys. Keys not meeting the application's
trust criteria would not be used. Such criteria might include, but is not
limited to the source of the key, whether the TLS certificate validates for
keys retrieved from URLs, whether a key in an X.509 certificate is backed by
a valid certificate chain, and other information known by the application. 

5.   Attempt signature or MAC validation for a JWS object or decryption of a
JWE object with some or all of the collected and possibly filtered and/or
ordered keys. A limit on the number of keys to be tried might be applied.
This process will normally terminate following a successful validation or
decryption. 

It is reasonable to do the signature validation prior to doing the trust
validation steps as items which do not validate do not need to have a trust
decision made.

                                                                -- Mike

I do not see how one can possibly state that steps 1, 3 and 4 are in any way
optional in this algorithm.  The concept of not gathering keys, filtering
out keys that cannot possibly be correct and not checking the signature of
keys makes absolutely no sense to me.  If these steps are to be considered
optional then the reason for them being option must be clearly documented.

My understanding of x5u says that only a single key referenced by the chain
would be eligible for inclusion in the key set.  If this is not true then it
needs to clarified in the description of x5u.  If it is true then
s/keys/key/ in that description.

I need to have a much better understanding of the statement that you can
order based on the value of the kty value.  As it stands I have no idea what
this means and why one would do such an ordering.

I would probably swap steps 2 and 3 so that one can order with respect to
those keys which are reasonable to look at rather than looking at the entire
building of keys.  As part of this I would move the number of keys from
current step 3 to step 4.

If you are going to make the statement "Keys with inappropriate "alg"
(algorithm), "use" (public key       use), or "key_ops" (key operations)
values would likewise       typically be excluded." Then you need to provide
text to tell me under what circumstances I would not be excluding them.  My
understanding is that they would always be excluded and thus this text makes
no sense to me.
 
I would move the kty filter into the previous sentence.  It them make sense
to talk about applications filtering based on other values that might be
more application specific.
 
I would like to see the trust statement moved to a separate item in the list
of steps.  Again this is something that needs to be done, but it can be done
after step 4 rather than in the filter process.  The trust statement can be
made to be more general that what is current stated.  That is the trust
decision may be made based on internal application information, generic
information or an external certificate validation process.  In some cases
the trust decision may be determined to be implicit based on the source of
the key.    I would make this general rather than specific.  That is to say
I would say that a binding of trust needs to be made, and the following
items should be considered in the list of things to be included.  This
should not and would not be presented as an exhaustive list but should be
somewhat complete.  That is getting this from a jku has a degree of trust
that a jkw does not have.
 
Jim

---

From: Mike Jones <[email-masked]>
Date: Thu, 13 Feb 2014 01:07:16 +0000

Thanks for the useful comments, Jim.  I've incorporated them, sometimes with small wording changes, in the version below.  Hopefully this version will get us to a draft we both like (or at least, can live with :)).

The steps below are described for illustration purposes only; specific applications can and are likely to use different algorithms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the keys to use, as there may be one or two key selection methods that are profiled for the application's use. This appendix supplements the normative information on key location in Section 6 (Key Identification).

These algorithms include the following steps. Note that the steps can be performed in any order and do not need to be treated as distinct. For example, keys can be tried as soon as they are found, rather than collecting all the keys before trying any.
1.   Collect the set of potentially applicable keys. Sources of keys may include:
o   Keys supplied by the application protocol being used.
o   Keys referenced by the jku (JWK Set URL) Header Parameter.
o   The key provided by the jwk (JSON Web Key) Header Parameter.
o   The key referenced by the x5u (X.509 URL) Header Parameter.
o   The key provided by the x5c (X.509 Certificate Chain) Header Parameter.
o   Other applicable keys available to the application.
The order for collecting and trying keys from different key sources is typically application dependent. For example, frequently all keys from a one set of locations, such as local caches, will be tried before collecting and trying keys from other locations.
2.   Filter the set of collected keys. For instance, some applications will use only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters. If the application uses the alg (algorithm), use (public key use), or key_ops (key operations) parameters, keys with keys with inappropriate values of those parameters would be excluded. Additionally, keys might be filtered to include or exclude keys with certain other member values in an application specific manner. For some applications, no filtering will be applied.
3.   Order the set of collected keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tried before keys with neither of these values. Likewise, keys with certain member values might be ordered before keys with other member values. For some applications, no ordering will be applied.
4.   Make trust decisions about the keys. Signatures made with keys not meeting the application's trust criteria would not be accepted. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application.
5.   Attempt signature or MAC validation for a JWS object or decryption of a JWE object with some or all of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process will normally terminate following a successful validation or decryption.

Note that it is reasonable for some applications to perform signature or MAC validation prior to making a trust decision about a key, since keys for which the validation fails need no trust decision.

The only suggested action I didn't apply was deleting the sentence "For some applications, no filtering will be applied".  I didn't delete it because it's true.  For example, an application might specify that all potentially applicable keys are retrieved from a particular JWK Set, it might specify that only applicable keys may be present there, and that the keys are to be tried until one succeeds.  That's very simple.  Such an application doesn't need, and wouldn't use any of the optional key attribute parameters.  They'd just use key values, and would try keys until one works.  No filtering is performed.

                                                            -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 3:05 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Appendix D in draft -20

From: Mike Jones [mailto:[email-masked]]
Sent: Friday, February 07, 2014 6:04 PM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] Appendix D in draft -20

Hi Jim,

These algorithms would typically include these steps.  (Note: The steps can be performed in any order and do not need to be treated as distinct, that is keys can be tested as soon as they are found rather than waiting for all keys to be found):
1.   Collect  a the set of potentially applicable keys. Sources of keys may include:
o   Keys supplied by the application protocol being used.
o   Keys referenced by the jku (JWK Set URL) Header Parameter.
o   The key provided by the jwk (JSON Web Key) Header Parameter.
o   The key referenced by the x5u (X.509 URL) Header Parameter.
o   The key provided by the x5c (X.509 Certificate Chain) Header Parameter.
o   Other applicable keys available to the application.
The order of looking at key sources is frequently application dependent both for order and inclusion.  Frequently all keys from a one set of locations, such as local caches, will be checked before looking at other locations.

2.   Filter the set of collected keys. For instance, some applications will only use keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters might be tried by the application. Keys with inappropriate alg (algorithm), use (public key use), or key_ops (key operations) values would likewise typically be excluded if the application uses those parameters. Additionally, keys Keys might be filtered to include or exclude keys with certain application specific other member values. For some applications, no filtering will be applied.
3.   Order the set of collected keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tried before other keys trying keys without a kid value. Likewise, keys with certain member values might be ordered before keys with other member values. For some applications, no ordering will be applied.
4.   Make trust decisions about the keys. Keys not meeting the application's trust criteria would not be used. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application.
5.   Attempt signature or MAC validation for a JWS object or decryption of a JWE object with some or all of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process will normally terminate following a successful validation or decryption.
It is reasonable to do the signature validation prior to doing the trust validation steps as items which do not validate do not need to have a trust decision made.

                                                                -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, January 23, 2014 12:41 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [jose] Appendix D in draft -20

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 12 Feb 2014 17:55:38 -0800

From: Mike Jones [mailto:[email-masked]] 
Sent: Wednesday, February 12, 2014 5:07 PM
To: Jim Schaad
Cc: [email-masked]
Subject: RE: [jose] Appendix D in draft -20

Thanks for the useful comments, Jim.  I've incorporated them, sometimes with
small wording changes, in the version below.  Hopefully this version will
get us to a draft we both like (or at least, can live with J).

appendix supplements the normative information on key location in Section 6
(Key Identification). 

These algorithms include the following steps. Note that the steps can be
performed in any order and do not need to be treated as distinct. For
example, keys can be tried as soon as they are found, rather than collecting
all the keys before trying any. 

1.   Collect the set of potentially applicable keys. Sources of keys may
include: 

The order for collecting and trying keys from different key sources is
typically application dependent. For example, frequently all keys from a one
set of locations, such as local caches, will be tried before collecting and
trying keys from other locations. 

2.   Filter the set of collected keys. For instance, some applications will
use only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1
thumbprint) parameters. If the application uses the alg (algorithm), use
(public key use), or key_ops (key operations) parameters, keys with keys
with inappropriate values of those parameters would be excluded.
Additionally, keys might be filtered to include or exclude keys with certain
other member values in an application specific manner. For some
applications, no filtering will be applied. 

3.   Order the set of collected keys. For instance, keys referenced by kid
(Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be
tried before keys with neither of these values. Likewise, keys with certain
member values might be ordered before keys with other member values. For
some applications, no ordering will be applied. 

4.   Make trust decisions about the keys. Signatures made with keys not
meeting the application's trust criteria would not be accepted. Such
criteria might include, but is not limited to the source of the key, whether
the TLS certificate validates for keys retrieved from URLs, whether a key in
an X.509 certificate is backed by a valid certificate chain, and other
information known by the application. 

Note that it is reasonable for some applications to perform signature or MAC
validation prior to making a trust decision about a key, since keys for
which the validation fails need no trust decision. 

The only suggested action I didn't apply was deleting the sentence "For some
applications, no filtering will be applied".  I didn't delete it because
it's true.  For example, an application might specify that all potentially
applicable keys are retrieved from a particular JWK Set, it might specify
that only applicable keys may be present there, and that the keys are to be
tried until one succeeds.  That's very simple.  Such an application doesn't
need, and wouldn't use any of the optional key attribute parameters.  They'd
just use key values, and would try keys until one works.  No filtering is
performed.

That is not really  true statement - and what happens if  key is in the list
which is does not follow the rules?  Then either things go boom or the
filtering step is applied, it is just applied in a really bad way at some
later step.

                                                            -- Mike

 

Hi Jim,

                                                                -- Mike

 

Jim

---

From: Mike Jones <[email-masked]>
Date: Thu, 13 Feb 2014 06:09:02 +0000

A key being in the list that doesn't follow the application's rules is really just an example of illegal input.  Well-written programs handle and reject illegal inputs, whether they be malformed JSON syntax, RSA keys with no "e" parameter, "kty" values not supported by the application, etc.  You can stretch and try to call error handling "filtering" if you want, but they're really not the same thing.

You may think I'm splitting hairs, but I really don't think I am.  In the real world, there will be perfectly good apps that just try all the keys.  Some keys won't work because the signatures don't validate.  Some may not work because the key type isn't supported.  Some won't work for other reasons that perhaps neither of us have thought of.  That doesn't make these simple applications broken or non-conformant because they didn't have a key filtering step.  Thus, there's nothing incorrect or particularly dire about saying "For some applications, no filtering will be applied".

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, February 12, 2014 5:56 PM
To: Mike Jones
Cc: [email-masked]
Subject: RE: [jose] Appendix D in draft -20

That is not really  true statement - and what happens if  key is in the list which is does not follow the rules?  Then either things go boom or the filtering step is applied, it is just applied in a really bad way at some later step.

                                                            -- Mike

Hi Jim,

                                                                -- Mike

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 12 Feb 2014 23:02:38 -0800

And it would appear that you do not care about problems such as the
Bleichenbacher attack.

From: Mike Jones [mailto:[email-masked]] 
Sent: Wednesday, February 12, 2014 10:09 PM
To: Jim Schaad
Cc: [email-masked]
Subject: RE: [jose] Appendix D in draft -20

A key being in the list that doesn't follow the application's rules is
really just an example of illegal input.  Well-written programs handle and
reject illegal inputs, whether they be malformed JSON syntax, RSA keys with
no "e" parameter, "kty" values not supported by the application, etc.  You
can stretch and try to call error handling "filtering" if you want, but
they're really not the same thing.

You may think I'm splitting hairs, but I really don't think I am.  In the
real world, there will be perfectly good apps that just try all the keys.
Some keys won't work because the signatures don't validate.  Some may not
work because the key type isn't supported.  Some won't work for other
reasons that perhaps neither of us have thought of.  That doesn't make these
simple applications broken or non-conformant because they didn't have a key
filtering step.  Thus, there's nothing incorrect or particularly dire about
saying "For some applications, no filtering will be applied".

                                                            -- Mike

 

                                                            -- Mike

 

Hi Jim,

                                                                -- Mike

 

Jim

---

From: Mike Jones <[email-masked]>
Date: Thu, 13 Feb 2014 07:18:19 +0000

No, I'm asserting that there exist constrained application scenarios in which the preconditions for the Bleichenbacher attack cannot occur.  Are you really asserting that no such constrained use cases are possible?

From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 11:03 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Appendix D in draft -20

And it would appear that you do not care about problems such as the Bleichenbacher attack.

                                                            -- Mike

                                                            -- Mike

Hi Jim,

                                                                -- Mike

Jim