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 protected]] On Behalf Of Jim Schaad
Sent: Thursday, January 23, 2014 12:41 PM
To: [email protected]
Cc: [email protected]
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
