Subject: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

From: "Jim Schaad" <[email-masked]>
Date: Mon, 21 May 2012 15:46:05 -0700

Here are comments this document

Abstract

1.  Since I called it out for JWK I will make the comment that I do not have
a problem with enumerate in this document.

Section 1

1.  Just a comment - I am not sure why you feel the name to create a
specific acronym for this document but it does not really matter.

2.  Need to expand JSON if you are going to use it.

3.  New paragraph for sentence starting with "Enumerating..."  Separate
justification from what this document does and hash.

4.  Move last sentence to the end of the first paragraph

Section 2

1.  In general I would like to see this duplicated into this document.
Readers should not have to reference another document for this purpose.

Section 3.1

1.  I am not overly happy with the existence of a "none" algorithm.  Does it
really need to exist?

Section 3.2

1.  You may want to reference RFC4231 as well.  It contains test vectors and
such for the SHA2 HMACs

2.  HMAC SHA-256 is a MAC function not a hash function (para #2)

3.  I have not yet read the updated JWS document, but I do worry about the
fact that this document is saying that the output should be base64url
encoded.  If the JWS document says the same thing injudiciously then one
could easily see that people might double encode the result.

4.  I have a real problem with people saying that UTF-8 and ASCII are the
same.  They aren't and saying that they are does not make it so. 

5.  I find it confusing to constantly refer to the JWS specification
throughout this text.  For one thing it makes it harder to refer to these
documents for other uses in JSON of these algorithms (such as for an encrypt
and MAC algorithm).

Section 3.3

1.  I am not sure why there is a reference to both RFC 3447 and FIPS 186-3.
RSA v1.5 is fully defined and described in 3447.

2.  I would move the justification of PKCS v1.5 to security considerations
and not put it here.

Section 3.4

1.  I am not sure that the statement on key sizes makes any sense given that
a key size is implied by the group being used.

2.  Given that we are using JSON as the basic structure - why not use a JSON
structure rather than concatenate - just the question of size?

3.  If you are doing a guide for idiots - then you need to give the array
sizes for R and S for each of the algorithms

4.  I have never see the R,S pair be referred to as a point before.  I
believe it is just an ordered pair of integers and not a point on the field.

5.  The following sentence puzzles me "The ECDSA validator will then
determine if the digital signature is
   valid, given the inputs."   This sentence is just after the steps of how
to do validation so saying it will then be validated does not make sense to
me.

Section 3.5

1. I would put the justification for plaintext JWS in JWS not here.  In fact
I would almost prefer a version of JWS that omitted the alg parameter to say
that it has no security than what is done here.  I think this entire section
should be moved into JWS.

Section 3.6

1.  I don't see the purpose of the last paragraph in this section.  It has
nothing to do with algorithms.

Section 4.5 

1.  RSA-OAEP is under specified.  There are a number of parameters for OAEP
that must be defined to go with it.  These include the mask function and a
hash function.  Look at RFC 3447 for the details.

Section 4.6

1.  I would rephrase the last paragraph as being you must re-generate a new
EPK for each key agreement done rather than saying that you cannot reuse
them.  The way specified might say that you can never re-use them rather
than you should only rarely re-use them and in an unpredictable manner.

2.  I strongly disagree with setting OtherInfo parameters to be empty.   We
need to define and fill in the AlgorithmId at a minimum.  Note that this can
be an implicit computation and does not need to be carried as extra data.
At a minimum I would suggest something along the lines of JOSE-### where ###
is the number of bits to get generated.

3.  Same comment as above about key sizes - key sizes are specified by the
curve being used.

Section 4.8

1. Use of an IV is REQUIRED not RECOMMENDED

Section 4.9

1.  Specification of the data to be processed needs to be in JWE not in this
document.  It should just specify that there are the following inputs:
Additional data and data to be encrypted.   Interesting question of is this
where the key is generated or not - I would ignore that issue.

Section 4.10

1.  Is this section needed?  It is a duplicate of the same data in section
3.2 (or it should be)

Section 4.11

1.  for last paragraph see comment on 3.6

Section 6.1

1.  I would move this registry to either the signature or encryption
documents and not put it here.  What does this document populate it with?

Section 6.2

1.  Make life easy for IANA and me - create a table of the values

2.  Can an algorithm have more than one usage?

Section 6.3

1.  This registry should be in either the encryption or signature draft

Section 6.4

1.  This registry should be in the JWK document

Section 6.5

1.  Make life easy for IANA and me - create a table of the values

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 22 May 2012 11:31:43 +1000

> 1.  I am not overly happy with the existence of a "none" algorithm.  Does it

+1 for removing "none"

> could easily see that people might double encode the result.

The algorithms spec should map a string, eg "HS512", to the "standard model" for that type of algorithm. The standard model for a MAC, for example, has two inputs (key and data) and one output (mac), all of which are byte arrays.

A better structure for the algorithms spec would be 8 sections for the 8 types of algorithm: asymmetric signature, MAC, asymmetric key encryption, symmetric key wrapping, asymmetric key agreement, symmetric encryption, AEAD, public key. Each section would describing the model for that type of algorithm: inputs and outputs, and their types (generally byte arrays). A sub-section for each specific name would reference the algorithm's external specification and add any restrictions on options or lengths.

Leave it to JWE/JWS/JWT to take care of how to package it all together (eg to support asymmetric key encryption or symmetric key wrapping or key agreement in a JSON structure; what to base64url encode...).

> Section 4.9 [A128GCM, A256GCM]

NIST 800-38D says the authentication tag for A128GCM or A256GCM can be 128, 120, 112, 104, or 96 bits long (or 64 or 32 bits for certain applications) -- regardless of the key size. It cannot be 256 bits. I suspect we should just pick 128 bits.

REPLACE
   The requested size of the "authentication tag" output MUST be the
   same as the key size (for instance, 128 bits for "A128GCM").
WITH
   The "authentication tag" MUST be 16 bytes (128 bits),
   regardless of the key size.

> Section 6.2 [algorithm registry]
>

Each algorithm name should be assigned to 1 of the 8 algorithm type, not just "alg", "enc", or "int".

The JWE spec, for instance, can say its 'alg' field can hold names from the 3 types (asymmetric key encryption, symmetric key wrap, asymmetric key agreement) etc.

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Wed, 30 May 2012 00:45:48 +0000

Hi James,

Thanks for pointing out the legal AES GCM "authentication tag" sizes.  The next version of the JWE spec will say "The requested size of the 'authentication tag' output MUST be 128 bits, regardless of the key size", as you suggested.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Monday, May 21, 2012 6:32 PM
To: [email-masked]
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

> Section 3.1
>
> 1.  I am not overly happy with the existence of a "none" algorithm.  
> Does it really need to exist?

+1 for removing "none"

> 3.  I have not yet read the updated JWS document, but I do worry about 
> the fact that this document is saying that the output should be 
> base64url encoded.  If the JWS document says the same thing 
> injudiciously then one could easily see that people might double encode the result.

REPLACE

--
James Manger
_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose