Re: [jose] Issue #93

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 <ietf@augustcellars.com> 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:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf
> Of *Richard Barnes
> *Sent:* Friday, October 04, 2013 9:57 AM
> *To:* Jim Schaad
> *Cc:* jose@ietf.org
> *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 <jimsch@augustcellars.com>
> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>