Can you explain in more details why you believe Section 4.2 supports your conclusions regarding deriveBits and deriveKey?

In particular, I'm guessing you're focusing on the (grammatically incorrect) language from 4.2 that says

   The "enc" value is also be used for public keys used for key
   agreement operations.

That sentence would be one strong argument, I am not sure why you are saying that it is grammatically incorrect however.  Remember that for the JOSE working group the following is a key agreement algorithm - ECDH-ES+A128KW.  This composite algorithm does do an encryption operation and not just a key wrap algorithm.

This difference of opinions is one of the reasons why key_ops needed to be defined, to get a much finer view of what the operations were that were associated with a key.  You are thinking in terms what what it means for the algorithm "ECDH" and there is no such algorithm in the JOSE world.

This we have the sentence that explicitly states it to be true and we have an explicit example of the usage in the document.  I think that is good support for the thinking of the JOSE document editors and working group.

(In reply to jimsch from comment #2)
> That sentence would be one strong argument, I am not sure why you are saying
> that it is grammatically incorrect however. 

"is also be"

Is this
"is also to be" (e.g. a SHOULD-type requirement)

Was it a typo for
"may also be" (e.g. a MAY-type requirement)

Or something else. Either way, it's a wrong agreement.

> Remember that for the JOSE
> working group the following is a key agreement algorithm - ECDH-ES+A128KW. 
> This composite algorithm does do an encryption operation and not just a key
> wrap algorithm.

I'm not sure if you meant to write something else, because I don't think the argument made supports your point, even though there is one to be made.

That is, for using ECDH-ES+A128KW in an "alg" parameter of some JWE, which has an associated JWK public key, the operations performed are:
- Key agreement with ECDH (yielding a secret Z)
- Key derivation (by feeding that Z into Concat, per https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-4.7 )
- Encryption-via-key-wrap (with AES Key Wrap)

> 
> This difference of opinions is one of the reasons why key_ops needed to be
> defined, to get a much finer view of what the operations were that were
> associated with a key.  You are thinking in terms what what it means for the
> algorithm "ECDH" and there is no such algorithm in the JOSE world.

I'm thinking in terms of ECDH because there is no such AEDH-ES+A128KW in the Web Crypto world. The fact that it's composed of three operations is somewhat irrelevant for Web Crypto, because there is (intentionally) no way to represent this.

> 
> This we have the sentence that explicitly states it to be true and we have
> an explicit example of the usage in the document.  I think that is good
> support for the thinking of the JOSE document editors and working group.

1) That sentence talks about public keys (so should we assume the omission of private keys was intentional or accidental)
2) That sentence is, as you note, in the context of composite algorithms.
  - In the case of ECDH-ES+A128KW, the composition is (Agreement, Derivation, Wrap)
  - In the case of ECDH-ES, the composition is (Agreement, Derivation, Encrypt)

Please note that Appendix A.2 is *non-normative*. It is merely *informative*. You can see the actual requirement for ECDH keys in 

https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#ecdh-description

In particular, importKey dictates that if "use" is present in a JWK, then throw a DataError.

