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

[Matt Miller <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 5/20/14, 12:42 PM, Thijs Alkemade wrote:
> Hello,
> 
> 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, Thijs
> 
> 
> 
> _______________________________________________ posh mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/posh
> 

Hello Thijs,

The desire to use JWK came from wanting to support other very similar
use-cases, including browserid.  But since others haven't picked up on
this, using a full JWK might be overkill now.

The original version of the document called for the response to be a
PEM-encoded certificate, but that has drawbacks for key/certificate
rotation.  It could move back in that direction, with a list of
PEM-encoded certificates.  We would have to be clear on what that list
means (is it the chain to expect, or is it the list of alternates?).

However, there is strong desire for the "by reference" model, where
the response is an application-level redirect, and the actual
keys/hashes are served up by the hosting provider.  It would be nice
to maintain a single syntax, I would think, as is the ability to
indicate a "cache for at least <x>" without requiring (config|code)
changes to the HTTPS servers.

I'll confer with my co-author on some options here.


- -- 
- - m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTh2P4AAoJEDWi+S0W7cO1hPsIAKl9iFPCWXgQlHlWxCzQjTTE
mBK62d0mWZmKRfezaZY3ihEbuDYU7d1oYEW52gw3Td4tLLvOvbuGw9jyh9gROCSR
caQkorwi9N+NQQ9JdYEXXLIY8fU2NiUjOaI8QgLtR4VpJ/XyPMaUvOJo0SksPRUE
CIMYmCtD/zDmL0QwtaWZvoCkXqIvJiJdo/p7cM4YJGNxbPq/3NGhTOvRuDZdP7GK
43qIeSTTkR4DMkKIOZRYY+Ns6ZM+Yj5aUF7HGbNCgJNFKM4A34sAOc4266HsmnyA
iZIBjd6X7NonOKMlmeXD4Jgm9C9t1Bngxk9LLf3JDDjuWzaqKI96L0KESx0gjuk=
=hjA+
-----END PGP SIGNATURE-----