Subject: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter

From: "Peck, Michael A" <[email-masked]>
Date: Wed, 6 Mar 2013 17:28:09 +0000

What is the use case for the "jwk" (JSON Web Key) Header Parameter described in section 4.1.3 of draft-ietf-jose-json-web-signature-08?

It seems unsafe for a signature to provide, unauthenticated (not in a signed certificate or protected by other means), the public key to be used to verify itself. 
I would think this field makes it too easy for implementations to do the wrong thing.

Thanks,
Mike

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Mar 2013 13:45:05 -0500

What's your threat scenario here?

I would note that the signed content of an X.509 certificate also does not
carry any indication of the signer's public key (unless the issuer chooses
to include the optional AuthorityKeyIdentifier extension).  Likewise for
CMS SignedData.  Both of those structures are exactly analogous to JWS in
this regard.

For both JWS and CMS SignedData, the method in which the recipient
authenticates the key used to verify the signature is out of scope.  You
could even say the same thing about X.509, since the issuer public key
could be either a certified key or a trust anchor (provisioned through some
other channel).

On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A <[email-masked]> wrote:

> What is the use case for the "jwk" (JSON Web Key) Header Parameter
> described in section 4.1.3 of draft-ietf-jose-json-web-signature-08?
>
> It seems unsafe for a signature to provide, unauthenticated (not in a
> signed certificate or protected by other means), the public key to be used
> to verify itself.
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: "Peck, Michael A" <[email-masked]>
Date: Wed, 6 Mar 2013 19:20:54 +0000

In the case of JWS, it looks like with the "jwk" header parameter, the signed message itself can contain the raw public key to be used to verify it.
My concern is that the verifier will grab and use the public key without ensuring its authenticity.
This would be analogous to automatically trusting a self-signed X.509 certificate.
There should at least be some Security Considerations language that when "jwk" is used the verifier needs to use out of bands means to assure that the provided public key is trusted.

CMS SignedData does not contain the raw public key used to sign the message itself.
It contains a SignerIdentifier to reference the public key and optionally contains certificates (which would convey the public key, but along with proof that it should be trusted).

Rather than directly including the "raw" public key, JWS provides lots of other safer header parameters to reference the public key.

From: Richard Barnes [mailto:[email-masked]]
Sent: Wednesday, March 06, 2013 1:45 PM
To: Peck, Michael A
Cc: [email-masked]
Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter

I would note that the signed content of an X.509 certificate also does not carry any indication of the signer's public key (unless the issuer chooses to include the optional AuthorityKeyIdentifier extension).  Likewise for CMS SignedData.  Both of those structures are exactly analogous to JWS in this regard.

For both JWS and CMS SignedData, the method in which the recipient authenticates the key used to verify the signature is out of scope.  You could even say the same thing about X.509, since the issuer public key could be either a certified key or a trust anchor (provisioned through some other channel).

On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A <[email-masked]<mailto:[email-masked]>> wrote:
What is the use case for the "jwk" (JSON Web Key) Header Parameter described in section 4.1.3 of draft-ietf-jose-json-web-signature-08?

Thanks,
Mike
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Mar 2013 14:26:37 -0500

No, this is analogous to accepting a certificate signed under a trust
anchor, where that trust anchor was provisioned through some other
protocol.

SignedData doesn't contain the raw key, but it contains a hash
(SignerIdentifier
::= CHOICE { ... subjectKeyIdentifier [0] SubjectKeyIdentifier }).  So the
only difference is that the client has to know how to look up the key.

The right way to handle this is, as you say, to add some security
considerations that mention the risks associated with choosing which keys
should be used to validate signatures.

On Wed, Mar 6, 2013 at 2:20 PM, Peck, Michael A <[email-masked]> wrote:

>  In the case of JWS, it looks like with the “jwk” header parameter, the
> signed message itself can contain the raw public key to be used to verify
> it.****
>
> My concern is that the verifier will grab and use the public key without
> ensuring its authenticity.****
>
> This would be analogous to automatically trusting a self-signed X.509
> certificate.****
>
> There should at least be some Security Considerations language that when
> “jwk” is used the verifier needs to use out of bands means to assure that
> the provided public key is trusted.****
>
> ** **
>
> CMS SignedData does not contain the raw public key used to sign the
> message itself.****
>
> It contains a SignerIdentifier to reference the public key and optionally
> contains certificates (which would convey the public key, but along with
> proof that it should be trusted).****
>
> ** **
>
> Rather than directly including the “raw” public key, JWS provides lots of
> other safer header parameters to reference the public key.****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Wednesday, March 06, 2013 1:45 PM
> *To:* Peck, Michael A
> *Cc:* [email-masked]
> *Subject:* Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header
> parameter****
>
> ** **
>
> What's your threat scenario here?****
>
> ** **
>
> this regard.****
> ** **
> other channel).****
> ** **
> ** **
> On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A <[email-masked]> wrote:*
> ***
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 7 Mar 2013 14:55:32 +1100