(In reply to Ryan Sleevi from comment #3)
> (In reply to jimsch from comment #2)
> > That sentence would be one strong argument, I am not sure why you are saying
> > that it is grammatically incorrect however. 
> 
> "is also be"
> 
> Is this
> "is also to be" (e.g. a SHOULD-type requirement)

This is the reading that I am using.  (MAY for presence - MUST for what it means)

> 
> Was it a typo for
> "may also be" (e.g. a MAY-type requirement)
> 
> Or something else. Either way, it's a wrong agreement.

You are right - I have forward to the document editor to get it fixed.  That is what I get for having read the document too many times.

> 
> > Remember that for the JOSE
> > working group the following is a key agreement algorithm - ECDH-ES+A128KW. 
> > This composite algorithm does do an encryption operation and not just a key
> > wrap algorithm.
> 
> I'm not sure if you meant to write something else, because I don't think the
> argument made supports your point, even though there is one to be made.
> 
> That is, for using ECDH-ES+A128KW in an "alg" parameter of some JWE, which

It is also an "alg" parameter for some JWK - which says that the JWK is to be used only for JWE operations which have the same "alg" value.  That is it can be used to restrict the set of algorithms the key can be used with.

> has an associated JWK public key, the operations performed are:
> - Key agreement with ECDH (yielding a secret Z)
> - Key derivation (by feeding that Z into Concat, per
> https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-4.
> 7 )
> - Encryption-via-key-wrap (with AES Key Wrap)

And, from a JOSE perspective, this results in an encryption operation even though there are some operations performed which are not encryption in the middle.  Only the composite algorithm is to be considered.

> 
> > 
> > This difference of opinions is one of the reasons why key_ops needed to be
> > defined, to get a much finer view of what the operations were that were
> > associated with a key.  You are thinking in terms what what it means for the
> > algorithm "ECDH" and there is no such algorithm in the JOSE world.
> 
> I'm thinking in terms of ECDH because there is no such AEDH-ES+A128KW in the
> Web Crypto world. The fact that it's composed of three operations is
> somewhat irrelevant for Web Crypto, because there is (intentionally) no way
> to represent this.
> 
> > 
> > This we have the sentence that explicitly states it to be true and we have
> > an explicit example of the usage in the document.  I think that is good
> > support for the thinking of the JOSE document editors and working group.
> 
> 1) That sentence talks about public keys (so should we assume the omission
> of private keys was intentional or accidental)

I am sure this was accidental.  Given that private keys were not added until late in the process (as the request of the W3C) there are probably still a number of places where this type of oversight on correcting text has been made.
However the principle of restricting operations with a key implies that this should apply to private keys as well. Not sure what would be required to make it more correct at this point from an IETF process perspective.

> 2) That sentence is, as you note, in the context of composite algorithms.
>   - In the case of ECDH-ES+A128KW, the composition is (Agreement,
> Derivation, Wrap)
>   - In the case of ECDH-ES, the composition is (Agreement, Derivation,
> Encrypt)
> 
> Please note that Appendix A.2 is *non-normative*. It is merely
> *informative*. You can see the actual requirement for ECDH keys in 
> 

It is not normative, however it is indicative of the thinking of the working group.

> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#ecdh-
> description
> 
> In particular, importKey dictates that if "use" is present in a JWK, then
> throw a DataError.

And was I ever surprised when the import operation did not work because of this.  This was completely unexpected behavior

(In reply to jimsch from comment #4)
> It is also an "alg" parameter for some JWK - which says that the JWK is to
> be used only for JWE operations which have the same "alg" value.  That is it
> can be used to restrict the set of algorithms the key can be used with.
<snip>
> And, from a JOSE perspective, this results in an encryption operation even
> though there are some operations performed which are not encryption in the
> middle.  Only the composite algorithm is to be considered.

I'm still a little confused here about how it's relevant to WebCrypto, in as much we don't support the composite algorithms.


<snip>
> > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#ecdh-
> > description
> > 
> > In particular, importKey dictates that if "use" is present in a JWK, then
> > throw a DataError.
> 
> And was I ever surprised when the import operation did not work because of
> this.  This was completely unexpected behavior

Not to sound dismissive, but there's been plenty of "unexpected" behaviour that comes when people have approach with different mindsets. e.g. I see that Anders recently raised again that it was "unexpected" behaviour that JOSE and Web Crypto algorithms don't match - which is unexpected if you think the two are meant to solve the same use cases and problems, or completely expected if you think they aren't (which they aren't, as was pointed out on the JOSE list).

In order to better understand this impedence, could you provide a scenario where things would break under the current behaviour? And what I mean by that is not so much a contrived case (we can easily see that "use" on a JWK would be rejected, as per the spec), but a use case where it would cause issue? I think that may help make it clearer the issue at hand.

