Skip to main content

JSON Web Algorithms (JWA)
draft-ietf-jose-json-web-algorithms-40

Yes

(Kathleen Moriarty)

No Objection

(Adrian Farrel)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Ted Lemon)

Abstain


Note: This ballot was opened for revision 32 and is now closed.

Kathleen Moriarty Former IESG member
Yes
Yes (for -32) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -33) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2014-09-28 for -33) Unknown
== Section 3.4 ==
"Signing and validation with the ECDSA P-384 SHA-384 and ECDSA P-521
  SHA-512 algorithms is performed identically to the procedure for
  ECDSA P-256 SHA-256 -- just using the corresponding hash algorithms
  with correspondingly larger result values.  For ECDSA P-384 SHA-384,
  R and S will be 384 bits each, resulting in a 96 octet sequence.  For
  ECDSA P-521 SHA-512, R and S will be 521 bits each, resulting in a
  132 octet sequence."

For the ECDSA P-521 SHA-512 case, how does the result amount to 132 octets? Is there padding inserted into R and S?

== Section 7 ==

Do we use iesg@iesg.org? I usually use iesg@ietf.org.

== Section 8.4 ==
"An Initialization Vector value MUST never be used multiple times with
   the same AES GCM key."

I think what was intended here was s/MUST never/MUST NOT/
Barry Leiba Former IESG member
No Objection
No Objection (2014-09-25 for -32) Unknown
I have one comment.  I'm making it non-blocking, but I think it really does need to be clarified, so please chat with me about it:

-- Section 7.1 --

   The implementation requirements of an algorithm MAY be changed over
   time by the Designated Experts(s) as the cryptographic landscape
   evolves, for instance, to change the status of an algorithm to
   Deprecated, or to change the status of an algorithm from Optional to
   Recommended+ or Required.  Changes of implementation requirements are
   only permitted on a Specification Required basis, with the new
   specification defining the revised implementation requirements level.

1 (minor). The "MAY" does not refer to a protocol option, and I think it should not be a 2119 key word.

2 (the real point). I don't understand how the two sentences relate to each other.  The first sentence seems to say that the DE(s) can change implementation requirements on their own.  The second says it has to be done using Specification Required (which doesn't really need to be said, as that's the policy for the registry anyway).

Which is it?  If it's Specification Required, then anyone can propose a change, using a specification, and the DE(s) will review that as they do any other registration request.

This comment also applies to Sections 7.4 and 7.6.
Brian Haberman Former IESG member
(was No Record, No Objection) No Objection
No Objection (for -33) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -33) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -33) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -33) Unknown

                            
Richard Barnes Former IESG member
(was Discuss) No Objection
No Objection (2014-10-01 for -36) Unknown
Section 1.1.
The pointer for BASE64URL should be to JWS.  One level of indirection, please :)

Section 3.1, 4.1, and 5.1.
As I said in the working group, the implementation requirements in these registries should be removed.  They are unnecessary for interoperability, and highly likely to be ignored by implementors, both because (1) many implementations are for specific applications that do not require all of the REQUIRED algorithms, and (2) many implementations use cryptographic libraries that do not support some REQUIRED algorithms.  I have personally written more than one JWS/JWE implementation that ignored these requirements, for exactly these reasons.  (This would be a DISCUSS for me, if not for my having made this argument already in the WG.)

Section 3.2.
"A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm."
A pointer to Section 3 of RFC 2104 here would be helpful.  I was surprised at this requirement, given that FIPS 198 says "The size of the key, K, shall be equal to or greater than L/2, where L is the size of the hash function output."

Section 3.4.
It might be worth noting that though this format seems ad-hoc, it is the same used by WebCrypto.

Section 4.7.1.1.
Shouldn't you require that this field MUST encode a 16-octet / 128-bit value?
Spencer Dawkins Former IESG member
No Objection
No Objection (for -33) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2014-11-27 for -37) Unknown
I'm clearing but think it's still a bad plan to include the 
unimplemented >2 prime RSA support here. It's even
worse to have it as you do where implementations that
don't support this are allowed to use the key pair
nonetheless - that seems designed to lead to a lack
of security or else horrible performance. You should
say that if you don't support >2 prime RSA then you MUST
barf on all such keys. However, based on my belief
that this won't get used in any case, I'm willing to hold
my nose and clear.

-- older comments below, I didn't check them vs. -37
and there's no need to worry about them unless you
want to.


First point was a discuss, now a comment:

(2) Instructions to DEs: would registering DES be considered
ok or not? What about myJustInventedPrivateAlg?  What about a
request for 10 ccTLD specific Algs? I think these need a bit
more clarity wrt cryptographic "goodness." As a nit, "makes
sense" isn't going to help too much, we've seen that
reasonable folks can differ on that here. Again I don't
recall that discussion on the list, but please point me at it
if it happened.

- Unlike others, I do think implementation requirements are
needed. The WG did specifically discuss this (a lot) and
landed where it did. I don't think the IESG should second
guess that without specific evidence that it'd cause damage.
(Richard's points were made previously I believe.)

- 3.3 (and elsewhere) says 2048 bits or larger. I guess that
2049 bit keys might not work for many implementations and are
not a great idea (as Bleichenbacher works quicker against
such lengths if I recall correctly). Could be worth a note
somewhere even though I guess most folks know what's what.

- 4.1 (and elsewhere): adding table captions with numbers
would be good. Col 1 of the final 3 rows are unfortunate.

- Surprised there was no need for integer DH. Can be added
later I guess.

- 6.2.1: Given that the point compression IPR is now expired
(right?) did the WG consider now allowing that? I wondered
how much work it would be to add now, vs to add later. If
"later" would cause a lot of duplication, then maybe "now"
would actually be worth it. ("Later" might also be fine
considering the current work in CFRG on additional curves.) 

- 6.3.1.1: allowing the extra 0x00 would be a better choice
IMO, but whatever. Those were historically added so that
buggy decoders wouldn't wrongly think numbers negative, which
could still happen maybe. 

- 7.1, 2nd para: why not RSA2048 earlier then?

- 7.1.1: It might help the DE if the template here required
references to well know academic crypto conference
publications that consider cryptanalysis of the alg in
question, e.g. from crypto, or eurocrypt etc. One good rule
of thumb here is that if there are no such references then
you really should not register the thing.

- 8.3: Is 65537 considered a "low" e?  "Low" is too vague
there.

- 8.5: I'd prefer there was no none. The WG did discuss it
though, so I'll hold my nose.

- 8.6: suggesting a CA as a cure for oversized keys is odd, I
think those are separable things and e.g. TOFU might be just
as or more effective then X.509 here.

- Appendix A:  Thanks for that! It'll save folks a lot of
time. Might be better presented as a set of records and not
as a fixed width table.

- I think most of the secdir stuff has been handled (and
thanks for that) so I'm fine that the authors and AD are on
top of that.
Ted Lemon Former IESG member
No Objection
No Objection (for -33) Unknown

                            
Pete Resnick Former IESG member
(was Discuss) Abstain
Abstain (2014-12-02 for -37) Unknown
I've got some suggestions for improvements below, but overall I cannot support this document, so I'm entering an ABSTAIN. I don't think this WG has actually fulfilled its charter with regard to this document set. The WG was supposed to produce a "JSON syntax that can be used by applications to describe secure data objects". I don't believe it did that. Instead, it produced a compact serialization for a particular purpose and then backed into a JSON syntax. The compact serialization drove the effort and produced IMO a substandard JSON serialization. I don't believe that (reliable) interoperable implementations of the JSON serialization will be possible using this document set. However, there is at least rough consensus that these documents are usable as-is, and I don't think there's anything to be gained by holding them up any further.

I hope the WG will adopt some of the remaining comments, but my intention is not to discuss this any further. If you wish to address any of the comments and need clarification, I'm glad to help with that.

------

3.1/4.1/5.1/6.1: The implementation requirements do not belong in this document. They should be removed.

3.2ff: None of these algorithm requirements (using MUSTs) really belong in this document. These are requirements for any new crypto algorithm that should be documented elsewhere. They are not JOSE specific.

4.8: I think the MUST for UTF-8 is seriously problematic. Because different system normalize UTF-8 strings differently, there is no way that just saying "MUST use UTF-8" makes for any kind of interoperability unless you go into much more detail. I think you should either (a) just say that it is an octet string or (b) refer to PRECIS.

4.8.1.1: s/UTF-8/ASCII

5.2.2.1:

OLD
       Here we denote the number of octets in the MAC_KEY as
       MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN;

NEW
       MAC_KEY_LEN is the number of octets in MAC_KEY and ENC_KEY_LEN is
       the number of octets in ENC_KEY.

OLD
       The number of octets in the input key K MUST be the sum of
       MAC_KEY_LEN and ENC_KEY_LEN.

NEW
       The number of octets in the input key K MUST be the sum of
       MAC_KEY_LEN and ENC_KEY_LEN.

The following is completely redundant:

       When generating the secondary keys
       from K, MAC_KEY and ENC_KEY MUST NOT overlap.