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
- [jose] Issue #93 - How to find a key Jim Schaad
- Re: [jose] Issue #93 - How to find a key Richard Barnes
- Re: [jose] Issue #93 - How to find a key Jim Schaad
- Re: [jose] Issue #93 - How to find a key Richard Barnes