Subject: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

From: "Richard Barnes" <[email-masked]>
Date: Wed, 01 Oct 2014 19:33:59 -0700

Richard Barnes has entered the following ballot position for
draft-ietf-jose-json-web-key-33: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 4.3.
"The "use" and "key_ops" JWK members SHOULD NOT be used together."
Did the WG discuss how these could combine?  What was the outcome of that
discussion?  This could be an important point for interoperability.  For
example, WebCrypto enforces them both, so it will break if it gets a key
with "use" and "key_ops" set to inconsistent values.
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#rsa-pss-operations

Section 8.
"[TBD]@ietf.org"
This needs to be populated before approval.  I don't know what's
customary here, but "[email-masked]" is an obvious candidate.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.1.
The pointer for BASE64URL should be to JWS.  One level of indirection,
please :)

Section 4.
It might be worth being explicit (here or elsewhere):
"A JWK MUST NOT contain algorithm-specific members for key type other the
one specified in its "kty" attribute."

Section 4.1.
"cryptographic algorithm family used with the key"
"... such as "RSA" or "EC"."

Section 4.7.
"base64 encoded ([RFC4648] Section 4 -- not base64url encoded) DER"
It seems unpleasant for implementations to have to support two flavors of
base64, especially since this doesn't use PEM directly.  Did the WG
discuss just using BASE64URL?

Section 9.1.
It might help here to note that technologies like PKIX and JWT can allow
relying parties to verify the provenance of a key and binding of
attributes to it.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 1 Oct 2014 20:38:44 -0700

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, October 01, 2014 7:34 PM
To: The IESG
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33:
(with DISCUSS and COMMENT)

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Section 4.3.
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#rsa-pss
-operations

[JLS] The set of values in use and key_ops do not have the same granularity.
This means that if you use both, you will be granting things in use that are
not granted in key_ops.  This was discussed by the group.

Section 8.
"[TBD]@ietf.org"
This needs to be populated before approval.  I don't know what's customary
here, but "[email-masked]" is an obvious candidate.

[JLS] If this is going to be an IANA moderated list, then it should be
filled in by IANA at the time of publishing and not now.  I believe that was
the original intent.

Section 1.1.

Section 4.

Section 4.1.

Section 4.7.
"base64 encoded ([RFC4648] Section 4 -- not base64url encoded) DER"
It seems unpleasant for implementations to have to support two flavors of
base64, especially since this doesn't use PEM directly.  Did the WG discuss
just using BASE64URL?

Section 9.1.
It might help here to note that technologies like PKIX and JWT can allow
relying parties to verify the provenance of a key and binding of attributes
to it.

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 1 Oct 2014 23:45:42 -0400

> filled in by IANA at the time of publishing and not now.  I believe that was

IANA does not moderate lists, and almost all of these sorts of lists
live on ietf.org.  You're even asking for this one to be on ietf.org
(not on iana.org).  There's no reason for IANA to care what list is
used; they will simply track whether the review was posted, and will
interact with the DE.

Barry

---

From: Richard Barnes <[email-masked]>
Date: Thu, 2 Oct 2014 00:05:47 -0400

On Wed, Oct 1, 2014 at 11:38 PM, Jim Schaad <[email-masked]> wrote:

> Cc: [email-masked];
> [email-masked];
> [email-masked]

My point is that consumers of JWK *are* going to be interpreting both of
these if present, so there are going to be interop issues if they don't
interpret both of them in the same way.

How about something like the following:
"""
If a JWK includes both a "use" member and a "key_ops" member, then the
fine-grained permissions in the "key_ops" member MUST be consistent with
the coarse-grained permissions in the "use" member:
  * enc: encrypt, decrypt, wrapKey, unwrapKey, deriveKey, deriveBits
  * sig: sign, verify

If the consumer of a JWK encounters an invalid combination of "use" and
"key_ops" (e.g., "sig" and "encrypt"), then it SHOULD reject the JWK as
invalid.
"""

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Thu, 2 Oct 2014 00:06:13 -0400

On Wed, Oct 1, 2014 at 11:45 PM, Barry Leiba <[email-masked]>
wrote:

> customary

Barry: Would [email-masked] be a sensible thing to put here?

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Oct 2014 03:03:17 -0400

On Thursday, October 2, 2014, Richard Barnes <[email-masked]> wrote:

