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 protected]]
Sent: Sunday, November 10, 2013 7:09 PM
To: John Bradley
Cc: Jim Schaad; Mike Jones; [email protected];
[email protected]
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.
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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> 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
From: Mark Watson [mailto:[email protected]]
Sent: Sunday, November 10, 2013 5:37 PM
To: Jim Schaad
Cc: Michael Jones; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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
On Mon, Nov 11, 2013 at 5:30 AM, Jim Schaad
<[email protected]<mailto:[email protected]>> wrote:
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 protected]<mailto:[email protected]>
> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of
> jose issue tracker
> Sent: Friday, November 08, 2013 4:46 PM
> To:
> [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>
> Cc: [email protected]<mailto:[email protected]>
> Subject: Re: [jose] #187: Define algorithm names for symmetric keys in for
> JWK
>
> #187: Define algorithm names for symmetric keys in for JWK
>
>
> Comment (by [email protected]<mailto:[email protected]>):
>
> 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".
>
> --
> -------------------------+----------------------------------------------
> -------------------------+---
> Reporter: | Owner: draft-ietf-jose-json-web-
> [email protected]<mailto:[email protected]> |
> [email protected]<mailto:[email protected]>
> Type: defect | Status: new
> Priority: minor | Milestone:
> Component: json-web- | Version:
> algorithms | Resolution:
> Severity: - |
> Keywords: |
> -------------------------+----------------------------------------------
> -------------------------+---
>
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/187#comment:2>
> jose <http://tools.ietf.org/jose/>
>
> _______________________________________________
> jose mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