I agree, Michael. A raw public key in a JWS is inviting dangerous code.

Key ids are even worse in JWE. An originator encrypts data with a recipient’s public key. The recipient needs to know which of his or her private keys to use to decrypt. JWE defines ways for the originator to include: the raw public key (jwk); a URI for the raw public key (jku) (actually a URI for a collection of raw public keys, one of which is the right one, but there is no indication which one that is); the certificate chain (x5c); and/or a URI for the certificate chain (x5u). This is all pointless — the recipient doesn’t need to be given its own public key or certificate. Only the “kid” (key id) field makes sense.

The originator can also include a hash of the certificate (x5t). The only use I can think of for that is when the originator doesn’t know a key id (eg there is no id-ce-subjectKeyIdentifier extension in the certificate) so it synthesises one. In this situation it would be better to hash the public key (not the certificate) as per RFC 5280 “PKIX certificate and CRL Profile”, section 4.2.1.2. “Subject Key Identifier”.

I don’t think there are any examples that use kid, jwk, jku, x5u, x5c, or x5t in a JOSE message in JWE, JWS, or JWT. Perhaps ensuring each defined field does appear in an example would be a good quality check.

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peck, Michael A
Sent: Thursday, 7 March 2013 6:21 AM
To: Richard Barnes
Cc: [email-masked]
Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter

In the case of JWS, it looks like with the “jwk” header parameter, the signed message itself can contain the raw public key to be used to verify it.
My concern is that the verifier will grab and use the public key without ensuring its authenticity.
This would be analogous to automatically trusting a self-signed X.509 certificate.
There should at least be some Security Considerations language that when “jwk” is used the verifier needs to use out of bands means to assure that the provided public key is trusted.

Rather than directly including the “raw” public key, JWS provides lots of other safer header parameters to reference the public key.

From: Richard Barnes [mailto:[email-masked]]
Sent: Wednesday, March 06, 2013 1:45 PM
To: Peck, Michael A
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter

Thanks,
Mike

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Mar 2013 09:37:13 -0500

> I agree, Michael. A raw public key in a JWS is inviting dangerous code.

Could you be a little more precise here?  What's the danger?

The only difference between a key and a cert is that the cert provides the
recipient with some attributes that go along with the key (signed under
some authority) -- assuming the recipient supports X.509 and has an
appropriate trust anchor.  So the only danger is that the recipient might
not check the attributes before accepting the signature.

This is a completely separate question from whether the signature is valid,
in a cryptological / mathematical sense.  And the answer you're implying
(that not checking attributes is dangerous) is clearly not true in all
cases.  For example, in PGP, you've validated the public key through some
out-of-band channel, and you really do just need the key here.

JOSE should stick to crypto, and stay away from policy.  To do otherwise
would cut off use cases unnecessariliy.

>  Key ids are even worse in JWE. An originator encrypts data with a
> recipient’s public key. The recipient needs to know which of his or her
> private keys to use to decrypt. JWE defines ways for the originator to
> include: the raw public key (jwk); a URI for the raw public key (jku)
> (actually a URI for a collection of raw public keys, one of which is the
> right one, but there is no indication which one that is); the certificate
> chain (x5c); and/or a URI for the certificate chain (x5u). This is all
> pointless — the recipient doesn’t need to be given its own public key or
> certificate. Only the “kid” (key id) field makes sense.
>
> ** **
>
> The originator can also include a hash of the certificate (x5t). The only
> use I can think of for that is when the originator doesn’t know a key id
> (eg there is no id-ce-subjectKeyIdentifier extension in the certificate) so
> it synthesises one. In this situation it would be better to hash the public
> key (not the certificate) as per RFC 5280 “PKIX certificate and CRL
> Profile”, section 4.2.1.2. “Subject Key Identifier”.****
>
> ** **
>
> I don’t think there are any examples that use kid, jwk, jku, x5u, x5c, or
> x5t in a JOSE message in JWE, JWS, or JWT. Perhaps ensuring each defined
> field does appear in an example would be a good quality check.
>

