From: Mike Jones [mailto:[email protected]] Sent: Friday, February 07, 2014 6:04 PM To: Jim Schaad Cc: [email protected] 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? 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 <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: 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 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
