Subject: Re: [jose] JWS Review, SHA 256 thumbprints - was - AD review of draft-ietf-jose-json-web-algorithms

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 27 May 2014 10:42:19 -0400

The reviews got a little confused with the responses for SHA1 and SHA2
thumbprints.  A couple of people responded supporting Mike's
assertion, but I have had others tell me directly, SHA2 would be good.

Is there a need to support this for the XMPP community, since they set
to SHA256 as a default for certificate fingerprints:
http://xmpp.org/extensions/xep-0189.html

Thanks,
Kathleen

On Wed, May 21, 2014 at 9:51 PM, Nat Sakimura <[email-masked]> wrote:
> ditto here.
>
> The primary reason for having thumbprint was for finding keys in the Windows
> crypto API.
> Security property must not depend on it. If it wants to deal with
> authentication, it should use the keys, IMHO.
>
>
> 2014-05-22 3:10 GMT+09:00 John Bradley <[email-masked]>:
>>
>> I agree with Mike, many key stores use SHA1 thumbprints.   I don't know of
>> any security consideration that makes SHA2 thumbprints better in any
>> practical way.
>>
>> I don't think that adding SHA 2 thumbprints is something that we need to
>> do now.
>>
>> John B.
>>
>> On May 1, 2014, at 1:46 PM, Kathleen Moriarty
>> <[email-masked]> wrote:
>>
>> >>
>> >> Mike> Per your JWS comment, SHA-1 thumbprints are widely deployed.  I’m
>> >> aware of no SHA-256 certificate thumbprint deployments.  I’ll note that
>> >> even
>> >> if SHA-1 were completely broken, that wouldn’t be a security issue
>> >> because
>> >> it’s just being used to generate a digest of publicly available
>> >> certificate
>> >> information.  It’s not being used to cryptographically obscure
>> >> anything.
>> >> (But that’s actually a discussion for another draft. J)
>> >>
>> >
>> > This is in place for the XML equivalents and should be possible for
>> > JSON.  I used this at least 2 years ago in the XML Oxygen editor.  I
>> > believe this has been brought up before in terms of JSON, so I am not
>> > the first.  But it is another draft... I'd like to get through these
>> > all soon :-)
>>
>>
>> _______________________________________________
>> jose mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en

-- 

Best regards,
Kathleen

---

From: Matt Miller <[email-masked]>
Date: Tue, 27 May 2014 09:00:38 -0600

/me dons "XMPP Expert" Hat

There is some desire to use SHA2 but no strong requirement.  As far as
algorithm requirements go, look to [XMPP-TLS], [XEP-0300], and
[XEP-0320] for the results of the community's more current discussions.

- -- 
- - m&m

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

[XMPP-TLS] Use of Transport Layer Security (TLS) in the Extensible
Messaging and Presence Protocol (XMPP) <
http://tools.ietf.org/html/draft-ietf-uta-xmpp-00 >
[XEP-0300] Use of Cryptographic Hash Functions in XMPP <
http://xmpp.org/extensions/xep-0300.html >
[XEP-0320] Use of DTLS-SRTP in Jingle Sessions <
http://xmpp.org/extensions/xep-0320.html >

On 5/27/14, 8:42 AM, Kathleen Moriarty wrote:
> The reviews got a little confused with the responses for SHA1 and
> SHA2 thumbprints.  A couple of people responded supporting Mike's 
> Is there a need to support this for the XMPP community, since they
> set to SHA256 as a default for certificate fingerprints: 
> Thanks, Kathleen
>> The primary reason for having thumbprint was for finding keys in
>> the Windows crypto API. Security property must not depend on it.
>> If it wants to deal with authentication, it should use the keys,
>> IMHO.
>> 
>> 
>>> I agree with Mike, many key stores use SHA1 thumbprints.   I
>>> don't know of any security consideration that makes SHA2
>>> thumbprints better in any practical way.
>>> 
>>> I don't think that adding SHA 2 thumbprints is something that
>>> we need to do now.
>>> 
>>> John B.
>>> 
>>>>> Mike> Per your JWS comment, SHA-1 thumbprints are widely
>>>>> deployed.  I’m aware of no SHA-256 certificate thumbprint
>>>>> deployments.  I’ll note that even if SHA-1 were completely
>>>>> broken, that wouldn’t be a security issue because it’s just
>>>>> being used to generate a digest of publicly available 
>>>>> certificate information.  It’s not being used to
>>>>> cryptographically obscure anything. (But that’s actually a
>>>>> discussion for another draft. J)
>>>>> 
>>>> 
>>>> This is in place for the XML equivalents and should be
>>>> possible for JSON.  I used this at least 2 years ago in the
>>>> XML Oxygen editor.  I believe this has been brought up before
>>>> in terms of JSON, so I am not the first.  But it is another
>>>> draft... I'd like to get through these all soon :-)
>>> 
>>> 
>>> _______________________________________________ jose mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/jose
>>> 
>> 
>> 
>> 
>> -- Nat Sakimura (=nat) Chairman, OpenID Foundation 
>> http://nat.sakimura.org/ @_nat_en
> 
> 
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 27 May 2014 11:27:37 -0400

