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

From: [email-masked]
Date: Sat, 12 May 2012 16:39:53 -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 Signature (JWS)
	Author(s)       : Michael B. Jones
                          John Bradley
                          Nat Sakimura
	Filename        : draft-ietf-jose-json-web-signature-02.txt
	Pages           : 30
	Date            : 2012-05-12

   JSON Web Signature (JWS) is a means of representing content secured
   with digital signatures or Message Authentication Codes (MACs) using
   JSON data structures.  Cryptographic algorithms and identifiers used
   with this specification are enumerated in the separate JSON Web
   Algorithms (JWA) specification.  Related encryption capabilities are
   described in the separate JSON Web Encryption (JWE) specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-signature-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-signature-02.txt

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

---

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

Here are some comments on the draft (a lot of these are duplicates from 
web-encryption):

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) s3: This is probably a style thing, but I think it's probably better 
to talk about the structure first and then provide an example.  It's 
just going to make everybody ask you to define/explain x in that section.

3) 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.

Also just checking that this means you can only send one signature type 
per object.  That is you can't send one JSON object that is signed with 
both RSA and ECDSA?

4) 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-.

5) s4.1/4.1.1: Same concerns about the registry setup as the other docs.

6) s4.1.2/s4.1.4: Add normative reference to [RFC3986] for absolute URL. 
  And I think they call it a URI.

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

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

9) s4.1.6: 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].

10) 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.

11) 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