I agree that some of these are not tremendously useful, but they're pretty
harmless except for the additional complexity of trying to support all of
them.

--Richard

> --****
>
> James Manger****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Peck, Michael A
> *Sent:* Thursday, 7 March 2013 6:21 AM
> *To:* Richard Barnes
>
> *Cc:* [email-masked]
> *From:* Richard Barnes [mailto:[email-masked] <[email-masked]>]

---

From: Daniel Holth <[email-masked]>
Date: Fri, 8 Mar 2013 10:00:52 -0500

I use and love the jwk feature "literal public keys". It's useful to
me because the signature has more bandwidth than the mechanism used to
convey trust (for example a signed list of hashes of public keys). Of
course you have to establish trust somehow, but banning keys from
signatures based on a particular notion of how this is accomplished is
limiting.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Mar 2013 18:41:20 +1100

Richard,

Verifying a JWS signature with a raw public key in the JWS provides almost no useful security property. To be useful you need to confirm the authenticity of the public key from some other source. Generally the “other source” that provides the authenticity can provide the actual public key as well.

The “danger” of including a raw public key is that silly code verifies the maths then automatically “trusts” the message. It is only a small danger. I am willing to ignore the danger, but only if there is real value in including the raw public key. Perhaps DANE (key in DNS protected by DNSSEC) is an example of a mechanism that can confirm the authenticity of a hash of a key without providing the actual key. Though wouldn’t it be better to get the full key from DANE once, and only send a key id in every JOSE message?

The closest analogy with certs is whether or not to include the self-signed root cert at the end of a cert chain in the message. It shouldn’t be sent. It often is. That hasn’t caused the sky to fall in, though it wastes a small (non-trivial??) portion of TLS traffic.

--
James Manger

From: Richard Barnes [mailto:[email-masked]]
Sent: Saturday, 9 March 2013 1:37 AM
To: Manger, James H
Cc: Peck, Michael A; [email-masked]
Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter

On Wed, Mar 6, 2013 at 10:55 PM, Manger, James H <[email-masked]<mailto:[email-masked]>> wrote:
I agree, Michael. A raw public key in a JWS is inviting dangerous code.

The only difference between a key and a cert is that the cert provides the recipient with some attributes that go along with the key (signed under some authority) -- assuming the recipient supports X.509 and has an appropriate trust anchor.  So the only danger is that the recipient might not check the attributes before accepting the signature.

This is a completely separate question from whether the signature is valid, in a cryptological / mathematical sense.  And the answer you're implying (that not checking attributes is dangerous) is clearly not true in all cases.  For example, in PGP, you've validated the public key through some out-of-band channel, and you really do just need the key here.

JOSE should stick to crypto, and stay away from policy.  To do otherwise would cut off use cases unnecessariliy.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Peck, Michael A
Sent: Thursday, 7 March 2013 6:21 AM
To: Richard Barnes

Thanks,
Mike

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 08:15:08 -0400

I guess I regard the ability to operate with bare public keys as a feature,
not a bug.  There are many, many ways to authenticate keys, ranging from
X.509 with detailed certificate profiles to pre-shared key fingerprints.
 Having bare public keys lets us address all of these use cases.

--Richard

On Tue, Mar 12, 2013 at 3:41 AM, Manger, James H <
[email-masked]> wrote:

