Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-02.txt

From: [email-masked]
Date: Sat, 12 May 2012 16:41:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Javascript Object Signing and Encryption Working Group of the IETF.

	Title           : JSON Web Encryption (JWE)
	Author(s)       : Michael B. Jones
                          Eric Rescorla
                          Joe Hildebrand
	Filename        : draft-ietf-jose-json-web-encryption-02.txt
	Pages           : 24
	Date            : 2012-05-12

   JSON Web Encryption (JWE) is a means of representing encrypted
   content using JSON data structures.  Cryptographic algorithms and
   identifiers used with this specification are enumerated in the
   separate JSON Web Algorithms (JWA) specification.  Related digital
   signature and MAC capabilities are described in the separate JSON Web
   Signature (JWS) specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-02.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/

---

From: Sean Turner <[email-masked]>
Date: Mon, 28 May 2012 13:36:03 -0400

Here are some comments:

1) s2 & Requirements Language: The RFC editor is going to move the 
Requirements Language section later on so you might as well save them 
the trouble and just make it part of s2.

2) General: Don't you also need to point to the JWK spec in the 
abstract/intro for the key formats?  I guess I could go either way on 
this one.

3) s3: This is probably a style thing but I'd move the example after 
discussing the actual format.  It'll stop people from asking for this or 
that to be defined/referenced in the example section.

3) throughout: r/RSA-PKCS1_1.5/RSAES-PKCS1-1.5

4) s3.1/3.2: If we up the IV to 128 in json-web-algorithms, then this 
should be updated too.

5) s3.1: Is this a JWK Set or just a JWK?

6) s4: Contains the following:

  The Header Parameter Names within this object
  MUST be unique; JWEs with duplicate Header Parameter Names MUST be
  rejected.

I'd prefer to see that if this is actually enforceable (not sure it is) 
that an error gets thrown or the message gets rejected.

7) s4: How are the different types of parameters (res,pub,priv) named? 
Is there going to be some kind of designator in front of them?  If so, 
then I would definitely try to get an early review from some Apps folks 
because they're deprecating X-.

8) s4.1.1-s4.1.3: Same concerns about the registry setup as the other docs.

9) s4.1.1/s4.1.2: contains the following:

  The processing of the "alg/enc" header parameter requires that
  the value MUST be one that is both supported ..

Not sure what this means?

10) s4.1.?: Isn't there a requirement that either the key be included or 
a reference to the key be included?  Which one is MTI?

11) s4.1.7/s4.1.9: add normative reference to [RFC3986] for absolute 
URL.  And I think they call it a URI.

12) s4.1.8: Add reference to RFC5280: X.509 public key certificate or 
certificate chain [RFC5280]

13) s4.1.8: Ack! PEM.  Replace the reference to PEM with RFC 4648 and 
pointer to s4.

14) s4.1.8: I think you need to specify what first means.  Network byte 
order.

15) s4.1.11: r/base64-encoded (not base64url encoded)/base64-encoded, 
[RFC4648] Section 4 (not base64url encoded),

16) s4.1.11: let's just do DER: r/DER/BER/DER [X.690]

and add the following normative reference

   [X.690]  ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
            Information technology - ASN.1 encoding rules:
            Specification of Basic Encoding Rules (BER), Canonical
            Encoding Rules (CER) and Distinguished Encoding Rules
            (DER).

or: r/DER/BER PKIX certificate value/PKIX certificate value [RFC5280].

17) s7: Same concern I had in web-algorithms about OtherInfo being zero.

18) s7: If the kid and thumbprints are not supposed to be generated in a 
way to make them unique it's worth pointing this out in s7.  I might 
suggest something along the lines of:

   While hash algorithms provide collision resistance, this property
   is not needed for key identifiers or thumbprints.

19) s11.1: encoding considerations: isn't it base64url encoded?
            applications that use this media type: is it just OpenId 
connect or can this be generalized a bit?

spt