Subject: [jose] Comments on draft-ietf-jose-json-web-key-01

From: "Jim Schaad" <[email-masked]>
Date: Wed, 11 Apr 2012 13:06:52 -0700

<no hat>

I am starting to come out of the normal sickness period following an IETF
meeting. So I am looking at the smallest document first.

I am going to skip section 4.2.1 & 4.2.2 as they appear to be heading for a
different document.

Abstract:

1.  Are JWK items restricted to just asymmetric algorithms?  Can/Should one
be able to transport symmetric keys via  web key structure?

2.  There was a request at one point to allow for encoding of private keys.
What if any response does the working group have to this request?

Introduction:

3.  The introduction text appears to be incorrect.  While the jku field
refers to a JWK Web Key, the epk field holds a JWK Key Object.

4.  I find the terminology to be very difficult to understand.  A JSON Web
Key (JWK)  is a set of one or more keys while a JWK Key Object is a single
key.  The fact that these are all dealing with the same string JWK is part
of the confusion as is the fact that the JWK is singular in name, but plural
in content.

5.  I would like to see the "non-goals" of this document to be pulled out
into a new paragraph and expanded into a number of different non-goals of
this document.  This includes certified keys - that is any form of binding
of keys to names that has been attested to.  

Terminology:

6.  I am not sure that the definition of the JWK Container Object is useful.
Is this really a separate object from the JSON Web Key object?

Overview:

7.  This section starts "It is sometimes useful.."  There are a lot of
things that are sometimes useful but we don't standardize a lot of them.  I
think that this text would be better started as:  "A large number of
operations, such as digital signature validation, require the public key in
order to be successful.  In many cases the public key is provided in an
X.509 certificate, however there are cases where it is more convenient to
provide the public key in a different format.  Examples of this include
.....  This document defines ..."  Actually I think that this text might be
even better placed in the introduction. And section 3.1 be promoted to
become section 3. And the current section 3 be omitted.

JWK Format:

8.  Does a JWK consist of a JWK Container object - or is it identical to a
JWK Container object?

JWK Container Object Format:

9.  Why is the member name jwk - it would seem that this should be the name
of the member that holds the entire object not that of the array of key
objects.  I would think that "keys" would be a better name for this member.

10.  The last sentence in this section again conflates a container object
and a JWK.

11.  Should the text that is in the signature and encryption dealing with
adding fields (urls vs simple names) be included in this section as well?

12.  Should there be an IANA registry for the member names of a container
object.

JWK Key Object Format:

13.  Should there be an IANA registry for the contents of the alg string?

14.  Should there be an IANA registry for the members of a Key Object?

15.  What is the function of the value of use?  Is there supposed to be a
requirement on items that use a key that the "use" value be of specific
values?    Do these values need to be registered?

16.  I don't understand the sentence "The "kid" value MAY correspond to a
JWS "kid" value." - First this seems to make no sense to have a protocol
requirement statement on it.  Secondly if the value does not correspond to a
JWS kid value, what in the world would it possibly correspond to, how could
would it be used for choosing among keys if it did not have such a
correspondence?

17.  Should the "kid" be present if there are multiple keys of the same
usage and algorithm?

18.  Should the text dealing with adding members be present (copied from
JWS)?  Is it just the key and not the entire key set that is to be ignored?

Open Issues:

19.  I think that a section on adding key families would be reasonable.

Security Considerations:

20.  The key is no more trustworthy that the method that is came to you.

21.  This structure is not intended to replace X.509 certificates.

Jim

---

From: Mike Jones <[email-masked]>
Date: Thu, 26 Apr 2012 04:21:57 +0000

Thanks for the detailed comments, as always, Jim.  Replies inline...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, April 11, 2012 1:07 PM
To: Mike Jones
Cc: [email-masked]
Subject: [jose] Comments on draft-ietf-jose-json-web-key-01

<no hat>

I am starting to come out of the normal sickness period following an IETF meeting.

I got sick after Paris too.  Hope you're feeling better now!

So I am looking at the smallest document first.

This is a good one to start with, as it has probably been reviewed less than the others.  (Maybe read JWA next, by the same logic.)

I am going to skip section 4.2.1 & 4.2.2 as they appear to be heading for a different document.

Agreed

Abstract:

1.  Are JWK items restricted to just asymmetric algorithms?  Can/Should one be able to transport symmetric keys via  web key structure?

Yes.  During our scoping discussions for the work, I believe there was consensus to restrict the JSON key representation spec to representing public keys only.  This is reflected in our charter as:
3) A Standards Track document specifying how to encode public keys as JSON-structured objects.

I believe this would require rechartering.

Introduction:

3.  The introduction text appears to be incorrect.  While the jku field refers to a JWK Web Key, the epk field holds a JWK Key Object.