Also, to make sure I'm understanding your argument well enough to repeat it:
- In JOSE, an EC public key with an "alg" of "enc" is used for a combined ECDH-ES or ECDH-ES+A*KW algorithm, which grants the EC public key the deriveKey capability, which is then fed into Concat to either derive a Wrap/Unwrap AES-KW key (ECDH-ES+A*KW) or a Encrypt/Decrypt [any alg here] CMK key (ECDH-ES)
- Thus, when used with JOSE, in all cases, a JWK EC key with "enc" implies deriveKey/deriveBits

Now, you've filed this bug against Appendix A.2, but it sounds like the *real* issue is with ECDH + JWK import. That is, one would not necessarily have the deriveKey/deriveBits usages on an RSA key, and for a JWK secret key, it would be an algorithm-by-algorithm basis (e.g. an AES key would not have the deriveKey/deriveBits, but if we allowed an HKDF key to be imported as JWK, then a 'use' field would be presumably valid)

Have I properly restated the issue as you see it?

(In reply to Ryan Sleevi from comment #5)
> (In reply to jimsch from comment #4)
> > It is also an "alg" parameter for some JWK - which says that the JWK is to
> > be used only for JWE operations which have the same "alg" value.  That is it
> > can be used to restrict the set of algorithms the key can be used with.
> <snip>
> > And, from a JOSE perspective, this results in an encryption operation even
> > though there are some operations performed which are not encryption in the
> > middle.  Only the composite algorithm is to be considered.
> 
> I'm still a little confused here about how it's relevant to WebCrypto, in as
> much we don't support the composite algorithms.
> 

A JOSE application retrieves a key set from a url.  The key set looks like:

{"keys":[ {"kty":"EC", "use":"enc", ... },
          {"kty":"EC", "use":"sig", ... }]}

In this case the use parameter is used to distinguish between which keys are to be used to verify signatures and which are to be used for encrypting messages.
If there is an attempt by the JOSE application to import the first key, it will fail because of the use field.  The second will work just fine.  

Support of JOSE is one of the documented use cases.

(In reply to jimsch from comment #6)
> A JOSE application retrieves a key set from a url.  The key set looks like:
> 
> {"keys":[ {"kty":"EC", "use":"enc", ... },
>           {"kty":"EC", "use":"sig", ... }]}
> 
> In this case the use parameter is used to distinguish between which keys are
> to be used to verify signatures and which are to be used for encrypting
> messages.
> If there is an attempt by the JOSE application to import the first key, it
> will fail because of the use field.  The second will work just fine.  

Of course, in order to use the "enc" key, the JOSE application *MUST* perform transliteration of ECDH-ES(+A128KW/+A256KW) into a composite set of steps, so the 'theory' goes that they could just as well remove the 'use' field, since 'use' fields aren't supported by EC.

> 
> Support of JOSE is one of the documented use cases.

This is probably the weakest argument you could make. I'm trying to help you out though =)

To spell explicitly where I was trying to lead you: An application author can fully control this behaviour. As far as I can tell, nothing in the JOSE specs would have a wrapped JWK as the CMK with a kty of EC and a "use" of "enc", which would be the one place that an application author can't take action.

That is, the complexity regarding JWK is *solely* due to key wrap/unwrap existing in the spec - any other formatting changes can be made at the application level, and any support in the spec would just be sugar to not annoy devs. Because wrap/unwrap do exist, the argument for supporting "use": "enc" is that we should support wrapped EC keys to be used with those JOSE algorithms.

It's still a fairly weak argument - Web Crypto will never produce such keys, so it's up to the wrapper to "do the right thing", and we already have precedent elsewhere in the spec for requiring that the wrapper "do the right thing" (e.g. whitespace padding of JWK for AES-KW)

So that's an argument that I think you should be making, rather than "JOSE said so"

I happen to disagree.  I believe that the argument "because JOSE says so" is the strongest possible argument that can be made.  The argument goes along the lines of:

JOSE defined the JWK structure.
JOSE defined the "use" parameter within that structure.
JOSE defined the value of the "use" parameter for types of type "EC".
WebCrypto should follow the standard produced by the JOSE group.

Compared to this argument, any other argument is in my opinion extremely weak.  If you don't accept this argument then I don't think we would ever be able to reach an agreement.

If you would prefer that the bug be filed against the JWK import of ECDH keys (there is no jwk import for DH so it would not apply there yet), I am willing to make that change.  I don't see that it changes any of the base arguments what the title is.  The text of the initial bug says that this needs to be done as well.

I am not sure what the purpose of Appendix A.2 is.  It appears to me to make a statement on what the meaning of the JWK "use" value are in terms of the WebCrypto "usage" parameter.  However, I note that this is non-normative so the fact that it does not include the deriveBits and deriveKey values can be ignored.  I guess that means that I would not care if this gets fixed as long as the algorithm specific methods get fixed.

I agree that, in the event that allowing a jwk import for any of the KDF algorithms is permitted, then the question of what enc means.  However, in this case I would not have any specific argument that can be made.  I would say that WebCrypto could make any statement that it desired as the JOSE documents are silent in this instance.

I find the argument you make about the fact that WebCrypto does not tag a use at export time to be weak.  I would never expect that WebCrypto would ever define a use parameter on export.  It should only use the key_ops parameter as this has much better security properties.  I could extend your argument to be - since we never export a jwk with a use parameter, we should never import one which has the parameter set.  Is that your intent?

I don't expect that the WebCrypto group would ever define RSA-KEM (http://tools.ietf.org/html/rfc5990 and ASN-X9.44) as one of its algorithms, but it is not immediately clear if the correct set of usages for this algorithm is encrypt/decrypt or deriveBits/deriveKeys (returning both the encrypted secret and the derived bits/key).   This means that there is a possibility (however remote) that a use of enc is the wrong value for an RSA key as well as an EC key.  

The main reason for using KEM rather than OAEP is that the security proofs are so much better with KEM.  There are real tight proofs for KEM.  As an aside, it is also a demonstration for Mark as to why one does not want to put an upper limit on the amount of entropy that can be given to a KDF algorithm.

(In reply to jimsch from comment #8)
> JOSE defined the JWK structure.
> JOSE defined the "use" parameter within that structure.
> JOSE defined the value of the "use" parameter for types of type "EC".

For which JOSE only allows composed operations, whereas WebCrypto allows arbitrary primitives.

> WebCrypto should follow the standard produced by the JOSE group.

I suspect we'll just get in an unproductive discussion here. I just want to reiterate that this group has repeatedly made clear that there exist differences between Web Crypto and JOSE and for good reason.

This has born out in past discussions (e.g. regarding key ID, algorithm names) that there are fundamentally differences between APIs and wire-messaging formats like JWK/JOSE.

This is why it's a weak argument. It's the same reasoning that constraints that exist in JWS (e.g. https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-39#section-3.3 requiring a >= 2048-bit RSA key) are not applied to the base JWK format.

> If you would prefer that the bug be filed against the JWK import of ECDH
> keys (there is no jwk import for DH so it would not apply there yet), I am
> willing to make that change.  I don't see that it changes any of the base
> arguments what the title is.  The text of the initial bug says that this
> needs to be done as well.

The argument is that Appendix A.2 probably shouldn't be changed, but perhaps ECDH should be. That runs counter to your argument (which is ECDH should be changed because A.2 is changed)

> I find the argument you make about the fact that WebCrypto does not tag a
> use at export time to be weak.  I would never expect that WebCrypto would
> ever define a use parameter on export.  It should only use the key_ops
> parameter as this has much better security properties.  I could extend your
> argument to be - since we never export a jwk with a use parameter, we should
> never import one which has the parameter set.  Is that your intent?

No, I fear you have misunderstood this argument. I'm going to try to restate the point to make it clear:
- WebCrypto will NEVER tag a 'use', so this does NOT cause any issues between two Web Crypto implementations
- For keys that are not wrapped, the JS author can ALWAYS remove the use field if necessary. This is no different than the JS author needing to fix up 'alg' into the appropriate composite Web Crypto operations.
- Therefore, the ONLY issue is when receiving a wrapped key from some other, non-WebCrypto implementation

In the same way that WebCrypto does NOT allow/define reliable wrapping of JWK (e.g. to meet the padding requirements of AES-KW), and that is left to the external system, it COULD be simply an API requirement that any implementation sending such a key to WebCrypto should be explicitly using the key_ops field, rather than 'use'

This argument fails IFF it's possible for JOSE implementations to generate wrapped keys that are used in JOSE messages, where the JOSE implementation is defined to use 'use'. I can find no such support in the spec, but obviously, I'm not implementing JOSE.

> 
> I don't expect that the WebCrypto group would ever define RSA-KEM
> (http://tools.ietf.org/html/rfc5990 and ASN-X9.44) as one of its algorithms,
> but it is not immediately clear if the correct set of usages for this
> algorithm is encrypt/decrypt or deriveBits/deriveKeys (returning both the
> encrypted secret and the derived bits/key).   This means that there is a
> possibility (however remote) that a use of enc is the wrong value for an RSA
> key as well as an EC key.  

It's not clear why you suggest RSA-KEM would be derive*, when all of the past discussions have been in the context of it being a key wrapping method.

> The main reason for using KEM rather than OAEP is that the security proofs
> are so much better with KEM.  There are real tight proofs for KEM.  As an
> aside, it is also a demonstration for Mark as to why one does not want to
> put an upper limit on the amount of entropy that can be given to a KDF
> algorithm.

I'm aware. We've discussed this in the past, for some time, and it was always in the context of wrap/unwrap (aka encrypt/decrypt). It's not clear why you would suggest it's a deriveKey operation, since KEM as an operation involves a set of composite steps.

(In reply to Ryan Sleevi from comment #9)
> (In reply to jimsch from comment #8)
> > JOSE defined the JWK structure.
> > JOSE defined the "use" parameter within that structure.
> > JOSE defined the value of the "use" parameter for types of type "EC".
> 
> For which JOSE only allows composed operations, whereas WebCrypto allows
> arbitrary primitives.
> 
> > WebCrypto should follow the standard produced by the JOSE group.
> 
> I suspect we'll just get in an unproductive discussion here. I just want to
> reiterate that this group has repeatedly made clear that there exist
> differences between Web Crypto and JOSE and for good reason.
> 
> This has born out in past discussions (e.g. regarding key ID, algorithm
> names) that there are fundamentally differences between APIs and
> wire-messaging formats like JWK/JOSE.

I guess that would make my life as a designated expert for IANA on the issue of algorithm registration easier.  I can deny the registration of the "alg" values that are being requested because there are "fundamental differences between the usage of the parameter and the WebCrypto registrations are incompatible with those of JOSE".

> 
> This is why it's a weak argument. It's the same reasoning that constraints
> that exist in JWS (e.g.
> https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-39#section-3.
> 3 requiring a >= 2048-bit RSA key) are not applied to the base JWK format.
> 
> > If you would prefer that the bug be filed against the JWK import of ECDH
> > keys (there is no jwk import for DH so it would not apply there yet), I am
> > willing to make that change.  I don't see that it changes any of the base
> > arguments what the title is.  The text of the initial bug says that this
> > needs to be done as well.
> 
> The argument is that Appendix A.2 probably shouldn't be changed, but perhaps
> ECDH should be. That runs counter to your argument (which is ECDH should be
> changed because A.2 is changed)

I am happy to flip the argument if it makes you happy.  I don't care.

> 
> > I find the argument you make about the fact that WebCrypto does not tag a
> > use at export time to be weak.  I would never expect that WebCrypto would
> > ever define a use parameter on export.  It should only use the key_ops
> > parameter as this has much better security properties.  I could extend your
> > argument to be - since we never export a jwk with a use parameter, we should
> > never import one which has the parameter set.  Is that your intent?
> 
> No, I fear you have misunderstood this argument. I'm going to try to restate
> the point to make it clear:
> - WebCrypto will NEVER tag a 'use', so this does NOT cause any issues
> between two Web Crypto implementations
> - For keys that are not wrapped, the JS author can ALWAYS remove the use
> field if necessary. This is no different than the JS author needing to fix
> up 'alg' into the appropriate composite Web Crypto operations.
> - Therefore, the ONLY issue is when receiving a wrapped key from some other,
> non-WebCrypto implementation
> 
> In the same way that WebCrypto does NOT allow/define reliable wrapping of
> JWK (e.g. to meet the padding requirements of AES-KW), and that is left to
> the external system, it COULD be simply an API requirement that any
> implementation sending such a key to WebCrypto should be explicitly using
> the key_ops field, rather than 'use'
> 
> This argument fails IFF it's possible for JOSE implementations to generate
> wrapped keys that are used in JOSE messages, where the JOSE implementation
> is defined to use 'use'. I can find no such support in the spec, but
> obviously, I'm not implementing JOSE.

Given that PBKDF2 does not support anything that would look like an "import wrapped key" that is not doable by definition.


> 
> > 
> > I don't expect that the WebCrypto group would ever define RSA-KEM
> > (http://tools.ietf.org/html/rfc5990 and ASN-X9.44) as one of its algorithms,
> > but it is not immediately clear if the correct set of usages for this
> > algorithm is encrypt/decrypt or deriveBits/deriveKeys (returning both the
> > encrypted secret and the derived bits/key).   This means that there is a
> > possibility (however remote) that a use of enc is the wrong value for an RSA
> > key as well as an EC key.  
> 
> It's not clear why you suggest RSA-KEM would be derive*, when all of the
> past discussions have been in the context of it being a key wrapping method.

But the composite operations are:
*Generate a secret
*Derive a key or bytes from a secret

The question is do you treat that as a single operation, or do you force the secret to be exported before doing the derive.  I would probably have a preference for making this a single operation, and thus allow it to stay inside of the implementation, rather than two step process.  This is obviously not your view, and I can understand your view.

> 
> > The main reason for using KEM rather than OAEP is that the security proofs
> > are so much better with KEM.  There are real tight proofs for KEM.  As an
> > aside, it is also a demonstration for Mark as to why one does not want to
> > put an upper limit on the amount of entropy that can be given to a KDF
> > algorithm.
> 
> I'm aware. We've discussed this in the past, for some time, and it was
> always in the context of wrap/unwrap (aka encrypt/decrypt). It's not clear
> why you would suggest it's a deriveKey operation, since KEM as an operation
> involves a set of composite steps.

(In reply to jimsch from comment #10)
> I guess that would make my life as a designated expert for IANA on the issue
> of algorithm registration easier.  I can deny the registration of the "alg"
> values that are being requested because there are "fundamental differences
> between the usage of the parameter and the WebCrypto registrations are
> incompatible with those of JOSE".

I guess, put differently, I would prefer that WebCrypto not have to deal with 'use' at all, because it is understandably a no-fidelity comparison to WebCrypto's model.

Though we've tried to map it (to make it easier for users), it might equally be desirable to reject 'use' entirely [for all keys]. However, I suspect that would make many a JWK proponent unhappy.

> But the composite operations are:
> *Generate a secret
> *Derive a key or bytes from a secret
> 
> The question is do you treat that as a single operation, or do you force the
> secret to be exported before doing the derive.  I would probably have a
> preference for making this a single operation, and thus allow it to stay
> inside of the implementation, rather than two step process.  This is
> obviously not your view, and I can understand your view.

While we run the risk of veering off into a side-discussion on RSA-KEM, to the extent it's relevant to what does 'use': 'enc' mean for an RSA key, I think it's good to continue.

In my reading of RSA-KEM, it isn't
"generate a secret" + "derive a secret"

It is:
"wrap", where the wrapping scheme is composed of:
"generate a secret" + "encrypt with that secret" + concat (secret, encrypted message) as "wrapped key"

The input wrapping key is an RSA key. No ability to specify the random value.

Now, I can certainly appreciate how Steps 1&2 of RFC 5990, Section 1 may, on their face, appear to be agreement scheme (after all, "generate a random value" & "do some exponention" is functionally quite similar to DH-schemes), but I feel like the lack of a confirmation/exchange step, and in particular, Step 5 of Section 1 make it much more akin to a wrapping scheme with a nonce prepended [and, hopefully, a MAC covering it all]. That's why I see the 'enc' use for a hypothetical RSA-KEM still being a 'wrap' / 'unwrap' use, not a derive.

To be clear, if the 'secret' was some implicit value that the two parties arrived on in secret and never exchanged over the wire and wasn't reversible (e.g. as PBKDF2 tries to be, as HKDF / ECDH are), then I think sure, it'd be a derive operation, and likely composite. That is, derive to generate that CryptoKey for the secret, then feed the Secret in to an operation. But that's not RSA-KEM.

(In reply to Ryan Sleevi from comment #11)
> (In reply to jimsch from comment #10)
> > I guess that would make my life as a designated expert for IANA on the issue
> > of algorithm registration easier.  I can deny the registration of the "alg"
> > values that are being requested because there are "fundamental differences
> > between the usage of the parameter and the WebCrypto registrations are
> > incompatible with those of JOSE".
> 
> I guess, put differently, I would prefer that WebCrypto not have to deal
> with 'use' at all, because it is understandably a no-fidelity comparison to
> WebCrypto's model.
> 
> Though we've tried to map it (to make it easier for users), it might equally
> be desirable to reject 'use' entirely [for all keys]. However, I suspect
> that would make many a JWK proponent unhappy.

I don't think it would make them any more unhappy than what it currently is doing.  After all complete rejection is easier to code for.

> 
> > But the composite operations are:
> > *Generate a secret
> > *Derive a key or bytes from a secret
> > 
> > The question is do you treat that as a single operation, or do you force the
> > secret to be exported before doing the derive.  I would probably have a
> > preference for making this a single operation, and thus allow it to stay
> > inside of the implementation, rather than two step process.  This is
> > obviously not your view, and I can understand your view.
> 
> While we run the risk of veering off into a side-discussion on RSA-KEM, to
> the extent it's relevant to what does 'use': 'enc' mean for an RSA key, I
> think it's good to continue.

I had not really expected this point to generate a lot of discussion - this is a bit surprising to me.

> 
> In my reading of RSA-KEM, it isn't
> "generate a secret" + "derive a secret"
> 
> It is:
> "wrap", where the wrapping scheme is composed of:
> "generate a secret" + "encrypt with that secret" + concat (secret, encrypted
> message) as "wrapped key"
> 
> The input wrapping key is an RSA key. No ability to specify the random value.
> 
> Now, I can certainly appreciate how Steps 1&2 of RFC 5990, Section 1 may, on
> their face, appear to be agreement scheme (after all, "generate a random
> value" & "do some exponention" is functionally quite similar to DH-schemes),
> but I feel like the lack of a confirmation/exchange step, and in particular,
> Step 5 of Section 1 make it much more akin to a wrapping scheme with a nonce
> prepended [and, hopefully, a MAC covering it all]. That's why I see the
> 'enc' use for a hypothetical RSA-KEM still being a 'wrap' / 'unwrap' use,
> not a derive.

I would never call this a key agreement scheme - it does not involve two keys so that would be impossible.  I would call it a scheme that is doing key derivation of a secret with a KDF algorithm.  I think that is a very different beast.

> 
> To be clear, if the 'secret' was some implicit value that the two parties
> arrived on in secret and never exchanged over the wire and wasn't reversible
> (e.g. as PBKDF2 tries to be, as HKDF / ECDH are), then I think sure, it'd be
> a derive operation, and likely composite. That is, derive to generate that
> CryptoKey for the secret, then feed the Secret in to an operation. But
> that's not RSA-KEM.

You have a much more restricted version of secret than I do.  By your definition a CEK is never a secret because it is passed over the wire.

One of the reasons that I would not care for you implementation is the same as the current problem of adding a new hash for signatures, there is no way to do it for a key trapped in a browser.  In the same way a KDF is never going to be able to be added to the system.  The KDF needs to be passed in as an argument to the encryption and decryption operations for RSA-KEM.  The same restriction also is placed on new key wrap algorithms as the key wrap algorithm is going to need to be passed into the encryption and decryption operations for RSA-KEM.  And I thought you did not really want to have composite algorithms if they could be easily avoided.

You are also not allowing for the secret encrypted by RSA to be shared among multiple recipients, something that my reading of the documents says is a perfectly secure method of using the algorithm.

(In reply to jimsch from comment #12)
> I don't think it would make them any more unhappy than what it currently is
> doing.  After all complete rejection is easier to code for.

Which is what is currently specced, and which you seem unhappy about, thus this comment leaves me quite confused as to what your desired outcome is now.

In case it isn't clear, I'm mildly supportive of the outcome, but I'm trying to make sure we have sound documentation that's clear - in the context of Web Crypto. The argument that "JOSE said so" doesn't really provide much guidance, nor is it entirely consistent with other decisions (e.g. algorithm names, composites), which is why I'm trying to unpack

1) What the developer experience is, today, when writing a JOSE impl. using WebCrypto?
2) If the spec does not change at all, what use cases are eliminated?
3) If the spec does not change at all, what benefits are gained?
4) When will this situation come up, if at all?

I think these are all solid criteria, and this discussion has mostly been trying to answer these, so that it's clear *why* we're changing in a way that can cause interop issues.

> I would never call this a key agreement scheme - it does not involve two
> keys so that would be impossible.  I would call it a scheme that is doing
> key derivation of a secret with a KDF algorithm.  I think that is a very
> different beast.

OK. I'm just going to have to strongly disagree with you, but this is moot since no one is proposing RSA-KEM be added. I think it's likely sufficient to say that I still disagree on it being a KDF, but that's really best saved for a discussion of how to express RSA-KEM if and when it was exposed (and the reason why it wasn't, in this version, is already documented in this group archives).

(In reply to Ryan Sleevi from comment #13)
> (In reply to jimsch from comment #12)
> > I don't think it would make them any more unhappy than what it currently is
> > doing.  After all complete rejection is easier to code for.
> 
> Which is what is currently specced, and which you seem unhappy about, thus
> this comment leaves me quite confused as to what your desired outcome is now.

Oh - but the next step is to say - since you always error on it, why not just ignore it because it is "application" data and not something that you should be enforcing.

> 
> In case it isn't clear, I'm mildly supportive of the outcome, but I'm trying
> to make sure we have sound documentation that's clear - in the context of
> Web Crypto. The argument that "JOSE said so" doesn't really provide much
> guidance, nor is it entirely consistent with other decisions (e.g. algorithm
> names, composites), which is why I'm trying to unpack
> 
> 1) What the developer experience is, today, when writing a JOSE impl. using
> WebCrypto?

That is more or less what I have been doing.  What I am writing is not exactly JOSE but is almost identical.

> 2) If the spec does not change at all, what use cases are eliminated?

I would say that the JOSE use case is harmed, but not eliminated.  I would say the same thing if the jwk import format was completely eliminated.

> 3) If the spec does not change at all, what benefits are gained?

none that I know of.

> 4) When will this situation come up, if at all?

The question is one of who do you believe is going to do the import of a key into the system.  Is it always going to be a piece of library code or is the user going to want to do it on a regular basis.  If it is always library code, then that code can be written one and always used.  On the other hand if users are going to want to write the code so they can do once imports and then use the key object for the calls to the library then it will affect any user that runs across an EC key with a use of "enc".   There is no way of knowing how consistently this will be done at present.

Of the fields currently defined by the JWK specification, the one one I know of that will be enforced differently than document is the use parameter for an EC encryption designated key.  The "alg" parameter is not enforced for this case, it is only enforced for those cases where it is used to extract additional information - either a key length, a hash length or a curve.

> 
> I think these are all solid criteria, and this discussion has mostly been
> trying to answer these, so that it's clear *why* we're changing in a way
> that can cause interop issues.
>

Moved to https://github.com/w3c/webcrypto/issues/77