Subject: [jose] #187: Define algorithm names for symmetric keys in for JWK

From: "jose issue tracker" <[email-masked]>
Date: Fri, 08 Nov 2013 21:56:37 -0000

#187: Define algorithm names for symmetric keys in for JWK

 Algorithm ("alg") names for various common symmetric key algorithms are
 not defined and would be useful with JWK objects. Specifically AES Counter
 Mode and AES CBC.

 Suggestion is to add AxxxCTR and AxxxCBC to JWA for xxx = 128, 384, 284

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-jose-json-web-
  [email-masked]    |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:
Component:  json-web-    |    Version:
  algorithms             |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/187>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Fri, 08 Nov 2013 23:18:48 -0000

Comment (by [email-masked]):

 > Suggestion is to add AxxxCTR and AxxxCBC to JWA for xxx = 128, 384, 284

 Obviously, I mean 128, 192, or 256

  algorithms             |  Resolution:
 Keywords:               |

Ticket URL: <http://tools.ietf.org/wg/jose/trac/ticket/187#comment:1>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Sat, 09 Nov 2013 00:46:14 -0000

Comment (by [email-masked]):

 A JOSE working group decision was made early on to only support
 authenticated encryption algorithms.  Neither of AES CBC or AES CTR are
 authenticated encryption algorithms.

 There are registered algorithms for the composite AES-CBC-HMAC-SHA2
 algorithms, which do provide authenticated encryption, which could be used
 when applicable.

 That being said, it would be fine for non-JOSE specifications to define
 and register the values A{128,192,256}CTR and A{128,192,256}CBC.  For
 instance, a W3C WebCrypto specification could do this.  But I believe that
 JOSE specs defining these values is out of scope.

 Therefore, I believe that this issue should be closed as "wontfix".

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/187#comment:2>
jose <http://tools.ietf.org/jose/>

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 10 Nov 2013 13:30:48 -0800

While I agree this item is appropriately addressed as Won't Fix.  I disagree
that it would be appropriate for a later specification to define  non-AEAD
algorithm for encryption purposes.  If you feel it is appropriate then I
would like to make a change to the registration template to forbid it.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> jose issue tracker
> Sent: Friday, November 08, 2013 4:46 PM
> To: [email-masked];
[email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [jose] #187: Define algorithm names for symmetric keys in for
> JWK
> 
and
> register the values A{128,192,256}CTR and A{128,192,256}CBC.  For
instance,
> a W3C WebCrypto specification could do this.  But I believe that  JOSE
specs
> defining these values is out of scope.
> 
> -------------------------+----------------------------------------------
> -------------------------+---
> -------------------------+----------------------------------------------
> -------------------------+---
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mark Watson <[email-masked]>
Date: Mon, 11 Nov 2013 09:37:28 +0800

Jim,

Do you mean that JOSE will not register non-AEAD algorithms in future or
that you would like to prohibit anyone from registering such algorithms ?

In W3C WebCrypto we support import / export of a WebCrypto Key object in
JWK format and so I believe we will need alg / use / other attributes to
reflect all the algorithms / usages and other properties that WebCrypto Key
objects can have.

...Mark

On Mon, Nov 11, 2013 at 5:30 AM, Jim Schaad <[email-masked]> wrote:

> > Ticket URL: <
> http://trac.tools.ietf.org/wg/jose/trac/ticket/187#comment:2>

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 10 Nov 2013 18:36:59 -0800

Ii mean that I would like to prohibit anyone from registering a non-AEAD
algorithm.

Good practice says that you should have an AEAD type algorithm for
encrypting a key so that it includes an integrity check as part of the
decryption process.  Any such algorithm would qualify as an AEAD algorithm.
AES-CBC and AES-CTR do not have this property and therefore should be
prohibited from being registered and used.

Jim

From: Mark Watson [mailto:[email-masked]] 
Sent: Sunday, November 10, 2013 5:37 PM
To: Jim Schaad
Cc: Michael Jones; [email-masked];
[email-masked]
Subject: Re: [jose] #187: Define algorithm names for symmetric keys in for
JWK

Jim,

In W3C WebCrypto we support import / export of a WebCrypto Key object in JWK
format and so I believe we will need alg / use / other attributes to reflect
all the algorithms / usages and other properties that WebCrypto Key objects
can have.

...Mark

Jim

[email-masked];
and
instance,
specs

---

From: Mark Watson <[email-masked]>
Date: Mon, 11 Nov 2013 10:43:30 +0800

Hi Jim,

I am not talking about using AES-CBC and AES-CTR for encrypting a key. In
the WebCrypto spec we support import/export of Key objects in JWK. Key
objects in WebCrypto have an associated algorithm. WebCrypto supports
AES-CTR and AES-CBC amongst many other things. What they are used for us up
to the developer using WebCrypto.

It would be useful to be able to signal the WebCrypto algorithm in the JWK
object when a Key is imported / exported (including when a Key is wrapped /
unwrapped), hence a desire for a JWK "alg" value for every WebCrypto
algorithm. Is there a problem with that ?

...Mark

On Mon, Nov 11, 2013 at 10:36 AM, Jim Schaad <[email-masked]> wrote:

> decryption process.  Any such algorithm would qualify as an AEAD
> algorithm.  AES-CBC and AES-CTR do not have this property and therefore
> should be prohibited from being registered and used.
>
>
>
> Jim
>
>
>
>
>
> *From:* Mark Watson [mailto:[email-masked]]
> *Sent:* Sunday, November 10, 2013 5:37 PM
> *To:* Jim Schaad
> *Cc:* Michael Jones; [email-masked];
> *Subject:* Re: [jose] #187: Define algorithm names for symmetric keys in
> for JWK
>
>
>
> Jim,
>
>
>

---

From: John Bradley <[email-masked]>
Date: Sun, 10 Nov 2013 18:45:51 -0800

I agree that JOSE should not allow non-AEAD algorithms to be registered.  I understand some people will want them.
In the words of Nancy Reagan "Just say No"  I think she also said something about your brain on non-AEAD.  Who an I to argue with Nancy:)

