At least from my point of view, the problem here is that WebCrypto
unnecessarily uses different identifiers for things that can already be
distinguished from context. For instance with "use":"sig", if you have the
private key, you can do what WebCrypto calls "sign" and if you have the public
key, you can do what WebCrypto calls "verify". Both are parts of the signature
flow, and depending upon which key of the key-pair you're using, you can tell
which is which.
Likewise, WebCrypto unnecessarily distinguishes between key encryption and data
encryption, when you can tell from context which you're doing. If that's not
enough context, then include an "alg" value with the JWK, to limit the key use
to a specific algorithm. (The JOSE "alg" values for data encryption and key
encryption *are* different.)
And before you bring up symmetric keys, the operations are actually the same,
so WebCrypto is insisting on a distinction without a difference.
Has WebCrypto considered dropping the distinctions such as sign/verify, which
can be determined from context?
>From my point of view, it would be a lot cleaner to use a different
>identifier, such as "WebCrypto_uses" than to overload "use" with different,
>but related values. It will hurt interoperation by creating keys that use a
>common identifier differently, and in a non-interoperable manner. Far better
>to use a different identifier, which can be safely ignored by vanilla JWK
>implementations, rather than to overload the standard identifier, and
>potentially cause JWK implementations to reject the keys.
-- Mike
From: Mark Watson [mailto:[email protected]]
Sent: Saturday, December 14, 2013 12:37 AM
To: Mike Jones
Cc: [email protected]
Subject: Re: [jose] JWK "use" attribute and multiple uses
Sent from my iPhone
On Dec 13, 2013, at 9:04 PM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
As already fairly extensively discussed, many in the JOSE working group believe
that it is a security problem to use the same key for multiple uses.
Therefore, "use" is, and I believe should remain, single-valued.
Well, this is in complete contradiction to the existing use values which each
encompass multiple actual uses (enc = encrypt, decrypt, wrap, unwrap for
example). I agree with the principle, but the current use definition in JOSE
doesn't.
Also, as discussed on the list, if WebCrypto wants to record additional key
properties in a JWK, that's no problem. Just register a new key parameter and
use it. For instance, you could register "webcrypto_uses" and use exactly the
same key uses parameters that WebCrypto uses. Use of "use" is optional, and
WebCrypto could specify whether it MUST, MUST NOT, or MAY also be used for
WebCrypto keys.
There was strong push-back against registering a new attribute with overlapping
semantics and a preference for extending the existing attribute defined for
this purpose. That is what we have done for the 'single-use' cases, but there
are valid use-cases for multiple uses (e.g. both encrypt and decrypt).
The only question here is whether we can register an Array type value or
whether we have to register a string value which is a comma-separated list
(with attendant parsing issues). It would be fine for JOSE to just relax the
requirement that use values are strings and allow them to have any valid JSON
value.
...Mark
-- Mike
From: jose [mailto:[email protected]] On Behalf Of Mark Watson
Sent: Tuesday, December 10, 2013 1:09 PM
To: [email protected]<mailto:[email protected]>
Subject: [jose] JWK "use" attribute and multiple uses
All,
Currently, the JWK "use" attribute effectively distinguishes between JWE
("enc") and JWA ("sign").
However, additional uses can be added to the registry and the W3C WebCrypto
group is planning to register use values corresponding to the KeyUsage values
defined for WebCrypto Key objects. These KeyUsage values include, for example,
encrypt, decrypt, sign, verify, wrap, unwrap etc.
A WebCrypto Key object may have multiple KeyUsages and so we have a question as
to how to represent that in JWK.
One proposal is to allow the use string to contain a comma-separated list of
values. We could register such a scheme directly with IANA.
It would be cleaner, though, since this is JSON, to allow this attribute to
have Array type where two or more usages are to be represented (it would remain
a string for the single-usage case). I've also had some negative feedback from
implemetors about the comma-separated-value idea along
yet-another-string-parser lines.
Would it be possible to modify the Registry for JWK use values to allow data
types other than String to be registered ?
...Mark
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
