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

Matt Miller <mamille2@cisco.com> Wed, 04 June 2014 22:17 UTC

Return-Path: <mamille2@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D60281A032B for <xmpp@ietfa.amsl.com>; Wed, 4 Jun 2014 15:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OmjAAUZEWjGJ for <xmpp@ietfa.amsl.com>; Wed, 4 Jun 2014 15:17:57 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737851A0309 for <xmpp@ietf.org>; Wed, 4 Jun 2014 15:17:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2654; q=dns/txt; s=iport; t=1401920271; x=1403129871; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pOcwTRArMaB2EOUC3ciuET0btjkM9Y1i1TnWNPGRBiA=; b=Fy2QJZxvWD2Zv0sQJG6uBlEavHe1ZgRgajVdASSwGEOM30n2ADceUGWq SKgtXitMm+s8B80s26V/K9HSzzH+MvBKqm7hrb5oveekkyNbcXzp5D58R 2Yl4R+/FT/9XWATD1j9bhuxBy/CNCEUCQe/NKMQHEAMsrDlfh1J9ys+TL I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.98,975,1392163200"; d="scan'208";a="327502543"
Received: from rcdn-core-4.cisco.com ([]) by rcdn-iport-9.cisco.com with ESMTP; 04 Jun 2014 22:17:51 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com []) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s54MHp1O024093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jun 2014 22:17:51 GMT
Received: from MAMILLE2-M-T03K.CISCO.COM ( by xhc-rcd-x05.cisco.com ( with Microsoft SMTP Server (TLS) id; Wed, 4 Jun 2014 17:17:50 -0500
Message-ID: <538F9B0D.1030504@cisco.com>
Date: Wed, 4 Jun 2014 16:17:49 -0600
From: Matt Miller <mamille2@cisco.com>
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 <xmpp@ietf.org>
References: <B840DF08-6478-41AC-8894-51B0524ED622@thijsalkema.de>
In-Reply-To: <B840DF08-6478-41AC-8894-51B0524ED622@thijsalkema.de>
X-Enigmail-Version: 1.6
X-Forwarded-Message-Id: <B840DF08-6478-41AC-8894-51B0524ED622@thijsalkema.de>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/osWRhoQ67f9Z3c-RZKaVzyhIneM
Cc: Thijs Alkemade <me@thijsalkema.de>
Subject: [xmpp] Fwd: [POSH] What's the point of using JWKs in POSH?
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jun 2014 22:18:00 -0000

Hash: SHA512

[ Forwarding to the xmpp@ietf.org mailing list on behalf of Thjis
Alkemade ]


Today, I've spent some time on trying to implement POSH-checking for
xmpp.net. 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,
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/