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

From: Matt Miller <[email-masked]>
Date: Wed, 4 Jun 2014 16:17:49 -0600

[ Forwarding to the [email-masked] mailing list on behalf of Thjis
Alkemade ]

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: Wed, 4 Jun 2014 16:46:21 -0600

On 6/4/14, 4:17 PM, Matt Miller wrote:
> Today, I've spent some time on trying to implement POSH-checking
> for xmpp.net. My implementation aimed to do two things: doing the 
> 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:
> 
> 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.
> 
> 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.
> 
> Best regards, Thijs

As I stated in the previous venue ([email-masked]), 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).

- --
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Kim Alvefur <[email-masked]>
Date: Sun, 08 Jun 2014 13:40:48 +0200

> draft-ietf-xmpp-posh out relatively soon (by next week).

I'm ok with this.

--
Kim "Zash" Alvefur

---

From: Thijs Alkemade <[email-masked]>
Date: Mon, 9 Jun 2014 19:34:23 +0200

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

On 5 jun. 2014, at 00:46, Matt Miller <[email-masked]> wrote:

> Signed PGP part

This looks good to me!

Thijs

---

From: Thijs Alkemade <[email-masked]>
Date: Mon, 9 Jun 2014 19:31:33 +0200

This looks good to me!

Thijs

---

From: Matt Miller <[email-masked]>
Date: Tue, 10 Jun 2014 11:24:19 -0600

On 6/9/14, 11:34 AM, Thijs Alkemade wrote:
>> Signed PGP part On 6/4/14, 4:17 PM, Matt Miller wrote:
>>> [ Forwarding to the [email-masked] mailing list on behalf of
>>> Thjis Alkemade ]
>>> 
>>> 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 "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.
>>> 
>>> 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 ([email-masked]), 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 }
>> 
>> 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
>> 

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

- -- 
- - m&m