Ok, that's just one more "if" statement at the top: 0. Initialize KEYS to the empty set 1. If a key has been speciified by the application for use with this object, add that key to KEYS # Remaining steps are the same.
You could also make KEYS a stack/queue instead of a set, if you want to clarify that the specified key should be tried first. Or even just terminate the processing if a specified key is present. --Richard On Fri, Oct 4, 2013 at 6:25 PM, Jim Schaad <[email protected]> wrote: > Richard,**** > > ** ** > > The problem with this description, is that it does not do any of the > implicit finding of keys that happens when you do not have any of those > fields in. This is what is considered to be the normal case for things > like JWT.**** > > ** ** > > Jim**** > > ** ** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Richard Barnes > *Sent:* Friday, October 04, 2013 9:57 AM > *To:* Jim Schaad > *Cc:* [email protected] > *Subject:* Re: [jose] Issue #93 - How to find a key**** > > ** ** > > I agree that this would be helpful. I would suggest a structure a little > simpler than what you have, basically iterating through the key identifiers > in some order and seeing if the software has a matching key.**** > > ** ** > > # Look for self-describing keys (jwk, jku, x5c, x5u), then look for key > references (kid, x5t)**** > > ** ** > > 0. Initialize KEYS to the empty set**** > > 1. If "jwk" in header, add value to KEYS**** > > 2. If "jku" in header, fetch URL and add all JWKs in set to KEYS**** > > 3. If "x5c" in header, extract public key and add to KEYS (or > corresponding private key, if present)**** > > 4. If "x5u" in header, fetch URL and process first certificate as "x5c"*** > * > > 5. If "kid" in header and "kid" value represents a known key, add > corresponding key to KEYS**** > > 6. If "x5t" in header and "x5t" value matches a known cert, add > corresponding key to KEYS**** > > ** ** > > Obviously, any of the lines can be omitted if the implementation doesn't > support that identifier type. You could also express this as a single-key > search, terminating once you find a key.**** > > ** ** > > FWIW, the relevant code in PyJOSE is here:**** > > <https://github.com/bifurcation/pyjose/blob/master/jose/josecrypto.py#L165 > >**** > > ** ** > > --Richard**** > > ** ** > > On Thu, Sep 12, 2013 at 5:09 PM, Jim Schaad <[email protected]> > wrote:**** > > I have filed an issue that boils down to the following statement:**** > > **** > > There should be non-normative appendix to JWS that gives a > procedure/algorithm for locating keys based on the different things that > can be placed in a JOSE message.**** > > **** > > I have been told a large number of ways to do this over time, and I think > we need to place this all into a single location that gives some guidance > about how to do this. This is a list of the ways that I think there are > currently to locate keys:**** > > **** > > A. Look for certificates:**** > > a. Identify an EE certificate and a certificate list**** > > i. Is > there an x5u? Follow the link and down load the certificates to get a > certificate list and set the EE certificate to the zero-th entry in the list > **** > > ii. Is > there an x5t? Locate the EE certificate in local storage and set the > certificate list to that certificate**** > > iii. Is > there an x5c? Set the EE certificate to the first item in the list. Set > the certificate list to the array of certificates.**** > > b. Do path building from the EE certificate to a trusted root using > the certificate list and local certificate stores.**** > > c. Validate the path to a trust point**** > > B. Look for JWK Sets**** > > a. Create an empty JWK set KEYS**** > > b. Is there a jku? Down load from the pointer and add to KEYS we > are maintaining.**** > > c. Is there a jkw? Add it to KEYS**** > > d. Are there application JWKs? Add them to KEYS**** > > e. Are there local JWKs? Add them to KEYS**** > > C. Find viable keys in KEYS**** > > a. Is there a kid? Remove items from KEYS which have a kid and it > does match, leave items with kid value in the KEYS**** > > b. Remove items from KEYS based on the algorithm in the alg member. > If a key element in KEYS does not support the algorithm, remove it. This > examines the ‘kty’ member and the ‘alg’ member if it is present.**** > > c. Remove items from KEYS based on the use member. If a key > element in KEYS has a use member and it does not match the required use > for the JOSE element, remove it from KEYS.**** > > D. Check each of the key values in KEYS to see if it > validates/decrypts the object.**** > > **** > > **** > > I have no idea if the above set of steps is complete in any sense of the > word. If there are steps in it that people disagree with or not.**** > > **** > > Please comment both on the concept of adding the appendix and the steps > laid out above. And please remember that I am looking for an informational > not a normative appendix.**** > > **** > > Jim**** > > **** > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
