[Bug 27814] Section A.2 - the usage mapping of "enc" is incorrect

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27814

--- Comment #4 from jimsch <ietf@augustcellars.com> ---
(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 12 January 2015 22:22:45 UTC