> On Wed, Oct 1, 2014 at 11:45 PM, Barry Leiba <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> > Section 8.
>> > "[TBD]@ietf.org"
>> > here, but "[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>" is an obvious candidate.
>> >
> Barry: Would [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> be a sensible thing to put here?
>

I think it would, and we've done that with other WG lists, such as
vcarddav.  But it depends upon what's going to happen to the WG: if it's
likely to live a long time yet, and they expect significant activity for
registration reviews, they might not want those distracting the WG from
it's work.

I doubt that would be an issue for JOSE, but I can't really say for sure.

Barry

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 2 Oct 2014 10:52:00 -0700

From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, October 01, 2014 9:06 PM
To: Barry Leiba
Cc: Jim Schaad; The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

[JLS] I don’t have any objections to using [email-masked].  However the original discussions for this was it would be some type of “expert review” list similar to the mime-types list.  I don’t know that the jose list would provide the same semantics.

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Oct 2014 18:20:31 +0000

See my reply at the end prefixed by “Mike>”.

From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, October 02, 2014 10:52 AM
To: 'Richard Barnes'; 'Barry Leiba'
Cc: 'The IESG'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

From: Richard Barnes [mailto:[email-masked]]
Sent: Wednesday, October 01, 2014 9:06 PM
To: Barry Leiba
Cc: Jim Schaad; The IESG; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

On Wed, Oct 1, 2014 at 11:45 PM, Barry Leiba <[email-masked]<mailto:[email-masked]>> wrote:
> Section 8.
> "[TBD]@ietf.org<http://ietf.org>"
> here, but "[email-masked]<mailto:[email-masked]>" is an obvious candidate.
>

IANA does not moderate lists, and almost all of these sorts of lists
live on ietf.org<http://ietf.org>.  You're even asking for this one to be on ietf.org<http://ietf.org>
(not on iana.org<http://iana.org>).  There's no reason for IANA to care what list is
used; they will simply track whether the review was posted, and will
interact with the DE.

Barry: Would [email-masked]<mailto:[email-masked]> be a sensible thing to put here?

[JLS] I don’t have any objections to using [email-masked]<mailto:[email-masked]>.  However the original discussions for this was it would be some type of “expert review” list similar to the mime-types list.  I don’t know that the jose list would provide the same semantics.

Mike> The point of having a separate list in the spec from the working group list is that at some point (even if it’s years from now), the working group will be gone and registration requests will continue to come in.  That’s why the suggested list name is [email-masked] rather than [email-masked]<mailto:[email-masked]>.  This follows the precedent that OAuth registrations go to [email-masked]<mailto:[email-masked]> rather than [email-masked]<mailto:[email-masked]>.

                                                            -- Mike

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Oct 2014 14:23:29 -0400

> [JLS] I don't have any objections to using [email-masked].  However the
> original discussions for this was it would be some type of "expert review"
> list similar to the mime-types list.  I don't know that the jose list would
> provide the same semantics.

Right, that's why I said that it depends.

The media-types list is rather a special case, as it's *extremely*
active.  There are others like that, such as uri-review.

If you're not expecting many registrations very soon, and the working
group will close after the documents are done, then it makes sense to
use the jose list because by the time you start getting registrations
that list won't be active for the working group.

If you're expecting the jose list to have active discussion of
documents while registration requests are coming in, then it makes
sense to create a new list.

Use your judgment.

b

---

From: Richard Barnes <[email-masked]>
Date: Fri, 10 Oct 2014 17:39:43 -0400

> that list won't be active for the working group.

I expect that this is the more likely case.  Mike, Jim, do you agree?  To
Mike's point, just because the WG closes down doesn't mean the mailing list
does.

One other possibility: Just re-use the oauth-ext-review@ list.  It's
probably going to be pretty much the same people anyway.

--Richard

---

From: Mike Jones <[email-masked]>
Date: Sat, 11 Oct 2014 20:03:53 +0000

> Sent: Friday, October 10, 2014 2:40 PM
> To: Barry Leiba
> Cc: Jim Schaad; [email-masked]; [email-masked]; The IESG; [email-masked]
> I expect that this is the more likely case.  Mike, Jim, do you agree?  To Mike's point, just because the WG closes down doesn't mean the mailing list does.  

I know that JOSE registrations will come in from the WebCrypto and JWT specs and I expect header parameter registrations to come in reasonably often, as well as occasional algorithm registrations.

Some will happen while the working group is active.  Some will continue to happen after it's not.

> One other possibility: Just re-use the oauth-ext-review@ list.  It's probably going to be pretty much the same people anyway.

I disagree that the people will be the same, as the designated experts should likely be different.  OAuth registrations require expertise in REST-based authorization semantics.  JOSE registrations require expertise in cryptography.  I frankly expect that the designated experts for JOSE will be Jim Schaad and one or more of the editors.  None of those are among the set of OAuth designated experts.  That argues for having a separate list.

> sense to create a new list.

Yes, I think this is the case, therefore the current suggestion in the draft of using a distinct list still looks like the right one to me.

				-- Mike