You're right - I will tighten this description.

4.  I find the terminology to be very difficult to understand.  A JSON Web Key (JWK)  is a set of one or more keys while a JWK Key Object is a single key.  The fact that these are all dealing with the same string JWK is part of the confusion as is the fact that the JWK is singular in name, but plural in content.

Yes, a JWK represents a set of keys and a JWK Key Object represents a single key.  I'll think about how to make the terminology more intuitive.

5.  I would like to see the "non-goals" of this document to be pulled out into a new paragraph and expanded into a number of different non-goals of this document.  This includes certified keys - that is any form of binding of keys to names that has been attested to.

Good idea.  The set of non-goals should probably include representing private keys, representing symmetric keys, representing certified keys, and replacing X.509 certificates.

Terminology:

Given there's a 1:1 mapping, it's probably not.  I'll work on simplifying/coalescing.

Overview:

7.  This section starts "It is sometimes useful.."  There are a lot of things that are sometimes useful but we don't standardize a lot of them.  I think that this text would be better started as:  "A large number of operations, such as digital signature validation, require the public key in order to be successful.  In many cases the public key is provided in an

X.509 certificate, however there are cases where it is more convenient to provide the public key in a different format.  Examples of this include .....  This document defines ..."  Actually I think that this text might be even better placed in the introduction. And section 3.1 be promoted to become section 3. And the current section 3 be omitted.

Agreed.  I'd independently reached the same conclusion.

JWK Format:

8.  Does a JWK consist of a JWK Container object - or is it identical to a JWK Container object?

(See 6)

9.  Why is the member name jwk - it would seem that this should be the name of the member that holds the entire object not that of the array of key objects.  I would think that "keys" would be a better name for this member.

I agree.  WORKING GROUP:  How do you feel about this possible name change?

10.  The last sentence in this section again conflates a container object and a JWK.

(See 6)

11.  Should the text that is in the signature and encryption dealing with adding fields (urls vs simple names) be included in this section as well?

Are you thinking of the text about the three classes of names:  reserved, private, and public?  With the possibility of a registry?  What do people in the working group think?  I think the chances of this object being extended are small, especially since we only define one member.  But then, it's incredibly hard to predict how a standard will be used, if successful.  I'd be more prone to think that extension made sense if the spec defined more than one member.

12.  Should there be an IANA registry for the member names of a container object.

Per 11, I don't think so.  I think this case is better handled by the standard JSON "you can add fields if you understand them" logic.

JWK Key Object Format:

In the JWA spec, yes.

In the JWA spec, yes.

15.  What is the function of the value of use?  Is there supposed to be a requirement on items that use a key that the "use" value be of specific

Part of the function of this field is to match keys with the correct usages.  For instance, I believe that it's a potential security problem to use the same Elliptic Curve key for both signing and encryption.  One might have two keys, one with use "sig" and one with use "enc" to specify which key (or keys) are to be used for which purposes.

Unless the experts in this group want to bring to our attention public key usages other than signing and encryption that may also need to be defined in the future, I think what we have is sufficient.  If this is a more open-ended set (looking at the X.509 key usage description may tell us), we may want to consider a more robust treatment.

16.  I don't understand the sentence "The "kid" value MAY correspond to a JWS "kid" value." - First this seems to make no sense to have a protocol requirement statement on it.  Secondly if the value does not correspond to a JWS kid value, what in the world would it possibly correspond to, how could would it be used for choosing among keys if it did not have such a correspondence?

I can tighten this to say that when used with JWS and JWE, the JWS and JWE "kid" are intended to be used to match JWK "kid" values for key selection.  (When used in contexts other than with JWS and JWE, the "kid" values could be matched against something else entirely.)

17.  Should the "kid" be present if there are multiple keys of the same usage and algorithm?

I think this would be up to the particular usage profiles.  We could maybe so far as to make this RECOMMENDED for some use cases but I wouldn't go for REQUIRED.  For instance, in some cases, including key roll-over, it may be perfectly fine to just try all the keys without having identifiers for any of them.

18.  Should the text dealing with adding members be present (copied from JWS)?  Is it just the key and not the entire key set that is to be ignored?

Again, are you thinking the reserved/private/public treatment?  With a registry?  Or maybe just a registry?  I didn't find "ignore" in the draft, so I'm not sure what the second sentence in your remarks is referring to.

Open Issues:

Yes, probably in JWA.

Security Considerations:

Will add.

I'm thinking this belongs in the non-goals section.

Jim

                                                            Thanks again,
                                                            -- Mike

---

From: Mike Scott <[email-masked]>
Date: Thu, 26 Apr 2012 08:14:20 +0000

Hello List,

Mike Jones said

"Part of the function of this field is to match keys with the correct usages.  For instance, I believe that it’s a potential security problem to use the same Elliptic Curve key for both signing and encryption..."

Anyone got a reference for that? I did note some chatter on the Internet pointing out that different algorithms are needed for encryption and signature (ECIES and ECDSA), but not different keys. Assuming of course the same curve is being used for both. I did a quick check in Hankerson et al. "Guide to Elliptic Curve Cryptography", and there is no mention of it there..

If true, it needs to be propagated...

If false, it needs to be quashed..

Mike Scott
Certivox

---

From: John Bradley <[email-masked]>
Date: Thu, 26 Apr 2012 11:27:11 -0300

http://www.math.uwaterloo.ca/~ajmeneze/publications/static.pdf

I need to dig up other references.  Using the same keys in different protocols is generally a bad idea.
Principle 2 of Anderson and Needham’s robustness principles for public key protocols [3] advises:

If possible avoid using the same key for two different purposes (such as signing and decryption)...

Section 13.5.1 of the Handbook of Applied Cryptography [17] states:

The principle of key separation is that keys for different purposes should be crypto- graphically separated. 

For RSA you are always encrypting even for a signature, so key reuse is less of an issue.

From http://www.rfc-editor.org/rfc/rfc5008.txt

As specified in RFC 3279 [PKIX1ALG], ECDSA and Elliptic Curve
   Diffie-Hellman (ECDH) use the same algorithm identifier for subject
   public keys in certificates, and it is repeated here:

      id-ecPublicKey  OBJECT IDENTIFIER  ::=  { iso(1) member-body(2)
          us(840) ansi-x9-62(10045) keyType(2) 1 }

   This object identifier is used in public key certificates for both
   ECDSA signature keys and ECDH encryption keys.  The intended
   application for the key may be indicated in the key usage field (see
   RFC 3280 [PKIX1]).  The use of separate keys for signature and
   encryption purposes is RECOMMENDED; however, the use of a single key
   for both signature and encryption purposes is not forbidden.

While I don't know of a specific related key attack between ECDH-ES and ECDSA it is RECOMENDED not to use the same static key for both.

Will the world immediately end, probably not.

John B.

On 2012-04-26, at 5:14 AM, Mike Scott wrote:

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

---

From: John Bradley <[email-masked]>
Date: Sat, 28 Apr 2012 17:22:52 -0300

On Point 9:

I agree "keys" probably makes more sense than "JWK".  

John B.  
On 2012-04-26, at 1:21 AM, Mike Jones wrote:

> Thanks for the detailed comments, as always, Jim.  Replies inline…
>  
> I got sick after Paris too.  Hope you’re feeling better now!
>  
> You’re right - I will tighten this description.
>  
> Yes, a JWK represents a set of keys and a JWK Key Object represents a single key.  I’ll think about how to make the terminology more intuitive.
>  
> Given there’s a 1:1 mapping, it’s probably not.  I’ll work on simplifying/coalescing.
>  
> Overview:
>  
> Agreed.  I’d independently reached the same conclusion.
>  
> JWK Format:
>  
> Are you thinking of the text about the three classes of names:  reserved, private, and public?  With the possibility of a registry?  What do people in the working group think?  I think the chances of this object being extended are small, especially since we only define one member.  But then, it’s incredibly hard to predict how a standard will be used, if successful.  I’d be more prone to think that extension made sense if the spec defined more than one member.
>  
> Per 11, I don’t think so.  I think this case is better handled by the standard JSON “you can add fields if you understand them” logic.
>  
> JWK Key Object Format:
>  
> Part of the function of this field is to match keys with the correct usages.  For instance, I believe that it’s a potential security problem to use the same Elliptic Curve key for both signing and encryption.  One might have two keys, one with use “sig” and one with use “enc” to specify which key (or keys) are to be used for which purposes.
>  
> I can tighten this to say that when used with JWS and JWE, the JWS and JWE “kid” are intended to be used to match JWK “kid” values for key selection.  (When used in contexts other than with JWS and JWE, the “kid” values could be matched against something else entirely.)
>  
> I think this would be up to the particular usage profiles.  We could maybe so far as to make this RECOMMENDED for some use cases but I wouldn’t go for REQUIRED.  For instance, in some cases, including key roll-over, it may be perfectly fine to just try all the keys without having identifiers for any of them.
>  
> Again, are you thinking the reserved/private/public treatment?  With a registry?  Or maybe just a registry?  I didn’t find “ignore” in the draft, so I’m not sure what the second sentence in your remarks is referring to.
>  
> Open Issues:
>  
> I’m thinking this belongs in the non-goals section.
>  
> Jim
>  
>                                                             Thanks again,
>                                                             -- Mike
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 1 May 2012 04:43:48 +0900

> I agree.  WORKING GROUP:  How do you feel about this possible name change?

I support the change. This will make it much more descriptive.

Nat