> Richard,****
>
> ** **
>
> Verifying a JWS signature with a raw public key in the JWS provides almost
> no useful security property. To be useful you need to confirm the
> authenticity of the public key from some other source. Generally the “other
> source” that provides the authenticity can provide the actual public key as
> well.****
>
> ** **
>
> The “danger” of including a raw public key is that silly code verifies the
> maths then automatically “trusts” the message. It is only a small danger. I
> am willing to ignore the danger, but only if there is real value in
> including the raw public key. Perhaps DANE (key in DNS protected by DNSSEC)
> is an example of a mechanism that can confirm the authenticity of a hash of
> a key without providing the actual key. Though wouldn’t it be better to get
> the full key from DANE once, and only send a key id in every JOSE message?
> ****
>
> ** **
>
> The closest analogy with certs is whether or not to include the
> self-signed root cert at the end of a cert chain in the message. It
> shouldn’t be sent. It often is. That hasn’t caused the sky to fall in,
> though it wastes a small (non-trivial??) portion of TLS traffic.****
>
> ** **
>
> --****
>
> James Manger****
>
> ** **
>
> *Sent:* Saturday, 9 March 2013 1:37 AM
> *To:* Manger, James H
> *Cc:* Peck, Michael A; [email-masked]
>
> [email-masked]> wrote:****
>
> I agree, Michael. A raw public key in a JWS is inviting dangerous code.***
> *
>
> ** **
>
> Could you be a little more precise here?  What's the danger?****
>
> ** **
>
> not check the attributes before accepting the signature.****
>
> ** **
>
> This is a completely separate question from whether the signature is
> valid, in a cryptological / mathematical sense.  And the answer you're
> implying (that not checking attributes is dangerous) is clearly not true in
> all cases.  For example, in PGP, you've validated the public key through
> some out-of-band channel, and you really do just need the key here.****
>
> ** **
>
> would cut off use cases unnecessariliy.****
>
> ** **
>
> ****
>  ****
>  ****
>  ****
>  ****
> ****

---

From: "Peck, Michael A" <[email-masked]>
Date: Tue, 12 Mar 2013 18:31:43 +0000

JWS already has several X.509 header parameters, and the "kid" header parameter can be used anywhere those don't fit - such as to provide a fingerprint to identify the public key.
If implementations really wanted to (though I wouldn't recommend this), they could stuff the raw public key itself in the "kid".

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 8:15 AM
To: Manger, James H
Cc: [email-masked]
Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter

I guess I regard the ability to operate with bare public keys as a feature, not a bug.  There are many, many ways to authenticate keys, ranging from X.509 with detailed certificate profiles to pre-shared key fingerprints.  Having bare public keys lets us address all of these use cases.

--Richard

On Tue, Mar 12, 2013 at 3:41 AM, Manger, James H <[email-masked]<mailto:[email-masked]>> wrote:
Richard,

Verifying a JWS signature with a raw public key in the JWS provides almost no useful security property. To be useful you need to confirm the authenticity of the public key from some other source. Generally the "other source" that provides the authenticity can provide the actual public key as well.

The "danger" of including a raw public key is that silly code verifies the maths then automatically "trusts" the message. It is only a small danger. I am willing to ignore the danger, but only if there is real value in including the raw public key. Perhaps DANE (key in DNS protected by DNSSEC) is an example of a mechanism that can confirm the authenticity of a hash of a key without providing the actual key. Though wouldn't it be better to get the full key from DANE once, and only send a key id in every JOSE message?

The closest analogy with certs is whether or not to include the self-signed root cert at the end of a cert chain in the message. It shouldn't be sent. It often is. That hasn't caused the sky to fall in, though it wastes a small (non-trivial??) portion of TLS traffic.

--
James Manger

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, 9 March 2013 1:37 AM
To: Manger, James H
Cc: Peck, Michael A; [email-masked]<mailto:[email-masked]>

Thanks,
Mike

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 14:32:57 -0400

I would prefer not to encourage abuse of fields.  Let's just provide a
field.
--Richard

On Tue, Mar 12, 2013 at 2:31 PM, Peck, Michael A <[email-masked]> wrote:

>  JWS already has several X.509 header parameters, and the “kid” header
> parameter can be used anywhere those don’t fit – such as to provide a
> fingerprint to identify the public key.****
>
> If implementations really wanted to (though I wouldn’t recommend this),
> they could stuff the raw public key itself in the “kid”.****
>
> ** **
>
> Mike****
>
> ** **
>
> Of *Richard Barnes
> *Sent:* Tuesday, March 12, 2013 8:15 AM
> *To:* Manger, James H
> *Cc:* [email-masked]
>
> I guess I regard the ability to operate with bare public keys as a
> feature, not a bug.  There are many, many ways to authenticate keys,
> ranging from X.509 with detailed certificate profiles to pre-shared key
> fingerprints.  Having bare public keys lets us address all of these use
> cases.****
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
> *Cc:* Peck, Michael A; [email-masked]****
>
>
>  I agree, Michael. A raw public key in a JWS is inviting dangerous code.**
> **
>
>   ****
>
>    *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Peck, Michael A****
>
>
> *To:* Richard Barnes****
> Mike****