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

Matt Miller <> Tue, 10 June 2014 17:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C7C1D1A00E9 for <>; Tue, 10 Jun 2014 10:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GUpOQW1QTEwU for <>; Tue, 10 Jun 2014 10:24:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCC341A00D4 for <>; Tue, 10 Jun 2014 10:24:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4788; q=dns/txt; s=iport; t=1402421059; x=1403630659; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=EBLWI309kxn2x2mfFuYc2BVshVAL8b9xY4REMEz28ik=; b=kCamIHW8OCjOnfRO4lCegWiuHpl3sUOnXBcx88YKRNtxEVi7TRIrpFS0 n5ZOR8RFucp3Na2e9YGdin24BNdpWtWTPphGaeE8/LniaX2wROJbzuzqn diJF9rchRMHGo1bhCtDFAJDAJtC+F6L9BiPpXatfelqIgPUtOp8HW1gJ2 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.98,1010,1392163200"; d="scan'208";a="51906082"
Received: from ([]) by with ESMTP; 10 Jun 2014 17:24:18 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s5AHOIGs010861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Tue, 10 Jun 2014 17:24:18 GMT
Received: from MAMILLE2-M-T03K.CISCO.COM ( by ( with Microsoft SMTP Server (TLS) id; Tue, 10 Jun 2014 12:24:18 -0500
Message-ID: <>
Date: Tue, 10 Jun 2014 11:24:19 -0600
From: Matt Miller <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: XMPP Group <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
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: Tue, 10 Jun 2014 17:24:23 -0000

Hash: SHA512

On 6/9/14, 11:34 AM, Thijs Alkemade wrote:
> [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!
> Thijs

We'll get a new revision with this change out by next week.

- -- 
- - m&m

Matt Miller < >
Cisco Systems, Inc.
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -