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

Thijs Alkemade <[email protected]> Mon, 9 Jun 2014 19:31:33 +0200
Newsgroups	gmane.ietf.xmpp
Message-ID	<[email protected]>
On 5 jun. 2014, at 00:46, Matt Miller <[email protected]> wrote:

> Signed PGP part
> On 6/4/14, 4:17 PM, Matt Miller wrote:
> > [ Forwarding to the [email protected] 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
> 
> As I stated in the previous venue ([email protected]), 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

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp
signature.asc (application/pgp-signature, 841 B)