Re: [xmpp] [POSH] What's the point of using JWKs in POSH?

Thijs Alkemade <> Mon, 09 June 2014 17:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D982C1A01AC for <>; Mon, 9 Jun 2014 10:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.556
X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P795gLTsw4ZY for <>; Mon, 9 Jun 2014 10:35:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BADB41A00BD for <>; Mon, 9 Jun 2014 10:35:55 -0700 (PDT)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7C01B2042A for <>; Mon, 9 Jun 2014 19:35:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1402335352; bh=vOtX00BMg2BzSuV1GdDsErH3i+iBV4mNOyEAwUwbWaw=; h=From:Subject:Date:References:To:In-Reply-To; b=p5wZ2bLzne893PyMYxIQ92lj7pvW56Wks2gzsmXHvPYrB+LgstxEPWQsP4vkh9Kbn a/F6eSWW1W5r4/Ia5ZbjXWdGd6s+W6qCQbHniz0lgmhMF8YZpBGeADYe2svvddpXGf mwJWO/DoAbUxATE/kQC342NlqwAIp5EHy/RgxfAg=
From: Thijs Alkemade <>
Content-Type: multipart/signed; boundary="Apple-Mail=_1322ABE1-C9A3-470B-9E8C-565D72786C2A"; protocol="application/pgp-signature"; micalg=pgp-sha1
Message-Id: <>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Date: Mon, 9 Jun 2014 19:34:23 +0200
References: <> <> <>
To: XMPP Group <>
In-Reply-To: <>
X-Mailer: Apple Mail (2.1878.2)
Subject: Re: [xmpp] [POSH] What's the point of using JWKs in POSH?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Jun 2014 17:35:58 -0000

[Resending this message from the right address. Sorry for the duplicate copy, Matt.]

On 5 jun. 2014, at 00:46, Matt Miller <> wrote:

> Signed PGP part
> On 6/4/14, 4:17 PM, Matt Miller wrote:
>> [ Forwarding to the mailing list on behalf of Thjis
>> Alkemade ]
>> Hello,
>> Today, I've spent some time on trying to implement POSH-checking
>> for My implementation aimed to do two things: doing the
>> validation as described and showing someone how they could set up
>> their .well-known file by converting their X509 certificates to
>> JSON Web Keys.
>> The latter part was a lot more work than the former and made me
>> wonder why it is defined the way it is.
>> From draft-ietf-xmpp-posh:
>> Each included JWK object MUST possess the following information:
>> o  The "kty" field set to the appropriate key type used for TLS
>> connections (e.g., "RSA" for a certificate using an RSA key).
>> o  The required public parameters for the key type (e.g., "n" and
>> "e" for a certificate using an RSA key).
>> o  The "x5t" field set to the certificate thumbprint, as described
>> in section 3.6 of [JOSE-JWK].
>> Yet the data that is required in the first and second bullet is
>> never used. It doesn't specify if and how clients should verify
>> it. Verification only uses the x5t field and optionally x5c.
>> There are good arguments for "pinning" just the public key.
>> draft-ietf-websec-key-pinning only uses the SPKI field, DANE can
>> use either the full cert or its SPKI field (and optionally hashed).
>> But the way it is specified here won't allow that: the x5t field
>> always needs to be present and clients should verify it.
>> So the public parameters of the key are useless here, but they make
>> a key >10x as large is they have to be. Generating them is also not
>> as easy: most certificate viewers show a SHA1 fingerprint and it's
>> really easy to do with the openssl cli tool, but extracting n and e
>> and base64-encoding them is a lot more work. I wouldn't even know
>> what to do for ECDSA keys.
>> Are there any interoperability reasons for using JWKs that I'm not
>> aware of? Couldn't it just use a list of SHA1 hashes?
>> Best regards, Thijs
> As I stated in the previous venue (, us authors were
> originally working to support various other use-cases, such as
> browserid.  However, no one is arguing to actually support those other
> use-cases, so the desire to use JWKs is much less.
> My co-author and I discussed this today, and think what would be best
> is to switch from using a JWK-set to (roughly) your suggestion of a
> list of hashes.  It would allow us to stay with a single syntax for
> both the "by-reference" and "by-value" documents, as well as provide a
> simple point of extension (if that is ever necessary).
> An example:
> {
>    "fingerprints": [
>        {
>            "sha-1": "ij39Ctarv+LwSw45qoqaZl7venM=",
>            "sha-256": "WhEr4Lpv2L5pv769aRj9rrm4G6MNNCfQlre23Gol/eA="
>        },
>        {
>            "sha-1": "JWow1EHNSbNyRfhQchi22bjurr0=",
>            "sha-256": "K52a2gXfrjchMLYwv16QyOtv5bkKRE6rnR30hY3JM8k="
>        }
>    ],
>    "expires": 604800
> }
> Each "fingerprint" is a JSON object, where the key is the hash
> algorithm and the value is the base64 encoding of hashing the
> DER-encoded certificate with the given algorithm.  I do think that
> algorithm agility is necessary, which means something more than a
> simple array in my opinion.  Generating this should be very simple; I
> could kludge this together on the command-line pretty quickly
> If the WG is ok with this, we can get a new revision of
> draft-ietf-xmpp-posh out relatively soon (by next week).

This looks good to me!