Subject: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31

From: Tero Kivinen <[email-masked]>
Date: Thu, 4 Sep 2014 15:02:37 +0300

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: This document has issues.

This document is part of the jose-json document set, and describres
the JSON Web Signatures.

The security considerations section includes text which says:

   The entire list of security considerations is beyond the scope of
   this document, but some significant considerations are listed here.

but also lists quite a lot of security considerations. I think the
security considerations covering this document should be in scope with
the document. Of course there are generic security considerations
which might be outside the scope of this document, but I do not think
we need to explictly mention those.

I have following issues about the draft:

   1) "alg" and Protected Header

   2) Hash inside "alg" and inside the signature

   3) There is no explict warning about the "alg" "none".

   4) Thumbprint formats

There is also following nit:

   5) Terminology ordering.

----------------------------------------------------------------------

1) "alg" and Protected Header

Question: Shouldn't the "alg" header parameter be protected by the
signature, i.e. wouldn't it make sense to say MUST be in the
"Protected Header"?

If it is part of the "Unprotected Header" and is not protected by the
signature, that would allow all kind of attacks, i.e. changing the
"alg" to be "none" or changing the hash algorithm of the signature.

If it should be part of the "Protected Header" then that would mean
that "Proteced Header" cannot be empty, as "alg" is mandatory header
parameter, and MUST be present.

There are several cases where the text indicates that "Protected
Header" could be empty, which would mean that "alg" could be part of
the "Unprotected Header". (Section 5.1, 4. bullet; section 7.2,
"protected" element and other places in same section). In all examples
the "alg" is always in the "Proteced Header". 

I think the draft needs text saying something about the situation
where "alg" is not in "Protected Header" in the security sections
section. I.e. either say, that it has been analyzed that there is no
problem even when the "alg" is not protected, and reference to such
analysis, or otherwise add text/warning that it MUST/SHOULD be in the
"Protected Header". I do not know enough about the proposed signature
algorithms to know which one is true, especially as there might be new
algorithms in the future.

--

2) Hash inside "alg" and inside the signature

Also in some cases the signature itself has the hash function stored
internally, i.e. RSASSA-PKCS1-V1_5 contains the hash function oid
inside the signature, so what should the implementation do if the
"alg" parameter outside the signature does not match the oid inside
the signature? I.e the signature using "alg" of "RS256", but inside
the signature the oid is using the "SHA1". Most crypto libraries will
just take the oid from the signature, and use that to verify the
message. Adding some description what to do in such situation would be
needed.

--

3) There is no explict warning about the "alg" "none".

In the section 5.2 it says that "at least one signature ... MUST
successfully validate", but that does not limit alg "none" out from
it. I.e. if the application policy is to "one signature needs to
validate", and it gets JWS that has "none" as one of the algorithms,
then it will accept it.

I think there should be warning here or in the security considerations
section about the "none" algorithm, especially as the algorithm itself
is defined in the different draft (perhaps just reference to the
section 8.5 of the [JWA] draft).

--

4) Thumbprint formats

Section 4.1.7 and 4.1.8 defines a x5t and x5t#S256 thumbprints, but
those are over the whole certificate.

With the thumbprints, it has been noted lately, that quite often it is
more useful to use the hash of the SubjectPublicKeyInfo object of the
X.509 certificate, than the full X.509 certificate. This method has
been used in the raw public key methods (draft-ietf-tls-oob-pubkey,
draft-kivinen-ipsecme-oob-pubkey), and also in the DANE (it has two
options one for the full certificate and another for the
SubjectPublicKeyInfo object of the certificate).

Using hash of the SubjectPublicKeyInfo object allows changing the
certificate without invalidiating the certificates, i.e. when changing
CAs, or switching from SHA1 to SHA2 in certificates, or just renewing
the certificate. It also allows using raw public keys which do not
have defined X.509 certificate format, but which can be converted to
the SubjectPublicKeyInfo object when calculating the thumbprints. This
is very important in the Internet of Things type of things, which
might not be using the full X.509 certificates. 

--

5) Terminology ordering.

Terminology is not in any order. It would be useful to have it either
in logical order (i.e. define terms before they are used), or in
alphabetical order.

Now for example the "JWS Protected Header" is used before it is
defined in the "JWS Signature", and "Header Paramater" is between "JWS
Signature" and "JWS Protected Header", also "JWS Signature" uses both
"JWS Payload" and "JWS Protected Header", and one of those is defined
before and one after the "JWS Signature".
-- 
[email-masked]

---

From: Mike Jones <[email-masked]>
Date: Sat, 6 Sep 2014 00:56:14 +0000

Thanks for the useful review, Tero.  I've cc'ed the working group to make them aware of the contents of your review.  Also, Richard Barnes, please see a request for a reply from you on one issue below.  Replies are inline below...

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]]
Sent: Thursday, September 04, 2014 5:03 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Secdir review of draft-ietf-jose-json-web-signature-31

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document is part of the jose-json document set, and describres the JSON Web Signatures.

but also lists quite a lot of security considerations. I think the security considerations covering this document should be in scope with the document. Of course there are generic security considerations which might be outside the scope of this document, but I do not think we need to explictly mention those.

Several reviewers have objected to this sentence.  Its removal is planned.

Also, additional security considerations will be described in the process of resolving Russ Housley's gen-art review comments.

   4) Thumbprint formats

   5) Terminology ordering.

Question: Shouldn't the "alg" header parameter be protected by the signature, i.e. wouldn't it make sense to say MUST be in the "Protected Header"?

If it is part of the "Unprotected Header" and is not protected by the signature, that would allow all kind of attacks, i.e. changing the "alg" to be "none" or changing the hash algorithm of the signature.

If it should be part of the "Protected Header" then that would mean that "Proteced Header" cannot be empty, as "alg" is mandatory header parameter, and MUST be present.

There are several cases where the text indicates that "Protected Header" could be empty, which would mean that "alg" could be part of the "Unprotected Header". (Section 5.1, 4. bullet; section 7.2, "protected" element and other places in same section). In all examples the "alg" is always in the "Proteced Header".

I think the draft needs text saying something about the situation where "alg" is not in "Protected Header" in the security sections section. I.e. either say, that it has been analyzed that there is no problem even when the "alg" is not protected, and reference to such analysis, or otherwise add text/warning that it MUST/SHOULD be in the "Protected Header". I do not know enough about the proposed signature algorithms to know which one is true, especially as there might be new algorithms in the future.

Richard Barnes, do you want to answer this one?  You were the primary advocate for allowing the algorithm to be unprotected in the JSON Serialization.

As I recall, the motivation had to do with the fact that, by default, CMS does not protect the algorithm (although it was later extended to enable it to be protected).  Some others in the working group thought that having unprotected algorithms was a bad idea, in line with your comment above.

--

Also in some cases the signature itself has the hash function stored internally, i.e. RSASSA-PKCS1-V1_5 contains the hash function oid inside the signature, so what should the implementation do if the "alg" parameter outside the signature does not match the oid inside the signature? I.e the signature using "alg" of "RS256", but inside the signature the oid is using the "SHA1". Most crypto libraries will just take the oid from the signature, and use that to verify the message. Adding some description what to do in such situation would be needed.

I think there's some confusion here, since the JWS spec does not use any OIDs or ASN.1 for signatures.  Rather, the cryptographic operations to be performed are fully specified by the "alg" value and the signatures are represented as base64url encoded octet sequences representing the signature values produced by the signature algorithms.

--

In the section 5.2 it says that "at least one signature ... MUST successfully validate", but that does not limit alg "none" out from it. I.e. if the application policy is to "one signature needs to validate", and it gets JWS that has "none" as one of the algorithms, then it will accept it.

I think there should be warning here or in the security considerations section about the "none" algorithm, especially as the algorithm itself is defined in the different draft (perhaps just reference to the section 8.5 of the [JWA] draft).

This warning is present in the spec where the algorithm is defined - specifically http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-8.5.  (Note that the working group decided to define algorithms in a separate spec than the ones in which they are used.)

Also note that it is up to applications which algorithms are acceptable in a given context - not just "none" but also other algorithms that might be deprecated or inappropriate for some other reason.  Unless the signature algorithm used is acceptable to the application, it should not accept the JWT.

--

4) Thumbprint formats

Section 4.1.7 and 4.1.8 defines a x5t and x5t#S256 thumbprints, but those are over the whole certificate.

With the thumbprints, it has been noted lately, that quite often it is more useful to use the hash of the SubjectPublicKeyInfo object of the

X.509 certificate, than the full X.509 certificate. This method has been used in the raw public key methods (draft-ietf-tls-oob-pubkey, draft-kivinen-ipsecme-oob-pubkey), and also in the DANE (it has two options one for the full certificate and another for the SubjectPublicKeyInfo object of the certificate).

