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

Richard Barnes <rlb@ipv.sx> Fri, 04 October 2013 16:57 UTC

Return-Path: <rlb@ipv.sx>
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 A8E1621F9D46 for <jose@ietfa.amsl.com>; Fri, 4 Oct 2013 09:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.739
X-Spam-Level:
X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 0hkk52CHgjFq for <jose@ietfa.amsl.com>; Fri, 4 Oct 2013 09:57:05 -0700 (PDT)
Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 971FB21F9C7B for <jose@ietf.org>; Fri, 4 Oct 2013 09:57:02 -0700 (PDT)
Received: by mail-oa0-f47.google.com with SMTP id i1so4168531oag.6 for <jose@ietf.org>; Fri, 04 Oct 2013 09:57:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QDyC5A8VVQxIhNt1TzmC0SmYkJm7cMxRjoYCQ5k2EGA=; b=Knqy91AhltAeYswyTaZ1q3VkQKITMyYfyqJLtQDWGsUdhCGm28muoFg9Y8c+CGNGag QMDY9SdqyHc90UwTYrmAtzSO/kvYbtbC/vYpNxaIz4UmJFR90Gd4lFsg9oNAXh+LeCXq cNg0sgwVGikNGh65KStsyKDYse0RGS+AP6WW0AT0LQujM8OwqE/zDsiwlVmHf8KLuORt iLioDGV7yzzkZdTwcrweNcHJWQuD2U9R2qiazzNHwfBAwjngYtJwXJ12JG08DFqiii9L /9EdSn8C+M0cTCzPcQeoLvSaqGoAUkTpea0Uq4uNHg/3vcZJjoMu6KDLG+bq82XL3Tlo VuQw==
X-Gm-Message-State: ALoCoQknN3OoHqIXhRFX7P4k5jbnE215E7mPpNSl6REVOWyECzTDiu0fsBvUuj36YOBoXRjdaax9
MIME-Version: 1.0
X-Received: by 10.60.94.164 with SMTP id dd4mr131186oeb.68.1380905822066; Fri, 04 Oct 2013 09:57:02 -0700 (PDT)
Received: by 10.60.31.74 with HTTP; Fri, 4 Oct 2013 09:57:02 -0700 (PDT)
In-Reply-To: <007c01ceaffc$62090220$261b0660$@augustcellars.com>
References: <007c01ceaffc$62090220$261b0660$@augustcellars.com>
Date: Fri, 04 Oct 2013 12:57:02 -0400
Message-ID: <CAL02cgRWa1MiNT0VTRoEvVarRLozrwNeumF2dq_QLxiqHhJgsw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Jim Schaad <jimsch@augustcellars.com>
Content-Type: multipart/alternative; boundary="089e0116028cfe2cfc04e7ed305a"
Cc: "jose@ietf.org" <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 16:57:10 -0000

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
>
>