Thanks for the quick reply.  Another argument would be for the ability
to drop SHA1 support eventually.  If you move to all SHA2, there is no
need to support the SHA1 code anymore.

On Tue, May 27, 2014 at 11:00 AM, Matt Miller <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJThKiWAAoJEDWi+S0W7cO1RT0H/115y7u4qLZbWNTC23/dZhNa
> cvH47z2l+cL5KEEKLCFlx3NNgDFYZMabZc9NfTnHYxs0oRw8HQ48B5UubDp/wOgL
> E35wM4k7+Qsdl+UuiQR86Xu6JRc/9NW8ov4dTSk80TN64AltEtvjyFCO1cN9Zs89
> 6x/LBtgxrvjhsze4R+LnwWnm/+lXswME01wK8mZTCl0tY753Ca8FtRoAeLb51f4S
> YwGolRZ8bSRv5waZhupxV/crMeWUFbEsSKQePqrnH7R0O6EzKEI8qZuYc1BsoQ1a
> EyhHkeElAmJ71qfvBRzLMM6xTA+AGGVtmQG5msm2ETyTiJ4b1ASfG5EHXU1KYVE=
> =bDGF
> -----END PGP SIGNATURE-----

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Tue, 27 May 2014 15:41:56 +0000

The problem with migrating away from SHA1-based thumbprints is that to do so, the underlying development platforms used to build JOSE implementations would also need to do so for the migration at the JOSE level to be useful.  In particular, as Nat pointed out, "x5t" was added to the JOSE specs in the first place because Windows enables key lookup in the Windows key store using the SHA-1 thumbprint.
 
While I'm sensitive to the fact that I'm using Windows as a motivating use case and I'm a Microsoft employee (so you can discount my remarks relative to this as you see fit), in practice, you can't look up a key in Windows using any thumbprint value but the SHA-1 thumbprint.  Unless that changes, I doubt that any migration away from SHA-1 thumbprints will be practical, at least when using keys in stored in the Windows key store.  I believe the same is currently also true of OpenSSL.

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Tuesday, May 27, 2014 8:28 AM
To: Matt Miller
Cc: [email-masked]
Subject: Re: [jose] JWS Review, SHA 256 thumbprints - was - AD review of draft-ietf-jose-json-web-algorithms

Thanks for the quick reply.  Another argument would be for the ability to drop SHA1 support eventually.  If you move to all SHA2, there is no need to support the SHA1 code anymore.

On Tue, May 27, 2014 at 11:00 AM, Matt Miller <[email-masked]> wrote:
> http://tools.ietf.org/html/draft-ietf-uta-xmpp-00 > [XEP-0300] Use of 
> Cryptographic Hash Functions in XMPP < 
> http://xmpp.org/extensions/xep-0300.html > [XEP-0320] Use of DTLS-SRTP 
> in Jingle Sessions < http://xmpp.org/extensions/xep-0320.html >
>
>>> The primary reason for having thumbprint was for finding keys in the 
>>> Windows crypto API. Security property must not depend on it.
>>>> I don't think that adding SHA 2 thumbprints is something that we 
>>>> need to do now.
>>>>
>>>> John B.
>>>>
>>>>>> broken, that wouldn’t be a security issue because it’s just being 
>>>>>> used to generate a digest of publicly available certificate 
>>>>>> anything. (But that’s actually a discussion for another draft. J)
>>>>>>
>>>>>
>>>>> This is in place for the XML equivalents and should be possible 
>>>>> for JSON.  I used this at least 2 years ago in the XML Oxygen 
>>>>> editor.  I believe this has been brought up before in terms of 
>>>>> JSON, so I am not the first.  But it is another draft... I'd like 
>>>>> to get through these all soon :-)
>>>>
>>>>
>>>> _______________________________________________ jose mailing list 
>>>> [email-masked] https://www.ietf.org/mailman/listinfo/jose
>>>>
>>>
>>>
>>>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 27 May 2014 13:13:03 -0400