Using hash of the SubjectPublicKeyInfo object allows changing the certificate without invalidiating the certificates, i.e. when changing CAs, or switching from SHA1 to SHA2 in certificates, or just renewing the certificate. It also allows using raw public keys which do not have defined X.509 certificate format, but which can be converted to the SubjectPublicKeyInfo object when calculating the thumbprints. This is very important in the Internet of Things type of things, which might not be using the full X.509 certificates.

This thumbprint definition matches existing practice in commonly used software packages.  For instance, both openssl and Windows use certificate thumbprints of this kind.

That being said, there's nothing preventing another specification from defining a different thumbprint calculation over the SPKI information and a header parameter used to represent it.  The header parameters are extensible via a registry.

--

5) Terminology ordering.

Terminology is not in any order. It would be useful to have it either in logical order (i.e. define terms before they are used), or in alphabetical order.

Now for example the "JWS Protected Header" is used before it is defined in the "JWS Signature", and "Header Paramater" is between "JWS Signature" and "JWS Protected Header", also "JWS Signature" uses both "JWS Payload" and "JWS Protected Header", and one of those is defined before and one after the "JWS Signature".

The terms are listed in top-down order, with related terms grouped together.  Thus "JSON Web Signature" is first, the members that make up a JWS object are listed together in the order that they appear in a JWS, etc.  That being said, I'll plan to review the orderings and make sure that they consistently follow those ordering rules.

--

[email-masked]<mailto:[email-masked]>

                                                                Thanks again,

                                                                -- Mike

---

From: Richard Barnes <[email-masked]>
Date: Fri, 12 Sep 2014 17:51:18 -0400

On Fri, Sep 5, 2014 at 8:56 PM, Mike Jones <[email-masked]>
wrote:

>  Thanks for the useful review, Tero.  I’ve cc’ed the working group to
> make them aware of the contents of your review.  Also, Richard Barnes,
> please see a request for a reply from you on one issue below.  Replies are
> inline below…
>
>
>
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
>
>
> security considerations covering this document should be in scope with the
> document. Of course there are generic security considerations which might
> be outside the scope of this document, but I do not think we need to
> explictly mention those.
>
>
>
> Also, additional security considerations will be described in the process
> of resolving Russ Housley’s gen-art review comments.
>
>
>
> signature, i.e. wouldn't it make sense to say MUST be in the "Protected
> Header"?
>
>
>
> signature, that would allow all kind of attacks, i.e. changing the "alg" to
> be "none" or changing the hash algorithm of the signature.
>
>
>
> If it should be part of the "Protected Header" then that would mean that
> "Proteced Header" cannot be empty, as "alg" is mandatory header parameter,
> and MUST be present.
>
>
>
> There are several cases where the text indicates that "Protected Header"
> could be empty, which would mean that "alg" could be part of the
> "Unprotected Header". (Section 5.1, 4. bullet; section 7.2, "protected"
> element and other places in same section). In all examples the "alg" is
> always in the "Proteced Header".
>
>
>
> I think the draft needs text saying something about the situation where
> "alg" is not in "Protected Header" in the security sections section. I.e.
> either say, that it has been analyzed that there is no problem even when
> the "alg" is not protected, and reference to such analysis, or otherwise
> add text/warning that it MUST/SHOULD be in the "Protected Header". I do not
> know enough about the proposed signature algorithms to know which one is
> true, especially as there might be new algorithms in the future.
>
>
>
> Richard Barnes, do you want to answer this one?  You were the primary
> advocate for allowing the algorithm to be unprotected in the JSON
> Serialization.
>
>
>
> As I recall, the motivation had to do with the fact that, by default, CMS
> does not protect the algorithm (although it was later extended to enable it
> to be protected).  Some others in the working group thought that having
> unprotected algorithms was a bad idea, in line with your comment above.
>
The only need for protection of the "alg" value is to prevent algorithm
substitution attacks, as discussed in RFC 6211.
https://tools.ietf.org/html/rfc6211

These attacks are fairly limited in their applicability, since they require
that:
 * The attacker is able to compute an input that is valid for the signature
using a different, weaker algorithm
 * The attacker's input is valid according to whatever application rules
are being applied
 * A relying party will accept the weaker algorithm

Given all those criteria, it seems reasonable that some signers might
regard algorithm substitution attacks as an acceptable risk.  For example,
in an application that set explicit minimum algorithm requirements (e.g.,
SHA-3 only!), there may be no risk of a relying party accepting the weaker
algorithm.  Or the application payload might have low enough entropy that
it's impossible to find a valid forged input.

And if an application is concerned about algorithm substitution attacks, it
can protect itself by including the algorithm in the payload, as X.509 does.

I would be happy to have some advisory text in the security considerations,
but I don't think this rises to the level of SHOULD/MUST.

--Richard

> internally, i.e. RSASSA-PKCS1-V1_5 contains the hash function oid inside
> the signature, so what should the implementation do if the "alg" parameter
> outside the signature does not match the oid inside the signature? I.e the
> signature using "alg" of "RS256", but inside the signature the oid is using
> the "SHA1". Most crypto libraries will just take the oid from the
> signature, and use that to verify the message. Adding some description what
> to do in such situation would be needed.
>
>
>
> I think there’s some confusion here, since the JWS spec does not use any
> OIDs or ASN.1 for signatures.  Rather, the cryptographic operations to be
> performed are fully specified by the “alg” value and the signatures are
> represented as base64url encoded octet sequences representing the signature
> values produced by the signature algorithms.
>
>
>
> --
>
>
>
> successfully validate", but that does not limit alg "none" out from it.
> I.e. if the application policy is to "one signature needs to validate", and
> it gets JWS that has "none" as one of the algorithms, then it will accept
> it.
>
>
>
> section about the "none" algorithm, especially as the algorithm itself is
> defined in the different draft (perhaps just reference to the section 8.5
> of the [JWA] draft).
>
>
>
> This warning is present in the spec where the algorithm is defined –
> specifically
> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-8.5.
> (Note that the working group decided to define algorithms in a separate
> spec than the ones in which they are used.)
>
>
>
> Also note that it is up to applications which algorithms are acceptable in
> a given context – not just “none” but also other algorithms that might be
> deprecated or inappropriate for some other reason.  Unless the signature
> algorithm used is acceptable to the application, it should not accept the
> JWT.
>
>
>
> --
>
>
>
> 4) Thumbprint formats
>
>
>
> X.509 certificate, than the full X.509 certificate. This method has been
> used in the raw public key methods (draft-ietf-tls-oob-pubkey,
> draft-kivinen-ipsecme-oob-pubkey), and also in the DANE (it has two options
> one for the full certificate and another for the SubjectPublicKeyInfo
> object of the certificate).
>
>
>
> certificate without invalidiating the certificates, i.e. when changing CAs,
> or switching from SHA1 to SHA2 in certificates, or just renewing the
> certificate. It also allows using raw public keys which do not have defined
> X.509 certificate format, but which can be converted to the
> SubjectPublicKeyInfo object when calculating the thumbprints. This is very
> important in the Internet of Things type of things, which might not be
> using the full X.509 certificates.
>
>
>
> This thumbprint definition matches existing practice in commonly used
> software packages.  For instance, both openssl and Windows use certificate
> thumbprints of this kind.
>
>
>
> That being said, there’s nothing preventing another specification from
> defining a different thumbprint calculation over the SPKI information and a
> header parameter used to represent it.  The header parameters are
> extensible via a registry.
>
>
>
> --
>
>
>
> 5) Terminology ordering.
>
>
>
> Terminology is not in any order. It would be useful to have it either in
> logical order (i.e. define terms before they are used), or in alphabetical
> order.
>
>
>
> Now for example the "JWS Protected Header" is used before it is defined in
> the "JWS Signature", and "Header Paramater" is between "JWS Signature" and
> "JWS Protected Header", also "JWS Signature" uses both "JWS Payload" and
> "JWS Protected Header", and one of those is defined before and one after
> the "JWS Signature".
>
>
>
> The terms are listed in top-down order, with related terms grouped
> together.  Thus “JSON Web Signature” is first, the members that make up a
> JWS object are listed together in the order that they appear in a JWS,
> etc.  That being said, I’ll plan to review the orderings and make sure that
> they consistently follow those ordering rules.
>
>
>
> --
>
> [email-masked]
>
>
>
>                                                                 Thanks
> again,
>
>                                                                 -- Mike
>
>
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 16 Sep 2014 11:51:01 +0300

