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

From: Thijs Alkemade <[email-masked]>
Date: Tue, 20 May 2014 20:42:58 +0200

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

---

From: Matt Miller <[email-masked]>
Date: Thu, 29 May 2014 10:44:40 -0600

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.
> 
> 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 
> [email-masked] 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 < [email-masked] >
Cisco Systems, Inc.