John B.

On Nov 10, 2013, at 6:36 PM, Jim Schaad <[email-masked]> wrote:

> Ii mean that I would like to prohibit anyone from registering a non-AEAD algorithm.
>  
> Good practice says that you should have an AEAD type algorithm for encrypting a key so that it includes an integrity check as part of the decryption process.  Any such algorithm would qualify as an AEAD algorithm.  AES-CBC and AES-CTR do not have this property and therefore should be prohibited from being registered and used.
>  
> Jim
>  
>  
> Cc: Michael Jones; [email-masked]; [email-masked]
> Subject: Re: [jose] #187: Define algorithm names for symmetric keys in for JWK
>  
> Jim,
>  
> Do you mean that JOSE will not register non-AEAD algorithms in future or that you would like to prohibit anyone from registering such algorithms ?
>  
> In W3C WebCrypto we support import / export of a WebCrypto Key object in JWK format and so I believe we will need alg / use / other attributes to reflect all the algorithms / usages and other properties that WebCrypto Key objects can have.
>  
> ...Mark
>  
>

---

From: Mark Watson <[email-masked]>
Date: Mon, 11 Nov 2013 11:09:19 +0800

John,

I want to check that we have a common context here. The W3C WebCrypto API
allows Javascript content on a web page to generate / agree / import keys
which can then be used to encrypt arbitrary data, using a variety of
algorithms (including non-AEAD ones). What data and what algorithms is up
to the page developer and WebCrypto provides *plenty* of rope with which
people can hang themselves, security-wise. There is an ambition to create a
different, higher-level, API which would not provide so much rope. What
we're working on now, though, is explicitly a low-level API with all the
caveats that go with that.

WebCrypto also allows keys to be imported and exported in JWK format.

Are you saying that JWK is not really intended for this application ? Or
that WebCrypto should not provide support for AES-CTR and AES-CBC at all
(and if it does you want no part in supporting that with JWK) ?

What about an application that wants to pass keys around in JWK format and
then use those keys to decrypt some legacy data structure encrypted with
AES-CTR ?

...Mark

On Mon, Nov 11, 2013 at 10:45 AM, John Bradley <[email-masked]> wrote:

> In the words of Nancy Reagan "Just say No"  I think she also said
> something about your brain on non-AEAD.  Who an I to argue with Nancy:)
>
> John B.
>
>
> *From:* Mark Watson [mailto:[email-masked] <[email-masked]>]

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 Nov 2013 04:47:15 +0000

I disagree with Jim and John on this.  WebCrypto is a much lower-level API than JOSE.  It intentionally enables the use of raw cryptographic primitives.  For instance, when building a JOSE implementation on WebCrypto, one would definitely use WebCrypto's support for AES CBC to build the composite authenticated algorithm A128CBC-HS256.  Likewise, one would likely use WebCrypto's AES EBC support to build A128KW.

The high-level API that WebCrypto is talking about *is* a JOSE implementation.  We should do everything we can to encourage that being specified and built.

Therefore, I believe we want to encourage WebCrypto to use JWKs for their key format.  Yes - even for algorithms that aren't inherently safe.

I understand Jim's desire not to sanction the use of non-authenticated encryption algorithms *with JWE*.  That doesn't mean that we should prohibit all JWKs that contains keys for algorithms use them.

I believe the way to do this is to expend the definition of "Algorithm Usage Location(s)" in the JSON Web Signature and Encryption Algorithms registry to permit additional usage locations.  Currently they must be "alg" or "enc".  Jim has already discussed a possible extension (key management for MAC) in which other usage locations might be used.  WebCrypto could define another usage location for their registrations.  Then we could prohibit the registration of non-authenticated encryption algorithms for "enc", but allow them for other cases.

Would that work for people?

                                                            -- Mike

From: Mark Watson [mailto:[email-masked]]
Sent: Sunday, November 10, 2013 7:09 PM
To: John Bradley
Cc: Jim Schaad; Mike Jones; [email-masked]; [email-masked]
Subject: Re: [jose] #187: Define algorithm names for symmetric keys in for JWK

John,

I want to check that we have a common context here. The W3C WebCrypto API allows Javascript content on a web page to generate / agree / import keys which can then be used to encrypt arbitrary data, using a variety of algorithms (including non-AEAD ones). What data and what algorithms is up to the page developer and WebCrypto provides *plenty* of rope with which people can hang themselves, security-wise. There is an ambition to create a different, higher-level, API which would not provide so much rope. What we're working on now, though, is explicitly a low-level API with all the caveats that go with that.

Are you saying that JWK is not really intended for this application ? Or that WebCrypto should not provide support for AES-CTR and AES-CBC at all (and if it does you want no part in supporting that with JWK) ?

What about an application that wants to pass keys around in JWK format and then use those keys to decrypt some legacy data structure encrypted with AES-CTR ?

...Mark

On Mon, Nov 11, 2013 at 10:45 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
I agree that JOSE should not allow non-AEAD algorithms to be registered.  I understand some people will want them.
In the words of Nancy Reagan "Just say No"  I think she also said something about your brain on non-AEAD.  Who an I to argue with Nancy:)

John B.

On Nov 10, 2013, at 6:36 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

Jim

From: Mark Watson [mailto:[email-masked]]
Sent: Sunday, November 10, 2013 5:37 PM
To: Jim Schaad
Cc: Michael Jones; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #187: Define algorithm names for symmetric keys in for JWK

Jim,

...Mark

On Mon, Nov 11, 2013 at 5:30 AM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

Jim

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> jose issue tracker
> To: [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> Comment (by [email-masked]<mailto:[email-masked]>):
>
and
instance,
specs
>   [email-masked]<mailto:[email-masked]>    |  [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: Mark Watson <[email-masked]>
Date: Mon, 11 Nov 2013 13:03:22 +0800

Another possibility is to specify in the registry of alg / enc values which
values are permitted with JWE / JWS and which are only valid for JWKs
outside those contexts.

...Mark

Sent from my iPhone

On Nov 11, 2013, at 12:49 PM, Mike Jones <[email-masked]>
wrote:

  I disagree with Jim and John on this.  WebCrypto is a much lower-level
API than JOSE.  It intentionally enables the use of raw cryptographic
primitives.  For instance, when building a JOSE implementation on
WebCrypto, one would definitely use WebCrypto’s support for AES CBC to
build the composite authenticated algorithm A128CBC-HS256.  Likewise, one
would likely use WebCrypto’s AES EBC support to build A128KW.

The high-level API that WebCrypto is talking about **is** a JOSE
implementation.  We should do everything we can to encourage that being
specified and built.

Therefore, I believe we want to encourage WebCrypto to use JWKs for their
key format.  Yes – even for algorithms that aren’t inherently safe.

I understand Jim’s desire not to sanction the use of non-authenticated
encryption algorithms **with JWE**.  That doesn’t mean that we should
prohibit all JWKs that contains keys for algorithms use them.

I believe the way to do this is to expend the definition of “Algorithm
Usage Location(s)” in the JSON Web Signature and Encryption Algorithms registry
to permit additional usage locations.  Currently they must be “alg” or
“enc”.  Jim has already discussed a possible extension (key management for
MAC) in which other usage locations might be used.  WebCrypto could define
another usage location for their registrations.  Then we could prohibit the
registration of non-authenticated encryption algorithms for “enc”, but
allow them for other cases.

                                                            -- Mike

*From:* Mark Watson [mailto:[email-masked] <[email-masked]>]
*Sent:* Sunday, November 10, 2013 7:09 PM
*To:* John Bradley
*Cc:* Jim Schaad; Mike Jones;
[email-masked]; [email-masked]
*Subject:* Re: [jose] #187: Define algorithm names for symmetric keys in
for JWK

John,

...Mark

I agree that JOSE should not allow non-AEAD algorithms to be registered.  I
understand some people will want them.

In the words of Nancy Reagan "Just say No"  I think she also said something
about your brain on non-AEAD.  Who an I to argue with Nancy:)

John B.

Jim

Jim,

...Mark

Jim

[email-masked];
and
instance,
specs

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 10 Nov 2013 21:38:45 -0800

Mark,

Just to be clear, this is possible if you do not want to have key tainting
with algorithms today.  It can just be a symmetric key without an algorithm
defined.  It is only if you do want to have this done that there is a
problem.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
Watson
Sent: Sunday, November 10, 2013 7:09 PM
To: John Bradley
Cc: Jim Schaad; [email-masked]; Michael Jones;
[email-masked]
Subject: Re: [jose] #187: Define algorithm names for symmetric keys in for
JWK

John,

I want to check that we have a common context here. The W3C WebCrypto API
allows Javascript content on a web page to generate / agree / import keys
which can then be used to encrypt arbitrary data, using a variety of
algorithms (including non-AEAD ones). What data and what algorithms is up to
the page developer and WebCrypto provides *plenty* of rope with which people
can hang themselves, security-wise. There is an ambition to create a
different, higher-level, API which would not provide so much rope. What
we're working on now, though, is explicitly a low-level API with all the
caveats that go with that.

...Mark

John B.

Jim

From: Mark Watson [ <mailto:[email-masked]> mailto:[email-masked]]

Sent: Sunday, November 10, 2013 5:37 PM
To: Jim Schaad
Cc: Michael Jones;  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]>
[email-masked]
Subject: Re: [jose] #187: Define algorithm names for symmetric keys in for
JWK