Richard Barnes writes:
>>>     Question: Shouldn't the "alg" header parameter be protected by
>>>     the signature, i.e. wouldn't it make sense to say MUST be in
>>>     the "Protected Header"?
>>>    
>>>     I think the draft needs text saying something about the
>>>     situation where "alg" is not in "Protected Header" in the
>>>     security sections section. I.e. either say, that it has been
>>>     analyzed that there is no problem even when the "alg" is not
>>>     protected, and reference to such analysis, or otherwise add
>>>     text/warning that it MUST/SHOULD be in the "Protected Header".
>>>     I do not know enough about the proposed signature algorithms
>>>     to know which one is true, especially as there might be new
>>     Richard Barnes, do you want to answer this one?  You were the
>>     primary advocate for allowing the algorithm to be unprotected
>>     in the JSON Serialization.
>>    
>>     As I recall, the motivation had to do with the fact that, by
>>     default, CMS does not protect the algorithm (although it was
>>     later extended to enable it to be protected).  Some others in
>>     the working group thought that having unprotected algorithms
>>     was a bad idea, in line with your comment above.
>
>  * The attacker's input is valid according to whatever application rules are
> being applied
> Given all those criteria, it seems reasonable that some signers
> might regard algorithm substitution attacks as an acceptable risk. 

Perhaps, but is there benefits for leaving the alg without protection? 

> For example, in an application that set explicit minimum algorithm
> requirements (e.g., SHA-3 only!), there may be no risk of a relying
> party accepting the weaker algorithm.  Or the application payload
> might have low enough entropy that it's impossible to find a valid
> forged input.
> 
> And if an application is concerned about algorithm substitution
> attacks, it can protect itself by including the algorithm in the
> payload, as X.509 does.

Having this kind of options which might or might not have security is
usually bad. So I would suggest that unless there is use case or real
reason why the alg should NOT be protected all the time, make it
protected always. 

> I would be happy to have some advisory text in the security
> considerations, but I don't think this rises to the level of
> SHOULD/MUST.

I hate to be there in ten years, when someone finds out problems with
this prorotocol, as someone decided to add some new algorithms, and
someone then decided to use the feature include, i.e. having alg
unprotected, and then the combination suddenly causes problems...

So if there is no reason to keep it that way, I would be much more
happy to say that it must be protected always.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 16 Sep 2014 12:27:26 +0300

Mike Jones writes:
>> security considerations covering this document should be in scope
>> with the document. Of course there are generic security
>> considerations which might be outside the scope of this document,
>> but I do not think we need to explictly mention those.
>

Good. 

>> Also in some cases the signature itself has the hash function
>> stored internally, i.e. RSASSA-PKCS1-V1_5 contains the hash
>> function oid inside the signature, so what should the
>> implementation do if the "alg" parameter outside the signature does
>> not match the oid inside the signature? I.e the signature using
>> "alg" of "RS256", but inside the signature the oid is using the
>> "SHA1". Most crypto libraries will just take the oid from the
>> signature, and use that to verify the message. Adding some
>> description what to do in such situation would be needed.
>> 
> I think there's some confusion here, since the JWS spec does not use
> any OIDs or ASN.1 for signatures. Rather, the cryptographic
> operations to be performed are fully specified by the "alg" value
> and the signatures are represented as base64url encoded octet
> sequences representing the signature values produced by the
> signature algorithms.

But JWS uses RSASSA-PKCS1-V1_5, which DOES have ASN.1 inside. I.e. if
you look at the RFC3447 section 8.2 (referenced from the
draft-ietf-jose-json-web-algorithms-31) you will see that when you
generate signature, you first to EMSA-PKCS1-V1_5-ENCODE operation
(section 9.2 of RFC3447) to the message. This will take the hash of
the message, then create the DigestInfo ASN.1 object, which includes
the oid of hash algoritm used in previous step and the actual output
of the hash, and finally you encode the EM by padding that DigestInfo
with suitable padding. After that you do the RSA operation.

When verifying the signature, you do RSA operation, verify the padding
and extract the hash oid and hash value out from the ASN.1 and then
generate EM' by doing EMSA-PKCS1-V1_5-ENCODE operation to the original
message using hash algorithm specified by the oid extracted by
previous operation. 

In most cases the libraries will always do that automatically, and
there is no way to specify that you want to use some other algorith,
than what is stored in the ASN.1, as if you use any other algorithm
that was exactly same than what was stored in the ASN.1 inside the RSA
signature the verification will fail.

In your case there is now two algorithms, the outer "alg" algorithm
and the one inside the signature itself. So even if the outer "alg"
says "RS256", the hash used in the signature might be MD5, and most
crypto libraries will simply verify the signature fine, and this can
cause security problems. 

>> validate", and it gets JWS that has "none" as one of the
>> algorithms, then it will accept it.
>> 
>> I think there should be warning here or in the security
>> considerations section about the "none" algorithm, especially as
>> the algorithm itself is defined in the different draft (perhaps
>> just reference to the section 8.5 of the [JWA] draft).
> 
> This warning is present in the spec where the algorithm is defined
> specifically -
> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31
> #section-8.5. (Note that the working group decided to define
> algorithms in a separate spec than the ones in which they are used.)
> 
> Also note that it is up to applications which algorithms are
> acceptable in a given context - not just "none" but also other
> algorithms that might be deprecated or inappropriate for some other
> reason. Unless the signature algorithm used is acceptable to the
> application, it should not accept the JWT.

The current draft does not have any steps for such policy checks. So
it would be good to add new step in section 5.2 which says that verify
that the algorithms used in the signature are allowed by the policy in
the current context. Also noting that "none" is not really usable
signature algoritm ever... 

>> With the thumbprints, it has been noted lately, that quite often it
>> is more useful to use the hash of the SubjectPublicKeyInfo object
>> of the
>> 
>> certificate without invalidiating the certificates, i.e. when
>> changing CAs, or switching from SHA1 to SHA2 in certificates, or
>> just renewing the certificate. It also allows using raw public keys
>> which do not have defined X.509 certificate format, but which can
>> be converted to the SubjectPublicKeyInfo object when calculating
>> the thumbprints. This is very important in the Internet of Things
>> type of things, which might not be using the full X.509
>> certificates.
> 
> This thumbprint definition matches existing practice in commonly
> used software packages. For instance, both openssl and Windows use
> certificate thumbprints of this kind.

Yes, I am not saying we should remove them. 

> That being said, there's nothing preventing another specification
> from defining a different thumbprint calculation over the SPKI
> information and a header parameter used to represent it. The header
> parameters are extensible via a registry.

Yes, but as I think those formats using SPKI are much more usable,
especially in the internet of things contextes, it might be good idea
to define them now, not year later. On the other hand if these formats
are not meant to be used in the Internet of Things contextes, then
never mind... 

>> 5) Terminology ordering.
>> 
>> Terminology is not in any order. It would be useful to have it
>> either in logical order (i.e. define terms before they are used),
>> or in alphabetical order.
>> 
>> defined in the "JWS Signature", and "Header Paramater" is between
>> "JWS Signature" and "JWS Protected Header", also "JWS Signature"
>> uses both "JWS Payload" and "JWS Protected Header", and one of
>> those is defined before and one after the "JWS Signature".
> 
> together. Thus "JSON Web Signature" is first, the members that make
> up a JWS object are listed together in the order that they appear in
> a JWS, etc. That being said, I'll plan to review the orderings and
> make sure that they consistently follow those ordering rules.