Hi Mike,

The request was to add SHA2 support, not to get rid of SHA1 support.
You have a community of users (XMPP) that are supposed to be able to
use JOSE and have a stated preference for SHA2, I think that is
argument enough.

The other argument I just provided for supporting SHA2 is that
eventually, you will no longer need to support SHA1 algorithms once
SHA2 is widely used/deployed.

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Tue, 27 May 2014 17:25:07 +0000

OK

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Tuesday, May 27, 2014 10:13 AM
To: Mike Jones
Cc: Matt Miller; [email-masked]
Subject: Re: [jose] JWS Review, SHA 256 thumbprints - was - AD review of draft-ietf-jose-json-web-algorithms

Hi Mike,

The request was to add SHA2 support, not to get rid of SHA1 support.
You have a community of users (XMPP) that are supposed to be able to use JOSE and have a stated preference for SHA2, I think that is argument enough.

The other argument I just provided for supporting SHA2 is that eventually, you will no longer need to support SHA1 algorithms once
SHA2 is widely used/deployed.

On Tue, May 27, 2014 at 11:41 AM, Mike Jones <[email-masked]> wrote:
>> There is some desire to use SHA2 but no strong requirement.  As far 
>> as algorithm requirements go, look to [XMPP-TLS], [XEP-0300], and 
>> http://xmpp.org/extensions/xep-0300.html > [XEP-0320] Use of 
>> DTLS-SRTP in Jingle Sessions < 

-- 

Best regards,
Kathleen

---

From: John Bradley <[email-masked]>
Date: Tue, 27 May 2014 14:27:53 -0400

Matt,

Do people want a explicit way to send a SHA256 hash of a DER encoded cert in JWS/JWE?

The XMPP spec being pointed tp is talking about a print or keyprint that is a SHA256 of the XML character data of the <key/> element.  

The key element seems to be a XML encoded Modulus, Exponent and other stuff.

Is this part of the XMPP spec stable enough to have its quite custom notion of encoded public keys included in  JOSE. 

I would personally like to see the XMPP spec create the element and register it, similarly to the way we did it for JWKS thumbprint.
https://self-issued.info/docs/draft-jones-jose-jwk-thumbprint-00.html

If it were just using SHA256 vs SHA1 that might be a different case, but it seems that what is being hashed is quite different from the current thumbprint.

John B.

---

From: Matt Miller <[email-masked]>
Date: Tue, 27 May 2014 12:49:03 -0600

With regards to XEP-0189, I should have been much more explicit the
first time around.  It is Deferred, and has been so for a very long
time; it means no one is working on it, and no one cares enough about
it to put in the work to advance it to Draft.  It is essentially dead,
as dead as any specification can truly be.  Any further discussion on
the merits or deficiencies of XEP-0189 are pointless (unless you're
willing to take on its authorship).

Speaking much more generically, there is a desire to be able to use
SHA-2 wherever possible.  SHA-1 is still necessary to meet the widest
possible interoperability on the general Internet, but there are
isolated deployments where further restriction is wanted/needed.

There is some desire to make public keys available over XMPP via
[PUBSUB] and [PEP], but no one has yet put in the work to do that.  At
this point, that effort (if/when it starts up again) is extremely
likely to use something that already exists, which is possibly based
on JOSE.

As the above generalities apply to JOSE, I think that means:

* it would be nice to have a way to do everything with just SHA-2
* any fingerprinting ought to support SHA-2, but cannot prohibit SHA-1

- -- 
- - m&m

[PUBSUB] XEP-0060: Publish-Subscribe <
http://xmpp.org/extensions/xep-0060.html >
[PEP] XEP-0163: Personal Eventing Protocol <
http://xmpp.org/extensions/xep-0163.html >

On 5/27/14, 12:27 PM, John Bradley wrote:
> The XMPP spec being pointed tp is talking about a print or keyprint
> that is a SHA256 of the XML character data of the <key/> element.
> 
> 
> Is this part of the XMPP spec stable enough to have its quite
> custom notion of encoded public keys included in  JOSE.
> 
> I would personally like to see the XMPP spec create the element and
> register it, similarly to the way we did it for JWKS thumbprint. 
>  If it were just using SHA256 vs SHA1 that might be a different
> case, but it seems that what is being hashed is quite different
> from the current thumbprint.
> 
> John B.
>