(In reply to Mark Watson from comment #0)
> The JOSE working group has decided that it will not specify attributes /
> algorithms that are not needed for the JOSE Encryption and Signature
> standards (JWE and JWS). However, they do intend that JOSE structure may
> have other applications and are thus establishing IANA registries to allow
> others to extend JWK, JWE and JWS.
> 
> So, responsibility for defining the JWK attributes needed to represent a
> WebCrypto Key object falls to the WebCrypto group, not JOSE.
> 
> Here is a proposal for additional WebCrypto sections to this end:
> 
> y. Representation of WebCrypto Key objects using JSON Web Key
> 
> The KeyFormat value "jwk" enables Key objects to be imported or exported in
> JSON Web Key [reference].
> 
> This specification defines additional JWK attributes and attribute values
> that may be used for this purpose as follows:
> 
>    o  Additional "alg" names for algorithms supported by WebCrypto by not
> used by JSON Web Encryption or JSON Web Algorithms
>    o  A new "uses" attribute enabling multiple specific useages to be
> associated with a key
>    o  A new "ext" attribute providing the value of the WebCrypto Key's
> extractable attribute.
> 
> y.1 JWK algorithm names for WebCrypto algorithms
> 
> This specification defines additional JWK algorithm names associated with
> WebCrypto algorithms as listed in the following table:
> 
> WebCrypto Algorithm | Key Size | JWK "alg" value
> AES-CTR | 128 | A128CTR
> AES-CTR | 192 | A192CTR
> AES-CTR | 256 | A256CTR
> AES-CBC | 128 | A128CBC
> AES-CBC | 192 | A192CBC
> AES-CBC | 256 | A256CBC
> 
> y.2 JWK "uses" attribute
> 
> This specification defines a new JWK attribute "uses" that enables multiple
> key usages to be included in the JWK. Since WebCrypto usages distinguish
> encryption from decryption etc., wheras JOSE "use" values do not, new values
> are defined for the individual usages.
> 
> The "uses" attribute shall have a value which is an array of strings. Each
> entry shall specify a single usage, as follows:
> 
> WebCrypto KeyUsage value | Value in JWK uses array
> encrypt | enc
> decrypt | dec
> sign | sig
> verify | vfy
> deriveKey | derivekey
> deriveBits | derivebits
> wrapKey | wrap
> unwrapKey | unwrap
> 
> The JWK "use" value "enc" shall be equivalent to the "uses" value [ "enc",
> "dec" ].
> 
> The JWK "use" value "sig" shall be equivalent to the "uses" value [ "sig",
> "vfy" ].
> 
> If both a "use" and "uses" value are specified and are different, then the
> "uses" value shall take precedance.
> 
> y.3 JWK "ext" attribute
> 
> This specification defines a new JWK attribute "ext" that enables the value
> of the extractable attribute of a WebCrypto Key to be included in a JWK
> object. The "ext" attribute SHALL have a Boolean value.
> 
> x.  IANA Considerations
> 
> x.1 JSON Web Signature and Encryption Algorithms Registration
> 
> This section registers the following algorithm identifiers in the IANA JSON
> Web Signature and Encryption Algorithms Registry.
> 
>    o  Algorithm Name: "A128CBC"
>    o  Algorithm Description: AES CBC using 128 bit key
>    o  Algorithm Usage Location(s): "alg"
>    o  Implementation Requirements: Optional
>    o  Change Controller: W3C WebCrypto working group
>    o  Specification Document(s): [[ this document ]]
> 
>    o  Algorithm Name: "A192CBC"
>    o  Algorithm Description: AES CBC using 192 bit key
>    o  Algorithm Usage Location(s): "alg"
>    o  Implementation Requirements: Optional
>    o  Change Controller: W3C WebCrypto working group
>    o  Specification Document(s): [[ this document ]]
> 
>    o  Algorithm Name: "A256CBC"
>    o  Algorithm Description: AES CBC using 256 bit key
>    o  Algorithm Usage Location(s): "alg"
>    o  Implementation Requirements: Optional
>    o  Change Controller: W3C WebCrypto working group
>    o  Specification Document(s): [[ this document ]]
> 
>    o  Algorithm Name: "A128CTR"
>    o  Algorithm Description: AES CTR using 128 bit key
>    o  Algorithm Usage Location(s): "alg"
>    o  Implementation Requirements: Optional
>    o  Change Controller: W3C WebCrypto working group
>    o  Specification Document(s): [[ this document ]]
> 
>    o  Algorithm Name: "A192CTR"
>    o  Algorithm Description: AES CTR using 192 bit key
>    o  Algorithm Usage Location(s): "alg"
>    o  Implementation Requirements: Optional
>    o  Change Controller: W3C WebCrypto working group
>    o  Specification Document(s): [[ this document ]]
> 
>    o  Algorithm Name: "A256CTR"
>    o  Algorithm Description: AES CTR using 256 bit key
>    o  Algorithm Usage Location(s): "alg"
>    o  Implementation Requirements: Optional
>    o  Change Controller: W3C WebCrypto working group
>    o  Specification Document(s): [[ this document ]]
> 

This really concerns me, because it seems to significantly dilute the objectives of JOSE (namely, providing semantically secure primitives)

Can you please provide justification for why we need to weaken JOSE security for these? Can you provide context to the discussions within the JOSE WG about the review of this?

> x.2 JSON Web Key Parameters Registry
> 
>    o  Parameter Name: "ext"
>    o  Used with "kty" Value(s): *
>    o  Parameter Information Class: Public
>    o  Change Controller: W3C WebCrypto working group
>    o  Specification Document(s): Section y.2 of [[ this document ]]
> 
>    o  Parameter Name: "uses"
>    o  Used with "kty" Value(s): *
>    o  Parameter Information Class: Public
>    o  Change Controller: W3C WebCrypto working group
>    o  Specification Document(s): Section y.1 of [[ this document ]]

The intention is not to dilute the security of JWE and JWS but to enable the use of JWK to represent a WebCrypto Key, which is something we need in WebCrypto (the KeyFormat for JWK has existing for ages and we have use-cases which make use of this).

The discussion in JOSE concluded that we should be clear these new algorithms are not for use with JWE / JWS. I expect the JOSE group will need to arrange their registries or add information to the registrations which make it clear what uses of these algorithms are allowed for JOSE purposes and which are not.

See: http://www.ietf.org/mail-archive/web/jose/current/msg03667.html

The proposal makes good sense to me from implementation standpoint.

One thing I find potentially dangerous and confusing is the "uses" attribute. Every implementation of JWK will need to know how process it and how to resolve conflicts to preserve secure semantics.

Is there a specific scenario that makes existing "use" values insufficient? My understanding is that "enc" currently allows encrypt/decrypt/wrap/unwrap, and "sig" allows sign/verify. Is there a cryptographic reason to allow using a key for signing, but not for verification, for example?

> y.1 JWK algorithm names for WebCrypto algorithms

I'm surprised that JOSE group is unwilling to specify these names, given that JWK is their deliverable. "A128CBC" may not make sense for JWS or JWE, but it totally makes sense for JWK, whether the keys are used with WebCrypto or not.

(In reply to Alexey Proskuryakov from comment #3)
> The proposal makes good sense to me from implementation standpoint.
> 
> One thing I find potentially dangerous and confusing is the "uses"
> attribute. Every implementation of JWK will need to know how process it and
> how to resolve conflicts to preserve secure semantics.
> 
> Is there a specific scenario that makes existing "use" values insufficient?
> My understanding is that "enc" currently allows encrypt/decrypt/wrap/unwrap,
> and "sig" allows sign/verify. Is there a cryptographic reason to allow using
> a key for signing, but not for verification, for example?

First, there are very good security reasons ("principle of least privilege") to specify more precisely what a key may be used for.

Second, WebCrypto allows multiple uses to be specified for a key (notwithstanding the above). If we want to mapping WebCrypto Key <-> JWK to be bijective / invertible then we need to be able to precisely represent the attributes of a WebCrypto Key in JWK.

It would of course be better if the use attribute in JWK were modified to be more specific.

> 
> > y.1 JWK algorithm names for WebCrypto algorithms
> 
> I'm surprised that JOSE group is unwilling to specify these names, given
> that JWK is their deliverable. "A128CBC" may not make sense for JWS or JWE,
> but it totally makes sense for JWK, whether the keys are used with WebCrypto
> or not.

I believe JOSE wish to define names only for algorithms that may be used in JWE and JWS. But they wish to encourage use of JWK by others and this is why there is a registry.

Based on the registration template in the latest JWA specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-18#section-7.1.1) the Implementation Requirements value for these registrations should be "Prohibited".

> First, there are very good security reasons ("principle of least privilege")
> to specify more precisely what a key may be used for.

I certainly agree with this principle in general. However I think that most applications of the principle are outside the scope of key format. There is a known cryptographic attack scenario that warrants a key being tied to its algorithm, but is there one that make WebCrypto level of usage granularity useful?

There is no end to possible restrictions on key use (can only be used during office hours... can only be used on a specific machine... can only be used once... can only be used to encrypt content that was approved by a parental filter...)

> Second, WebCrypto allows multiple uses to be specified for a key
> (notwithstanding the above). If we want to mapping WebCrypto Key <-> JWK to
> be bijective / invertible then we need to be able to precisely represent the
> attributes of a WebCrypto Key in JWK.

Yes, I don't see why we should go to such extreme lengths as duplicating an existing attribute to achieve this.

At this point, we'd be better off defining a custom format that is not governed by JOSE specs (not something I advocate for).

(In reply to Alexey Proskuryakov from comment #6)
> > First, there are very good security reasons ("principle of least privilege")
> > to specify more precisely what a key may be used for.
> 
> I certainly agree with this principle in general. However I think that most
> applications of the principle are outside the scope of key format. There is
> a known cryptographic attack scenario that warrants a key being tied to its
> algorithm, but is there one that make WebCrypto level of usage granularity
> useful?

I'm not sure I understand why you say the 'known cryptographic attack scenario that warrants a key being tied to its algorithm' doesn't apply to WebCrypto usage granularity ? 

In our use-case, we use wrapped JWK to deliver session keys from a server to a client. These could include a key used to verify messages sent from the server and key used to sign messages sent to the server.

If these keys do not have specific usages, then once installed, the verification key could be used to forge messages that appear to come from the server.

Another example would be the case where one delivers a wrapped key with the usage 'unwrap'. If this key can also be used for decryption, then it could be used to decrypt a future wrapped key, exposing that key when the intention was that it could only be used to unwrap a key.

> 
> There is no end to possible restrictions on key use (can only be used during
> office hours... can only be used on a specific machine... can only be used
> once... can only be used to encrypt content that was approved by a parental
> filter...)
> 
> > Second, WebCrypto allows multiple uses to be specified for a key
> > (notwithstanding the above). If we want to mapping WebCrypto Key <-> JWK to
> > be bijective / invertible then we need to be able to precisely represent the
> > attributes of a WebCrypto Key in JWK.
> 
> Yes, I don't see why we should go to such extreme lengths as duplicating an
> existing attribute to achieve this.
> 
> At this point, we'd be better off defining a custom format that is not
> governed by JOSE specs (not something I advocate for).

What is your suggestion ? You're second sentence seems self-contradictory.

It's probably best to discuss use cases separately, as linear flow of a bug is not well suited to discussing multiple issues at once. I'm not sure if usage is the best solution in either case that you provided, but I'm not an expert in cryptography.

But talking about key format specifically, I object to having a format that is almost like JWK, but has an additional key with a similar name, almost identical yet subtly different semantics, and complicated conflict resolution rules. It will be very hard to achieve interoperability there, and it will be hard to use.

The current proposal even directly contradicts JWK:

> The JWK "use" value "enc" shall be equivalent to the "uses" value [ "enc",
> "dec" ].

While JWK says:

   When a key is used to wrap another key and a key use designation for
   the first key is desired, the "enc" (encryption) key use value SHOULD
   be used, since key wrapping is a kind of encryption.

My point is that ideally, we will find out that we can live with JWK as specified by JOSE, only extending it via official registries and not conflicting with JWK spec at all. But if it's not possible, then creating an entirely separate format is likely better than extending JWK in incompatible ways.

(In reply to Alexey Proskuryakov from comment #8)
> It's probably best to discuss use cases separately, as linear flow of a bug
> is not well suited to discussing multiple issues at once. I'm not sure if
> usage is the best solution in either case that you provided, but I'm not an
> expert in cryptography.
> 
> But talking about key format specifically, I object to having a format that
> is almost like JWK, but has an additional key with a similar name, almost
> identical yet subtly different semantics, and complicated conflict
> resolution rules. It will be very hard to achieve interoperability there,
> and it will be hard to use.
> 
> The current proposal even directly contradicts JWK:
> 
> > The JWK "use" value "enc" shall be equivalent to the "uses" value [ "enc",
> > "dec" ].
> 
> While JWK says:
> 
>    When a key is used to wrap another key and a key use designation for
>    the first key is desired, the "enc" (encryption) key use value SHOULD
>    be used, since key wrapping is a kind of encryption.

Ok, so "use" = "enc" is equivalent to "uses" = [ "enc", "dec", "wrap", "unwrap" ]

> 
> My point is that ideally, we will find out that we can live with JWK as
> specified by JOSE, only extending it via official registries and not
> conflicting with JWK spec at all. But if it's not possible, then creating an
> entirely separate format is likely better than extending JWK in incompatible
> ways.

My requirement is just to be able to map from a WebCrypto Key to a JWK and back without loss of information. I agree that "uses" is not very elegant. What do you propose ?

[Btw, the proposal above *is* only extending JWK with official registries.]

> My requirement is just to be able to map from a WebCrypto Key to a JWK and
> back without loss of information. I agree that "uses" is not very elegant.
> What do you propose ?

I get the "ext" key - with the same reservations as everyone else - but I think that I do get it.

It's not clear to me why preserving usage with 100% fidelity is important. My thinking is that fine grained WebCrypto usages are an aid to web developer, not a security measure (an analogy in C++ would be "const" variables - these are super useful, even though they don't provide any protection against willfully overriding constness).

I think that a good way forward may be to split the discussion into multiple threads on the mailing list, each discussing a WebCrypto use case that is not possible because of insufficient granularity of JWK "use" values.

I think that *if* we end up thinking that WebCrypto needs to exactly round-trip usages values through JWK, then extending "use" value set would be a cleaner solution than adding "uses".

Based on the email discussion, here is a revised proposal for representing JWK usages. 

---Replace Section y.2 of the original proposal above with:---

y.2 JWK "use" attribute

This specification defines additional values for the JWK attribute "use" that enables accurate representation of the WebCrypto usage values.

Since WebCrypto keys may have multiple usage values, we also allow multiple usages to be specified as a comma-separated list.

WebCrypto KeyUsage value | Value in JWK use string
encrypt | enconly
decrypt | deconly
sign | sigonly
verify | vfyonly
deriveKey | drvkey
deriveBits | drvbits
wrapKey | wrap
unwrapKey | unwrap

The JWK "use" value may contain a single registered value or a comma-separated list of values, with no whitespace, 

Note that with these definitions, the JWK "use" value "enc" is equivalent to the value "enconly,deconly,wrap,unwrap" and the value "sig" is equivalent to the value "sigonly,vfyonly".

---Remove the "uses" registration from section x.2---

---Add a new section x.3 as follows---

x.3 JSON Web Key Use Registry

   o  Use Member Value: "enconly"
   o  Use Description: Encryption
   o  Change Controller: W3C WebCrypto working group
   o  Specification Document(s): Section y.2 of [[ this document ]]

   o  Use Member Value: "deconly"
   o  Use Description: Decryption
   o  Change Controller: W3C WebCrypto working group
   o  Specification Document(s): Section y.2 of [[ this document ]]

   o  Use Member Value: "sigonly"
   o  Use Description: Signature and HMAC generation
   o  Change Controller: W3C WebCrypto working group
   o  Specification Document(s): Section y.2 of [[ this document ]]

   o  Use Member Value: "vfyonly"
   o  Use Description: Signature and HMAC verification
   o  Change Controller: W3C WebCrypto working group
   o  Specification Document(s): Section y.2 of [[ this document ]]

   o  Use Member Value: "drvkey"
   o  Use Description: Key derivation
   o  Change Controller: W3C WebCrypto working group
   o  Specification Document(s): Section y.2 of [[ this document ]]

   o  Use Member Value: "drvbits"
   o  Use Description: Shared secret derivation
   o  Change Controller: W3C WebCrypto working group
   o  Specification Document(s): Section y.2 of [[ this document ]]

   o  Use Member Value: "wrap"
   o  Use Description: Key wrapping
   o  Change Controller: W3C WebCrypto working group
   o  Specification Document(s): Section y.2 of [[ this document ]]

   o  Use Member Value: "unwrap"
   o  Use Description: Key unwrapping
   o  Change Controller: W3C WebCrypto working group
   o  Specification Document(s): Section y.2 of [[ this document ]]

   o  Use Member Value: All comma-separated non-whitespace-containing duplicate-free non-empty lists of non-comma-containing registered values
   o  Use Description: The union of the listed uses
   o  Change Controller: W3C WebCrypto working group
   o  Specification Document(s): Section y.2 of [[ this document ]]

In the absence of further comments I will implement this in the Editor's Draft.

https://dvcs.w3.org/hg/webcrypto-api/rev/f3240a7d89f2
https://dvcs.w3.org/hg/webcrypto-api/rev/07b333881f7d
https://dvcs.w3.org/hg/webcrypto-api/rev/878e400170ea

Reopening. Need to align with recent decision of JOSE to include 'key_ops' attribute that can represent WebCrypto Key usages.

https://dvcs.w3.org/hg/webcrypto-api/rev/05819fa07004

- align with JWK-20
- add JWK values for WebCrypto algorithms that do not already have them
- define mapping between WebCrypto Key and JWK
- remove use values registration in favor of key_ops