Ok, thanks.
-- 
[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Sep 2014 23:50:29 -0400

On Tue, Sep 16, 2014 at 4:51 AM, Tero Kivinen <[email-masked]> wrote:

> are

Simplicity (if you omit protected headers altogether), and compatibility
with other signed things.  In the sense that you could transform one of
them into a JWS without re-signing.  This would apply, for example, to an
X.509 certificate -- just parse the outer SEQUENCE, and re-assemble into a
JWS with the tbsCertificate as payload.  Same security properties that
X.509 already has.

It's also completely unnecessary for PKCS#1 signatures, which are the
dominant use case today.

In general, I'm opposed to protocols baking in more application-specific
logic than they need to.  The point of JOSE is to describe the
cryptographic operation that was performed, and carry the relevant bits
around.  Its job is not to fix all the weaknesses that every algorithm
has.

--Richard

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 17 Sep 2014 10:59:36 +0300

Richard Barnes writes:
> Simplicity (if you omit protected headers altogether), and
> compatibility with other signed things.  In the sense that you could
> transform one of them into a JWS without re-signing.  This would
> apply, for example, to an X.509 certificate -- just parse the outer
> SEQUENCE, and re-assemble into a JWS with the tbsCertificate as
> payload.  Same security properties that X.509 already has.

Ok, having this kind of information somewhere in the draft would help
to understand the reason. Also having text explaining that is
possible, and that the security properties of this option (i.e. no
problem with PKCS#1, etc... the text you had in the other email). 

> It's also completely unnecessary for PKCS#1 signatures, which are
> the dominant use case today.

I agree.

> In general, I'm opposed to protocols baking in more
> application-specific logic than they need to.  The point of JOSE is
> to describe the cryptographic operation that was performed, and
> carry the relevant bits around.  Its job is not to fix all the
> weaknesses that every algorithm has. 

Yes, but this property might have security issues, so they should be
covered by the security considerations section. 
-- 
[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Wed, 17 Sep 2014 09:24:25 -0400

> covered by the security considerations section.

I'm perfectly happy to have it documented in the Security Considerations.

Mike: Should I generate some text, or do you want to take a stab?

> --
> [email-masked] <javascript:;>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 19 Sep 2014 18:49:42 +0000

I would appreciate it if you would write a draft of the proposed security considerations text, Richard.  Perhaps title the section “Unsecured Algorithm Values”.

                                                            Thanks!
                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Wednesday, September 17, 2014 6:24 AM
To: Tero Kivinen
Cc: Mike Jones; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31

On Wednesday, September 17, 2014, Tero Kivinen <[email-masked]<mailto:[email-masked]>> wrote:

I agree.

--
[email-masked]<javascript:;>

---

From: Mike Jones <[email-masked]>
Date: Fri, 19 Sep 2014 19:02:32 +0000

Tero - for your point "2) Hash inside "alg" and inside the signature", could you please write proposed security considerations text addressing this issue?  I'd think it should describe the need for implementations to ensure that signature verification is done for the exact algorithm specified in the "alg" header parameter, no matter what algorithm information may (or may not) have been encoded into the signature value in an algorithm-specific manner.

For your point "3) There is no explicit warning about the "alg" "none"", I plan to add the additional step that you suggested.

For your point "4) Thumbprint formats" if you or someone else wants to define an additional thumbprint format for use in IoT contexts (or any other contexts), I encourage you to write an Internet Draft that does so, registering the new header parameter defined in the JSON Web Signature and Encryption Header Parameters registry.

				Thanks,
				-- Mike

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Tuesday, September 16, 2014 2:27 AM
To: Mike Jones
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31

Mike Jones writes:
>> considerations which might be outside the scope of this document, but 
>> I do not think we need to explictly mention those.
>

Good. 

>> message. Adding some description what to do in such situation would 
>> be needed.
>> 
> any OIDs or ASN.1 for signatures. Rather, the cryptographic operations 
> to be performed are fully specified by the "alg" value and the 
> signatures are represented as base64url encoded octet sequences 
> representing the signature values produced by the signature 
> algorithms.

But JWS uses RSASSA-PKCS1-V1_5, which DOES have ASN.1 inside. I.e. if you look at the RFC3447 section 8.2 (referenced from the
draft-ietf-jose-json-web-algorithms-31) you will see that when you generate signature, you first to EMSA-PKCS1-V1_5-ENCODE operation (section 9.2 of RFC3447) to the message. This will take the hash of the message, then create the DigestInfo ASN.1 object, which includes the oid of hash algoritm used in previous step and the actual output of the hash, and finally you encode the EM by padding that DigestInfo with suitable padding. After that you do the RSA operation.

When verifying the signature, you do RSA operation, verify the padding and extract the hash oid and hash value out from the ASN.1 and then generate EM' by doing EMSA-PKCS1-V1_5-ENCODE operation to the original message using hash algorithm specified by the oid extracted by previous operation. 

In most cases the libraries will always do that automatically, and there is no way to specify that you want to use some other algorith, than what is stored in the ASN.1, as if you use any other algorithm that was exactly same than what was stored in the ASN.1 inside the RSA signature the verification will fail.

In your case there is now two algorithms, the outer "alg" algorithm and the one inside the signature itself. So even if the outer "alg"
says "RS256", the hash used in the signature might be MD5, and most crypto libraries will simply verify the signature fine, and this can cause security problems. 

>> considerations section about the "none" algorithm, especially as the 
>> algorithm itself is defined in the different draft (perhaps just 
>> reference to the section 8.5 of the [JWA] draft).
> 

The current draft does not have any steps for such policy checks. So it would be good to add new step in section 5.2 which says that verify that the algorithms used in the signature are allowed by the policy in the current context. Also noting that "none" is not really usable signature algoritm ever... 

>> is more useful to use the hash of the SubjectPublicKeyInfo object of 
>> the
>> 
>> changing CAs, or switching from SHA1 to SHA2 in certificates, or just 
>> renewing the certificate. It also allows using raw public keys which 
>> do not have defined X.509 certificate format, but which can be 
>> converted to the SubjectPublicKeyInfo object when calculating the 
>> thumbprints. This is very important in the Internet of Things type of 
>> things, which might not be using the full X.509 certificates.
> 
> software packages. For instance, both openssl and Windows use 

> That being said, there's nothing preventing another specification from 
> defining a different thumbprint calculation over the SPKI information 
> and a header parameter used to represent it. The header parameters are 

Yes, but as I think those formats using SPKI are much more usable, especially in the internet of things contextes, it might be good idea to define them now, not year later. On the other hand if these formats are not meant to be used in the Internet of Things contextes, then never mind... 

>> uses both "JWS Payload" and "JWS Protected Header", and one of those 
>> is defined before and one after the "JWS Signature".
> 
> together. Thus "JSON Web Signature" is first, the members that make up 
> a JWS object are listed together in the order that they appear in a 
> JWS, etc. That being said, I'll plan to review the orderings and make 
> sure that they consistently follow those ordering rules.

Ok, thanks.
--
[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Sep 2014 17:32:24 -0400

"""
# Signature Algorithm Protection

In some usages of JWS, there is a risk of algorithm substitution attacks,
in which an attacker can use an existing signature value with a different
signature algorithm to make it appear that a signer has signed something
that he actually has not.  These attacks have been discussed in detail in
the context of CMS {{RFC 6211}}.  The risk arises when all of the following
are true:

* Verifiers of a signature support multiple algorithms of different
strengths
* Given an existing signature, an attacker can find another payload that
produces the same signature value with a weaker algorithm
* In particular, the payload crafted by the attacker is valid in a given
application-layer context

For example, suppose a verifier is willing to accept both "PS1" and "PS256"
as "alg" values, and a signer creates a signature using "PS256".  If the
attacker can craft a payload that has the same SHA-1 digest has as the
SHA-256 digest of the legitimate payload, then the "PS1" signature over the
bogus payload will be the same as the "PS256" signature over the legitimate
payload.

There are several ways for an application using JOSE to mitigate algorithm
substitution attacks:

* Don't accept signatures using vulnerable algorithms: Algorithm
substitution attacks do not arise for all signature algorithms.
  * Signatures using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not subject
to substitution attacks because the signature value itself encodes the hash
function used.
  * Signatures with HMAC algorithms ("HS1", "HS256", etc.) cannot be
substituted because the signature values have different lengths  Likewise
for signatures with ECDSA algorithms ("ES256", "ES384", etc.).
  * The only algorithms defined in JWA
{{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm
substitution attacks is RSA-PSS ("PS1", "PS256", etc.).  An implementation
that does not support RSA-PSS is not vulnerable to algorithm substitution
attacks.

* Require that the "alg" parameter be carried in the protected header.
(This is the approach taken by RFC 6211.)

* Include a field reflecting the algorithm in the application payload, and
require that it be matched with the "alg" parameter during verification
(This is the approach taken by PKIX {{RFC5280}}.)

Of these mitigations, the only sure solution is the first.  Signing over
the "alg" parameter (directly or indirectly) only makes the attacker's work
more difficult, by requiring that the bogus payload also contain bogus
information about the signing algorithm.  They do not prevent attack by a
sufficiently powerful attacker.
"""

On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones <[email-masked]>
wrote:

>  I would appreciate it if you would write a draft of the proposed
> security considerations text, Richard.  Perhaps title the section
> “Unsecured Algorithm Values”.
>
>
>
>                                                             Thanks!
>
>                                                             -- Mike
>
>
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Wednesday, September 17, 2014 6:24 AM
> *To:* Tero Kivinen
> *Cc:* Mike Jones; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: Secdir review of draft-ietf-jose-json-web-signature-31
>
>
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 19 Sep 2014 22:29:35 +0000

Thanks Richard.  Your proposed text uses the “RS1” and “PS1” algorithms, which WebCrypto has but JOSE doesn’t.  Can you revise the examples to make the same points using only algorithms in JWA?

                                                                Thanks again,
                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, September 19, 2014 2:32 PM
To: Mike Jones
Cc: Tero Kivinen; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31

"""
# Signature Algorithm Protection
In some usages of JWS, there is a risk of algorithm substitution attacks, in which an attacker can use an existing signature value with a different signature algorithm to make it appear that a signer has signed something that he actually has not.  These attacks have been discussed in detail in the context of CMS {{RFC 6211}}.  The risk arises when all of the following are true:

* Verifiers of a signature support multiple algorithms of different strengths
* Given an existing signature, an attacker can find another payload that produces the same signature value with a weaker algorithm
* In particular, the payload crafted by the attacker is valid in a given application-layer context
For example, suppose a verifier is willing to accept both "PS1" and "PS256" as "alg" values, and a signer creates a signature using "PS256".  If the attacker can craft a payload that has the same SHA-1 digest has as the SHA-256 digest of the legitimate payload, then the "PS1" signature over the bogus payload will be the same as the "PS256" signature over the legitimate payload.

There are several ways for an application using JOSE to mitigate algorithm substitution attacks:
* Don't accept signatures using vulnerable algorithms: Algorithm substitution attacks do not arise for all signature algorithms.
  * Signatures using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not subject to substitution attacks because the signature value itself encodes the hash function used.
  * Signatures with HMAC algorithms ("HS1", "HS256", etc.) cannot be substituted because the signature values have different lengths  Likewise for signatures with ECDSA algorithms ("ES256", "ES384", etc.).
  * The only algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm substitution attacks is RSA-PSS ("PS1", "PS256", etc.).  An implementation that does not support RSA-PSS is not vulnerable to algorithm substitution attacks.

* Require that the "alg" parameter be carried in the protected header.  (This is the approach taken by RFC 6211.)
* Include a field reflecting the algorithm in the application payload, and require that it be matched with the "alg" parameter during verification (This is the approach taken by PKIX {{RFC5280}}.)

Of these mitigations, the only sure solution is the first.  Signing over the "alg" parameter (directly or indirectly) only makes the attacker's work more difficult, by requiring that the bogus payload also contain bogus information about the signing algorithm.  They do not prevent attack by a sufficiently powerful attacker.
"""

On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I would appreciate it if you would write a draft of the proposed security considerations text, Richard.  Perhaps title the section “Unsecured Algorithm Values”.

                                                            Thanks!
                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 17, 2014 6:24 AM
To: Tero Kivinen
Cc: Mike Jones; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31

I agree.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 19 Sep 2014 16:25:16 -0700

"""

[JLS] This is not a true statement.  If you support both SHA256 and SHA512/256 then the signature values have the same length.  This will also be an issue if you support both the SHA2 and the SHA3 algorithm sets as they have results of the same length.

[JLS] ECDSA is open to this attack if you support both SHA256 and SHA512/256 the hash lengths are the same.  This will also be an issue if you support both the SHA2 and the SHA3 algorithm sets as they have results of the same length.

[JLS] RSA-PKCS#1.5 is open to this attack if the suggestion of Mike in a message prior to this is put into the text.  That is to allow for the hash inside of the signature and that outside of the signature to differ in value because you only enforce one of the two values.

"""

On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones <[email-masked]> wrote:

                                                            Thanks!

                                                            -- Mike

I agree.

--
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Fri, 19 Sep 2014 22:17:05 -0400

For HMAC changing the  hash from SHA3 256 to SHA2 256 doesn't really get the attacker much as they still don't know the key to be able to create a appropriate fake plaintext.
So simply knowing a value that creates a collision is not sufficient for an attack.

I interpreted Mike's comment on PKCS#1 as being that the signature needs to be verified by the algorithm specified in the "alg" parameter.  That is not to say that if in the case of PKCS#1 padding if the OID is not consistent with the value of "alg" that wouldn't be an error.   I think that would be a invalid JWS.     I do think that should be made clear.  

With PSS if the key is the same length it is true that you are going to be vulnerable to collisions over the plaintext based on the weakest hash you can get the receiver to accept.  
This is not a issue unique to JOSE in any way.   One would be tempted to rule out SHA1 now but it is differentiated by it's key length, so can't be downgraded to from SHA2.

John B.

On Sep 19, 2014, at 7:25 PM, Jim Schaad <[email-masked]> wrote:

> Cc: Tero Kivinen; [email-masked]; [email-masked]; [email-masked]; [email-masked];[email-masked]
> Cc: Mike Jones; [email-masked]; [email-masked]; [email-masked]; [email-masked];[email-masked]
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 19 Sep 2014 20:34:27 -0700

From: jose [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Friday, September 19, 2014 7:17 PM
To: Jim Schaad
Cc: [email-masked]; [email-masked]; Richard Barnes; Tero Kivinen; Michael
Jones; IESG; [email-masked];
[email-masked]
Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31

For HMAC changing the  hash from SHA3 256 to SHA2 256 doesn't really get the
attacker much as they still don't know the key to be able to create a
appropriate fake plaintext.

So simply knowing a value that creates a collision is not sufficient for an
attack.

[JLS] remember that the attacker can be the sender of the message, in this
case the key is known to the attacker.

I interpreted Mike's comment on PKCS#1 as being that the signature needs to
be verified by the algorithm specified in the "alg" parameter.  That is not
to say that if in the case of PKCS#1 padding if the OID is not consistent
with the value of "alg" that wouldn't be an error.   I think that would be a
invalid JWS.     I do think that should be made clear.  

With PSS if the key is the same length it is true that you are going to be
vulnerable to collisions over the plaintext based on the weakest hash you
can get the receiver to accept.  

This is not a issue unique to JOSE in any way.   One would be tempted to
rule out SHA1 now but it is differentiated by it's key length, so can't be
downgraded to from SHA2.

John B.

 

From: Richard Barnes [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Friday, September 19, 2014 2:32 PM
To: Mike Jones
Cc: Tero Kivinen;  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];  <mailto:[email-masked]>
[email-masked];
<mailto:[email-masked]>
[email-masked];
<mailto:[email-masked]> [email-masked]
Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31

"""

In some usages of JWS, there is a risk of algorithm substitution attacks, in
which an attacker can use an existing signature value with a different
signature algorithm to make it appear that a signer has signed something
that he actually has not.  These attacks have been discussed in detail in
the context of CMS {{RFC 6211}}.  The risk arises when all of the following
are true:

[JLS] This is not a true statement.  If you support both SHA256 and
SHA512/256 then the signature values have the same length.  This will also
be an issue if you support both the SHA2 and the SHA3 algorithm sets as they
have results of the same length.

  * The only algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}}
that is vulnerable to algorithm substitution attacks is RSA-PSS ("PS1",
"PS256", etc.).  An implementation that does not support RSA-PSS is not
vulnerable to algorithm substitution attacks.

[JLS] ECDSA is open to this attack if you support both SHA256 and SHA512/256
the hash lengths are the same.  This will also be an issue if you support
both the SHA2 and the SHA3 algorithm sets as they have results of the same
length.

[JLS] RSA-PKCS#1.5 is open to this attack if the suggestion of Mike in a
message prior to this is put into the text.  That is to allow for the hash
inside of the signature and that outside of the signature to differ in value
because you only enforce one of the two values.

Of these mitigations, the only sure solution is the first.  Signing over the
"alg" parameter (directly or indirectly) only makes the attacker's work more
difficult, by requiring that the bogus payload also contain bogus
information about the signing algorithm.  They do not prevent attack by a
sufficiently powerful attacker.

"""

On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones <
<mailto:[email-masked]> [email-masked]> wrote:

I would appreciate it if you would write a draft of the proposed security
considerations text, Richard.  Perhaps title the section "Unsecured
Algorithm Values".

                                                            Thanks!

                                                            -- Mike

From: Richard Barnes [mailto: <mailto:[email-masked]> [email-masked]] 
Sent: Wednesday, September 17, 2014 6:24 AM
To: Tero Kivinen
Cc: Mike Jones;  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];  <mailto:[email-masked]>
[email-masked];
<mailto:[email-masked]>
[email-masked];
<mailto:[email-masked]> [email-masked]
Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31

On Wednesday, September 17, 2014, Tero Kivinen < <mailto:[email-masked]>
[email-masked]> wrote:

I agree.

--
 <mailto:[email-masked]> [email-masked]

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

---

From: John Bradley <[email-masked]>
Date: Sat, 20 Sep 2014 06:54:51 -0400

Hi Jim,

I think I am missing something.

If the sender is the attacker and has the mac key, then they can integrity protect any plaintext they like with any hash that is supported..

This seems more like the sender wants to use a different hash than the receiver prefers situation.

That seems to me like a different security concern than an attacker taking a existing JWS and using a downgrade on the alg parameter to substitute a less collision resistant hash, in order to substitute a plain text (envelope and body in the Compact case) that has the same hash value as that encrypted by the RSA/EC key.

Thanks
John B.

On Sep 19, 2014, at 11:34 PM, Jim Schaad <[email-masked]> wrote:

> Cc: [email-masked]; [email-masked]; Richard Barnes; Tero Kivinen; Michael Jones; IESG; [email-masked]; [email-masked]
> [JLS] remember that the attacker can be the sender of the message, in this case the key is known to the attacker.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 20 Sep 2014 09:45:07 -0700

No, the attack would run as follows:

1.        I send you a message which is hashed

2.       You send back a message which includes the signature in your hash

3.       I take the other message with the bad signature to court and your
signature on the hash confirming you received it.

Jim

From: John Bradley [mailto:[email-masked]] 
Sent: Saturday, September 20, 2014 3:55 AM
To: Jim Schaad
Cc: [email-masked]; [email-masked]; Richard Barnes; Tero Kivinen; Michael
Jones; IESG; [email-masked];
[email-masked]
Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31

Hi Jim,

If the sender is the attacker and has the mac key, then they can integrity
protect any plaintext they like with any hash that is supported..

This seems more like the sender wants to use a different hash than the
receiver prefers situation.

That seems to me like a different security concern than an attacker taking a
existing JWS and using a downgrade on the alg parameter to substitute a less
collision resistant hash, in order to substitute a plain text (envelope and
body in the Compact case) that has the same hash value as that encrypted by
the RSA/EC key.

Thanks

John B.

 

From: jose [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of John Bradley
Sent: Friday, September 19, 2014 7:17 PM
To: Jim Schaad
Cc:  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]>
[email-masked]; Richard Barnes; Tero Kivinen; Michael Jones; IESG;
<mailto:[email-masked]> [email-masked];
<mailto:[email-masked]>
[email-masked]
Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31

John B.

On Sep 19, 2014, at 7:25 PM, Jim Schaad < <mailto:[email-masked]>
[email-masked]> wrote:

"""

"""

                                                            Thanks!

                                                            -- Mike

I agree.

---

From: John Bradley <[email-masked]>
Date: Sat, 20 Sep 2014 13:07:37 -0400

OK but HMAC is not a signature so that won't get you very far.

If I am the attacker and have a collision based on the weaker hash and you accept that why would I bother with changing the Hash alg?

I still see changing the hash alg as part of a digital digital signature as different from doing the same thing with the hash alg of a HMAC integrity protected message.

John B.
On Sep 20, 2014, at 12:45 PM, Jim Schaad <[email-masked]> wrote:

> 3.       I take the other message with the bad signature to court and your signature on the hash confirming you received it.
>  
> Jim
>  
>

---

From: Richard Barnes <[email-masked]>
Date: Sun, 21 Sep 2014 20:32:01 -0400

I think I may have erred by trying to write a treatise on which algorithms
are vulnerable :)  Here's some updated text, trying to be more concise.

Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't
really apply, since JOSE hasn't defined algorithm identifiers for
SHA-512/256 or SHA-3.

"""

For example, suppose a verifier is willing to accept both "PS256" and
"PS384" as "alg" values, and a signer creates a signature using "PS256".
If the attacker can craft a payload that results in the same signature with
SHA-256 as the signature with SHA-384 of the legitimate payload, then the
"PS256" signature over the bogus payload will be the same as the "PS384"
signature over the legitimate payload.

There are several ways for an application using JOSE to mitigate algorithm
substitution attacks
The simplest mitigation is to not accept signatures using vulnerable
algorithms: Algorithm substitution attacks do not arise for all signature
algorithms.  The only algorithms defined in JWA
{{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm
substitution attacks is RSA-PSS ("PS256", etc.).  An implementation that
does not support RSA-PSS is not vulnerable to algorithm substitution
attacks.  (Obviously, if other algorithms are added, then they may
introduce new risks.)

In addition, substitution attacks are only feasible if an attacker can
compute pre-images for the weakest hash function accepted by the
recipient.  All JOSE algorithms use SHA-2 hashes, for which there are no
known pre-image attacks as of this writing.  Until there begin to be
attacks against SHA-2 hashes, even a JOSE implementation that supports PSS
is safe from substitution attacks.

Without restricting algorithms, there are also mitigations at the JOSE and
application layer: At the level of JOSE, an application could require that
the "alg" parameter be carried in the protected header.  (This is the
approach taken by RFC 6211.)  The application could also include a field
reflecting the algorithm in the application payload, and require that it be
matched with the "alg" parameter during verification. (This is the approach
taken by PKIX {{RFC5280}}.)

Of these mitigations, the only sure solution is the first, not to accept
vulnerable algorithms.  Signing over the "alg" parameter (directly or
indirectly) only makes the attacker's work more difficult, by requiring
that the bogus payload also contain bogus information about the signing
algorithm.  They do not prevent attack by a sufficiently powerful attacker.
"""

---

From: John Bradley <[email-masked]>
Date: Sun, 21 Sep 2014 20:47:20 -0400

I like the general direction.

One question,  wouldn't the recipient of a PSS signature detect the substitution of SHA-284 with SHA-256 due to the different key length.

I was under the perhaps mistaken impression that the key lengths needed to be the same and just the alg different eg SHA3 and SHA2 keys of the same length.

If that is the case we probably have not defined any algs currently that may be subject to this.  That is not to say that we shouldn't warn people as new algs are defined.

John B.

On Sep 21, 2014, at 8:32 PM, Richard Barnes <[email-masked]> wrote:

> I think I may have erred by trying to write a treatise on which algorithms are vulnerable :)  Here's some updated text, trying to be more concise.
> 
> Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't really apply, since JOSE hasn't defined algorithm identifiers for SHA-512/256 or SHA-3.
> 
> """
> For example, suppose a verifier is willing to accept both "PS256" and "PS384" as "alg" values, and a signer creates a signature using "PS256".  If the attacker can craft a payload that results in the same signature with SHA-256 as the signature with SHA-384 of the legitimate payload, then the "PS256" signature over the bogus payload will be the same as the "PS384" signature over the legitimate payload.
>  
> There are several ways for an application using JOSE to mitigate algorithm substitution attacks
> 
> The simplest mitigation is to not accept signatures using vulnerable algorithms: Algorithm substitution attacks do not arise for all signature algorithms.  The only algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm substitution attacks is RSA-PSS ("PS256", etc.).  An implementation that does not support RSA-PSS is not vulnerable to algorithm substitution attacks.  (Obviously, if other algorithms are added, then they may introduce new risks.)  
> 
> In addition, substitution attacks are only feasible if an attacker can compute pre-images for the weakest hash function accepted by the recipient.  All JOSE algorithms use SHA-2 hashes, for which there are no known pre-image attacks as of this writing.  Until there begin to be attacks against SHA-2 hashes, even a JOSE implementation that supports PSS is safe from substitution attacks.
> 
> Without restricting algorithms, there are also mitigations at the JOSE and application layer: At the level of JOSE, an application could require that the "alg" parameter be carried in the protected header.  (This is the approach taken by RFC 6211.)  The application could also include a field reflecting the algorithm in the application payload, and require that it be matched with the "alg" parameter during verification. (This is the approach taken by PKIX {{RFC5280}}.)
> 
> Of these mitigations, the only sure solution is the first, not to accept vulnerable algorithms.  Signing over the "alg" parameter (directly or indirectly) only makes the attacker's work more difficult, by requiring that the bogus payload also contain bogus information about the signing algorithm.  They do not prevent attack by a sufficiently powerful attacker.
> """

---

From: John Bradley <[email-masked]>
Date: Sun, 21 Sep 2014 20:59:22 -0400

Also with PSS the attack is largely mitigated if the mask function uses the same hash as the message. http://tools.ietf.org/html/rfc3447#page-29

JWA sec 3.5  requires SHA2 MGF functions for SHA2 message hashes with the equivalent length.

If the same is done when SHA3 is added then I think PSS is not as susceptible to a substitution attack as it might look on the surface.

Sorry I just remembers that there was that mitigation for PSS.

John B.

---

From: Richard Barnes <[email-masked]>
Date: Sun, 21 Sep 2014 21:29:09 -0400

On Sun, Sep 21, 2014 at 8:47 PM, John Bradley <[email-masked]> wrote:

> One question,  wouldn't the recipient of a PSS signature detect the
> substitution of SHA-284 with SHA-256 due to the different key length.
>

No, in both cases, the key is an RSA key.

> I was under the perhaps mistaken impression that the key lengths needed to
> be the same and just the alg different eg SHA3 and SHA2 keys of the same
> length.
>

I think you're probably thinking about HMAC.

--Richard

If that is the case we probably have not defined any algs currently that
> may be subject to this.  That is not to say that we shouldn't warn people
> as new algs are defined.
>
> John B.
>
>

---

From: Richard Barnes <[email-masked]>
Date: Sun, 21 Sep 2014 21:31:53 -0400

On Sun, Sep 21, 2014 at 8:59 PM, John Bradley <[email-masked]> wrote:

> Also with PSS the attack is largely mitigated if the mask function uses
> the same hash as the message. http://tools.ietf.org/html/rfc3447#page-29
>
> If the same is done when SHA3 is added then I think PSS is not as
> susceptible to a substitution attack as it might look on the surface.
>

Certainly, having to change the MGF makes things much harder for the
attacker.  However, in principle an attacker with a sufficiently broken
hash algorithm could compute a preimage for the message *and* the MGF.  As
RFC 3447 says:

"it will be difficult for an opponent to substitute a different hash
function"

... using "difficult" in the sense of "way harder than if we hadn't", not
in the sense of "just as hard as forging the signature".

--Richard

---

From: John Bradley <[email-masked]>
Date: Sun, 21 Sep 2014 22:12:17 -0400

I need to re read Kaliski's paper from CT-RSA 2002 On Hash Function Firewalls in Signature Schemes to see how difficult is difficult. http://bookzz.org/book/2302665/6f0670

This is not exactly a new issue.  I can see other ISEG discussions over the years on this and related topics.

There seems to be a padding consideration for PSS that also acts as a mitigation to prevent the recipient from interpreting the hash to be shorter than was sent.

Having the correct security considerations will help implementers.  The paper above is referenced by a number of RFC, but I see some people did not consider the mitigation effective as the other uses of PSS do not tie the MGF to the signing hash as we did in JWA.

I am just getting on a flight, and will have a look at it tomorrow.

John B.

On Sep 21, 2014, at 9:31 PM, Richard Barnes <[email-masked]> wrote:

> Certainly, having to change the MGF makes things much harder for the attacker.  However, in principle an attacker with a sufficiently broken hash algorithm could compute a preimage for the message *and* the MGF.  As RFC 3447 says:
> 
> "it will be difficult for an opponent to substitute a different hash function"
> 
> ... using "difficult" in the sense of "way harder than if we hadn't", not in the sense of "just as hard as forging the signature".
> 
> --Richard
> 
> 
>

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 21 Sep 2014 19:10:54 -0700

From: jose [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Sunday, September 21, 2014 5:32 PM
To: John Bradley
Cc: [email-masked]; secdir; Jim Schaad; Tero Kivinen; Michael Jones; IESG; [email-masked]; [email-masked]
Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31

[JLS] Richard – are you planning to update this text when (not if) they are defined?  If not then this is still part of the problem even if currently not constrained.  The same could also be said to be not a problem for all of the ECDSA algorithms since there is only one hash defined of any given length.  (I will ignore the really fun problem for DSA and ECDSA where there is a modulus operation that occurs on the hash value thus creating collisions within the same hash function and making matching of hash function lengths and key lengths of primary importance.)  However, as these will almost certainly be defined in the future, they merit inclusion in the potential problems.   I believe that this should be included in the discussion as it is much easier to do than to break the mask function of RSA.  (Breaking the same hash function twice is very non-trival, having two hash functions that produce the same length hash is much easier.)

"""

---

From: Richard Barnes <[email-masked]>
Date: Sun, 21 Sep 2014 22:21:43 -0400

On Sun, Sep 21, 2014 at 10:10 PM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* jose [mailto:[email-masked]] *On Behalf Of *Richard Barnes
> *Sent:* Sunday, September 21, 2014 5:32 PM
> *To:* John Bradley
> *Cc:* [email-masked]; secdir; Jim Schaad; Tero Kivinen; Michael Jones;
> IESG; [email-masked]; [email-masked]
> *Subject:* Re: [jose] Secdir review of
> draft-ietf-jose-json-web-signature-31
>
>
>
> [JLS] Richard – are you planning to update this text when (not if) they
> are defined?  If not then this is still part of the problem even if
> currently not constrained.  The same could also be said to be not a problem
> for all of the ECDSA algorithms since there is only one hash defined of any
> given length.  (I will ignore the really fun problem for DSA and ECDSA
> where there is a modulus operation that occurs on the hash value thus
> creating collisions within the same hash function and making matching of
> hash function lengths and key lengths of primary importance.)  However, as
> these will almost certainly be defined in the future, they merit inclusion
> in the potential problems.   I believe that this should be included in the
> discussion as it is much easier to do than to break the mask function of
> RSA.  (Breaking the same hash function twice is very non-trival, having two
> hash functions that produce the same length hash is much easier.)
>

Is the phrase "Obviously, if other algorithms are added, then they may
introduce new risks" insufficient?

--Richard

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 21 Sep 2014 23:39:38 -0700

From: Richard Barnes [mailto:[email-masked]] 
Sent: Sunday, September 21, 2014 7:22 PM
To: Jim Schaad
Cc: John Bradley; [email-masked]; secdir; Tero Kivinen; Michael Jones; IESG; [email-masked]; [email-masked]
Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31

 

Is the phrase "Obviously, if other algorithms are added, then they may introduce new risks" insufficient?

[JLS] Given the context of the sentence I would say no.  It would seem to apply only to RSA-SSA-PSS and not to any of the DSA/ECDSA algorithms.

--Richard

"""

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Sep 2014 16:26:56 +0300

Richard Barnes writes:
> * Given an existing signature, an attacker can find another payload
> that produces the same signature value with a weaker algorithm

I think one of the major points is that hash algorithms try to make
sure that collisions are hard but ONLY INSIDE the same algorithm. I.e.
it is hard to find collisions for SHA-256. On the other hand nothing
is said how hard it is said to create SHA-1 hash that matches some
SHA-256-160 message. I.e. all the security analysis we have for
SHA-256 are worthless as they do not cover creating collision between
SHA-256 and SHA-1. I.e. SHA-256 was designed to be collision resistant
with SHA-256, but not with SHA-1. It might be secure, or it might not.

I think there are some papers talking about creating collisions
between MD5 and SHA-1, but those are done by analysing the hash
functions, i.e. not while designing the algorithms. I.e. this kind of
attacks were not major design criteria when algorithms were made.

I.e. most of the properties designed in to the hash functions are not
true anymore if we try to match two different algorithms against each
other.

On the other hand I think that one of the design criteria for creating
SHA-2 family was that there is no collisions between different
algorithms in the same family.
-- 
[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Sep 2014 09:41:52 -0400

> algorithms in the same family.

Do you think the above is inaccurate or incomplete, or misses critical
detail?  The level of detail you're talking about doesn't really seem
appropriate for this spec, which is consuming crypto, not designing it.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Sep 2014 16:42:02 +0300

Mike Jones writes:
> Tero - for your point "2) Hash inside "alg" and inside the
> signature", could you please write proposed security considerations
> text addressing this issue?  I'd think it should describe the need
> for implementations to ensure that signature verification is done
> for the exact algorithm specified in the "alg" header parameter, no
> matter what algorithm information may (or may not) have been encoded
> into the signature value in an algorithm-specific manner. 

Something like this:

  In case of algorithms where there is algorithm parameters specified
  also inside the actual signature, the implementations MUST verify
  that the parameters inside the signature and the parameters
  specified by the "alg" Header Parameter match. This includes for
  example the RSASSA-PKCS-v1_5 algorithms ("RS*") where the signature
  contains the hash algorithm and most libraries actually use the hash
  algorithm specified inside the signature when verifying the
  signature. This test is required as the steps in the section 5.2
  verify that algorithms specified by the "alg" Header Parameter are
  acceptable, and if those algorithms could be different the attacker
  could be able to claim to use strong hash algorithm while actually
  using weak one inside the signature. 

> For your point "3) There is no explicit warning about the "alg"
> "none"", I plan to add the additional step that you suggested.

In my text above I assumed you had already added step in section 5.2
to verify that "alg" is acceptable. 

> For your point "4) Thumbprint formats" if you or someone else wants
> to define an additional thumbprint format for use in IoT contexts
> (or any other contexts), I encourage you to write an Internet Draft
> that does so, registering the new header parameter defined in the
> JSON Web Signature and Encryption Header Parameters registry.

That can of course be done, but I would have hoped the initial version
of the specification would also be usable in the IoT context, where
the use of raw public keys will most likely arise.
-- 
[email-masked]

---

From: Mike Jones <[email-masked]>
Date: Mon, 22 Sep 2014 19:19:32 +0000

>> For your point "4) Thumbprint formats" if you or someone else wants to 
>> define an additional thumbprint format for use in IoT contexts (or any 
>> other contexts), I encourage you to write an Internet Draft that does 
>> so, registering the new header parameter defined in the JSON Web 
>> Signature and Encryption Header Parameters registry.
>
> That can of course be done, but I would have hoped the initial version of the specification would also be usable in the IoT context, where the use of raw public keys will most likely arise.

If what you want is a thumbprint over a raw key, see the individual submission draft https://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-01, which defines a method for doing this.  The -01 version incorporates working group feedback from Toronto.  In Toronto, I'd asked whether the working group wanted to adopt it as a working group draft and a decision hasn't been made on that yet.  If this would be useful for IoT applications, that would be good to know.

				-- Mike

---

From: Mike Jones <[email-masked]>
Date: Tue, 23 Sep 2014 01:28:36 +0000

My current editor’s draft contains the following security considerations subsection, which is derived from Richard’s proposed text.  I’m sending it now for working group review, with the intent to publish updated drafts addressing all the Gen-ART and secdir comments received, possibly as early as sometime tomorrow.

This subsection is over three times the size of any of the other security considerations subsections.  It’s my hope, as an editor, that people will suggest ways to drastically shorten it, while retaining understandable and actionable content, before I publish an updated draft.

I obviously hope that people will also review it for correctness.

                                                                Thank you,
                                                                -- Mike

10.7.  Algorithm Protection

In some usages of JWS, there is a risk of algorithm substitution attacks, in which an attacker can use an existing signature value with a different signature algorithm to make it appear that a signer has signed something that it has not. These attacks have been discussed in detail in the context of CMS [RFC6211]. The risk arises when all of the following are true:
·         Verifiers of a signature support multiple algorithms.
·         Given an existing signature, an attacker can find another payload that produces the same signature value with a different algorithm.
·         The payload crafted by the attacker is valid in the application context.

For example, suppose a verifier is willing to accept both PS256 and PS384 as alg values, and a signer creates a signature using PS256. If the attacker can craft a payload that has the same SHA-256 digest as the SHA-384 digest of the legitimate payload, then the PS256 signature over the bogus payload will be the same as the PS384 signature over the legitimate payload.

There are several ways for an application to mitigate algorithm substitution attacks:
·         Don't accept signatures using algorithms vulnerable to substitution attacks. Algorithm substitution attacks are not possible for all signature algorithms. The only algorithms defined in JWA [JWA] that may be vulnerable to algorithm substitution attacks are the RSASSA-PSS (PS256, PS384, etc.) algorithms. An implementation that does not support RSASSA-PSS or other vulnerable algorithms is not susceptible to algorithm substitution attacks. Substitution attacks are only feasible if an attacker can compute pre-images for a hash function accepted by the recipient. All JWA-defined algorithms use SHA-2 hashes, for which there are no known pre-image attacks, as of the time of this writing. Until there are attacks against SHA-2 hashes, even implementations that support RSASSA-PSS are not susceptible to substitution attacks.
·         Require that the alg Header Parameter be carried in the protected header. (This is always the case when using the JWS Compact Serialization and is the approach taken by CMS [RFC6211].)
·         Include a field containing the algorithm in the application payload, and require that it be matched with the alg Header Parameter during verification. (This is the approach taken by PKIX [RFC5280].)

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Sep 2014 12:17:58 +0300

Mike Jones writes:
> > That can of course be done, but I would have hoped the initial
> > version of the specification would also be usable in the IoT
> > context, where the use of raw public keys will most likely arise. 
> 
> If what you want is a thumbprint over a raw key, see the individual
> submission draft
> https://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-01,
> which defines a method for doing this.  The -01 version incorporates
> working group feedback from Toronto.  In Toronto, I'd asked whether
> the working group wanted to adopt it as a working group draft and a
> decision hasn't been made on that yet.  If this would be useful for
> IoT applications, that would be good to know. 

That looks ok for the jwk use, but for the hash over the SPKI parts of
the X.509 is better because that is already used in other places. I.e.
if you want to create fingerprint that can be used to match the key
used in other protocols, they are not using that format defined in
your draft, thus you need to regenerate the JWK format from their
internal public/private key formats and generate new hash.

For example DANE x 1 x format (i.e. 3 1 1 for SHA-256, or 3 1 2 for
SHA-512) defined RFC6698 section 2.1.3 are calculated over the exact
same binary object which is transmitted in the raw keys used in the
TLS (RFC7250 section 3), which is again same binary object used in the
in the IKEv2 (draft-kivinen-ipsecme-oob-pubkey).

In the IoT context it will most likely be quite common to define the
configuration of who can connect to you by using list of hashes of
raw public keys. I.e. the device has list of hashes, and when
connection comes (either over TLS or IKEv2 or whatever), then that raw
public key sent inside the connection protocol is hashed and it is
matched against that list of hashes. If match is found, the connection
is allowed, if not the connection is dropped. Now json might be one
way of this configuration could be transmitted to the IoT device, thus
ability to be able to represent hashes in the format that makes it
possible to match the binary blobs used on the wire, would be useful.

One of the reasons the SPKI is used, that it can also be extracted
from the self-signed certificate, i.e. early implementations might use
self-signed certificates in the TLS (for example) before the RFC7250
implementations come out.

The draft-jones-jose-jwk-thumbprint format is in such format that it
is quite hard to match that against the binary blob we get from the
wire, as to do so would require to format the public key received to
JWK and then calculating the fingerprint of that newly created object.
Parsing SPKI format (and parsing JSON also if we use that for
configurations) is required in the implementations anyways, but in
normal case the IoT devices do not need code for generating JSON
objects.

So I do not think the format you are specifying there is suitable for
IoT uses, but I assume it will still be useful in the JWK in general.
-- 
[email-masked]

---

From: Mike Jones <[email-masked]>
Date: Tue, 23 Sep 2014 23:43:11 +0000

Thanks again for your review, Tero.  The resolutions discussed in this thread have been applied to the -32 draft.

				-- Mike

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Monday, September 22, 2014 6:42 AM
To: Mike Jones
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Secdir review of draft-ietf-jose-json-web-signature-31

Mike Jones writes:
> Tero - for your point "2) Hash inside "alg" and inside the signature", 
> could you please write proposed security considerations text 
> addressing this issue?  I'd think it should describe the need for 
> implementations to ensure that signature verification is done for the 
> exact algorithm specified in the "alg" header parameter, no matter 
> what algorithm information may (or may not) have been encoded into the 
> signature value in an algorithm-specific manner.

Something like this:

> "none"", I plan to add the additional step that you suggested.

In my text above I assumed you had already added step in section 5.2 to verify that "alg" is acceptable.

---

From: Mike Jones <[email-masked]>
Date: Tue, 23 Sep 2014 23:55:27 +0000

Thanks for the additional information, Tero.  That's useful.

Speaking as an individual, rather than as an editor, I'd still suggest that someone with expertise in this area write up a quick individual submission draft defining this additional thumbprint format and if people appear to be using it, ask for it to become a JOSE working group item.  The registry makes adding new parameters like this easy.

Feel free to copy as much text from my individual submission draft as makes sense for yours.

				Best wishes,
				-- Mike

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Tuesday, September 23, 2014 2:18 AM
To: Mike Jones
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Secdir review of draft-ietf-jose-json-web-signature-31

> IoT applications, that would be good to know.

That looks ok for the jwk use, but for the hash over the SPKI parts of the X.509 is better because that is already used in other places. I.e.
if you want to create fingerprint that can be used to match the key used in other protocols, they are not using that format defined in your draft, thus you need to regenerate the JWK format from their internal public/private key formats and generate new hash.

For example DANE x 1 x format (i.e. 3 1 1 for SHA-256, or 3 1 2 for
SHA-512) defined RFC6698 section 2.1.3 are calculated over the exact same binary object which is transmitted in the raw keys used in the TLS (RFC7250 section 3), which is again same binary object used in the in the IKEv2 (draft-kivinen-ipsecme-oob-pubkey).

In the IoT context it will most likely be quite common to define the configuration of who can connect to you by using list of hashes of raw public keys. I.e. the device has list of hashes, and when connection comes (either over TLS or IKEv2 or whatever), then that raw public key sent inside the connection protocol is hashed and it is matched against that list of hashes. If match is found, the connection is allowed, if not the connection is dropped. Now json might be one way of this configuration could be transmitted to the IoT device, thus ability to be able to represent hashes in the format that makes it possible to match the binary blobs used on the wire, would be useful.

One of the reasons the SPKI is used, that it can also be extracted from the self-signed certificate, i.e. early implementations might use self-signed certificates in the TLS (for example) before the RFC7250 implementations come out.

The draft-jones-jose-jwk-thumbprint format is in such format that it is quite hard to match that against the binary blob we get from the wire, as to do so would require to format the public key received to JWK and then calculating the fingerprint of that newly created object.
Parsing SPKI format (and parsing JSON also if we use that for
configurations) is required in the implementations anyways, but in normal case the IoT devices do not need code for generating JSON objects.

So I do not think the format you are specifying there is suitable for IoT uses, but I assume it will still be useful in the JWK in general.
--
[email-masked]