Jim,

...Mark

On Mon, Nov 11, 2013 at 5:30 AM, Jim Schaad <
<mailto:[email-masked]> [email-masked]> wrote:

Jim

> From:  <mailto:[email-masked]> [email-masked] [mailto:
<mailto:[email-masked]> [email-masked]] On Behalf Of
> To:  <mailto:[email-masked]>
[email-masked];
 <mailto:[email-masked]> [email-masked];
>  <mailto:[email-masked]> [email-masked]
> Cc:  <mailto:[email-masked]> [email-masked]
> Comment (by  <mailto:[email-masked]>
and
instance,
specs

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

> Ticket URL: <
<http://trac.tools.ietf.org/wg/jose/trac/ticket/187#comment:2>
http://trac.tools.ietf.org/wg/jose/trac/ticket/187#comment:2>
> jose < <http://tools.ietf.org/jose/> http://tools.ietf.org/jose/>
>

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

_______________________________________________
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: Sun, 10 Nov 2013 22:43:28 -0800

Web Crypto should certainly implement the lower level functions like AES-CBC.

If we are talking about carrying keys in JWK and and wanting to mark the key usage as AES-128-CBC that gets dangerous as people will assume that is a valid JWE alg.

Can someone explain why you would need to create a JWK with a AES-CBC key usage if AES-CBC is a primitive operation and not intended for JWE?

If there is a reason to have the key use of those algorithms specified in a JWK it needs to be clear that they are not valid JWE algorithms.

John B.

On Nov 10, 2013, at 8:47 PM, Mike Jones <[email-masked]> wrote:

> I disagree with Jim and John on this.  WebCrypto is a much lower-level API than JOSE.  It intentionally enables the use of raw cryptographic primitives.  For instance, when building a JOSE implementation on WebCrypto, one would definitely use WebCrypto’s support for AES CBC to build the composite authenticated algorithmA128CBC-HS256.  Likewise, one would likely use WebCrypto’s AES EBC support to build A128KW.
>  
> Therefore, I believe we want to encourage WebCrypto to use JWKs for their key format.  Yes – even for algorithms that aren’t inherently safe.
>  
> I understand Jim’s desire not to sanction the use of non-authenticated encryption algorithms *with JWE*.  That doesn’t mean that we should prohibit all JWKs that contains keys for algorithms use them.
>  
> I believe the way to do this is to expend the definition of “Algorithm Usage Location(s)” in the JSON Web Signature and Encryption Algorithms registry to permit additional usage locations.  Currently they must be “alg” or “enc”.  Jim has already discussed a possible extension (key management for MAC) in which other usage locations might be used.  WebCrypto could define another usage location for their registrations.  Then we could prohibit the registration of non-authenticated encryption algorithms for “enc”, but allow them for other cases.
>

---

From: Mark Watson <[email-masked]>
Date: Mon, 11 Nov 2013 15:13:39 +0800

On Mon, Nov 11, 2013 at 2:43 PM, John Bradley <[email-masked]> wrote:

> If we are talking about carrying keys in JWK and and wanting to mark the
> key usage as AES-128-CBC that gets dangerous as people will assume that is
> a valid JWE alg.
>

So, there could presumably be some way, within the registry, that we can
indicate the algorithms that are "valid JWE algorithms" and those that have
been added for other reasons.

>
> Can someone explain why you would need to create a JWK with a AES-CBC key
> usage if AES-CBC is a primitive operation and not intended for JWE?
>

A Javascript application creates a WebCrypto Key object and indicates that
it may only be used with AES-CBC. The Javascript application uses that key
for encrypting some data - just raw encryption, not JWE.

At some point, for whatever application-specific reason, the application
wishes to export the Key, possibly wrapped with another Key, and send it
somewhere else. We would like the usages (AES-CBC) to be preserved and
having those indicated inside the JWK would achieve that.

Equally, you could imagine a Key being delivered in JWK format and we want
to avoid that the usages are tampered with. In the case that the key is
delivered wrapped, then there may be policy in the UA that polices the Key
usages and again ensures that the usages remain exactly what they are
supposed to be.

>
> If there is a reason to have the key use of those algorithms specified in
> a JWK it needs to be clear that they are not valid JWE algorithms.
>

Seems like that would be quite easy to make clear.

...Mark

> I disagree with Jim and John on this.  WebCrypto is a much lower-level API
> than JOSE.  It intentionally enables the use of raw cryptographic
> build the composite authenticated algorithmA128CBC-HS256.  Likewise, one

---

From: Richard Barnes <[email-masked]>
Date: Mon, 11 Nov 2013 00:51:05 -0800

I'm pretty much on the same page as Mike here.  In my fantasy world in
which JOSE does not engage in protocol pontification with regard to
ciphers, JWE would allow legacy, unauthenticated algorithms as well.  But
at the very least, we should allow JWK to represent keys for legacy
algorithms, even if they can't be used with JWE.

--Richard

---

From: John Bradley <[email-masked]>
Date: Mon, 11 Nov 2013 06:27:00 -0800

Sending the key somewhere else with a key usage that is not considered safe for at-least inter machine communication, seems like something that is likely to cause problems over time.

It is not the key use itself that worries me, but the resulting message that uses it.  

There needs to be sufficient warnings around algorithms like DES and AES-CBC, that while they are useful cryptographic primitives and may be used for backwards computability in  Web Cryipto, they are excluded from JWE intentionally and should not be used in new systems.

John B.

On Nov 10, 2013, at 11:13 PM, Mark Watson <[email-masked]> wrote:

> So, there could presumably be some way, within the registry, that we can indicate the algorithms that are "valid JWE algorithms" and those that have been added for other reasons.
>  
> 
> A Javascript application creates a WebCrypto Key object and indicates that it may only be used with AES-CBC. The Javascript application uses that key for encrypting some data - just raw encryption, not JWE.
> 
> At some point, for whatever application-specific reason, the application wishes to export the Key, possibly wrapped with another Key, and send it somewhere else. We would like the usages (AES-CBC) to be preserved and having those indicated inside the JWK would achieve that.
> 
> Equally, you could imagine a Key being delivered in JWK format and we want to avoid that the usages are tampered with. In the case that the key is delivered wrapped, then there may be policy in the UA that polices the Key usages and again ensures that the usages remain exactly what they are supposed to be.
>  
>

---

From: "jose issue tracker" <[email-masked]>
Date: Tue, 12 Nov 2013 03:21:47 -0000

Comment (by [email-masked]):

 There are currently no plans to add these algorithms to the registry by
 the JOSE working group.  However the registration template is being
 updated to allow for the registration of alg values that cannot be used in
 JOSE documents, but which would allow the key to be carried by a JWK
 object.

 The actual registration of these would need to be done by an external
 document.

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/187#comment:3>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Wed, 13 Nov 2013 01:00:31 -0000

#187: Allow registration of non-JWE/JWS algorithms for JWK

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/187#comment:4>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Wed, 13 Nov 2013 01:03:54 -0000

The -18 draft allows registration of non-JOSE algorithms for use with JWK.
 These registrations would contain these registration parameters:

 Algorithm Usage Location(s): JWK

 Implementation Requirements: Prohibited

 Therefore, I believe that this issue should be closed as "fixed".

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/187#comment:5>
jose <http://tools.ietf.org/jose/>