Re: [jose] Issue #93 - How to find a key

"Jim Schaad" <ietf@augustcellars.com> Fri, 04 October 2013 22:26 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD39121F9E37 for <jose@ietfa.amsl.com>; Fri, 4 Oct 2013 15:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level:
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5i6f+SOok31g for <jose@ietfa.amsl.com>; Fri, 4 Oct 2013 15:26:21 -0700 (PDT)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC5C21F9E00 for <jose@ietf.org>; Fri, 4 Oct 2013 15:26:21 -0700 (PDT)
Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id E323238F3C; Fri, 4 Oct 2013 15:26:18 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Richard Barnes' <rlb@ipv.sx>, 'Jim Schaad' <jimsch@augustcellars.com>
References: <007c01ceaffc$62090220$261b0660$@augustcellars.com> <CAL02cgRWa1MiNT0VTRoEvVarRLozrwNeumF2dq_QLxiqHhJgsw@mail.gmail.com>
In-Reply-To: <CAL02cgRWa1MiNT0VTRoEvVarRLozrwNeumF2dq_QLxiqHhJgsw@mail.gmail.com>
Date: Fri, 04 Oct 2013 15:25:03 -0700
Message-ID: <017a01cec150$935eefa0$ba1ccee0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_017B_01CEC115.E701EC60"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIX/wPuBPrtBYAQoTrwL2q16WZfvALA5OuKmTybx0A=
Content-Language: en-us
Cc: jose@ietf.org
Subject: Re: [jose] Issue #93 - How to find a key
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Oct 2013 22:26:26 -0000

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