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

From: Mike Jones <[email-masked]>
Date: Fri, 6 Jul 2012 18:00:50 +0000

Thanks once again for the detailed read, Sean.  Responses inline...

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 10:36 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-02.txt

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.

Done

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.

Done

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.

Yes, it's a style thing.  In my experience, developers grok things quicker if they have an example to start their brains down the right paths.  Hence, the current order.

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

Replaced with RSAES-PKCS1-V1_5

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

Examples replaced with real ones :-)

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

It was a set, but it's no longer in the example.

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.

I agree that this needs to be enforced.  Section 2.2 of http://tools.ietf.org/html/rfc4627 says "The names within an object SHOULD be unique."  So this should be enforced by conforming parsers.  I'd be interested in data saying that parsers exist that are non-conforming to this RFC 4627 "SHOULD".  If so, we should add appropriate warnings to the Security Considerations section.

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

All the current reserved parameters have names not containing a collision resistant namespace and are reserved in the IANA registry.  Public names either must contain a collision resistant namespace, such as a URL, OID, or GUID, or be registered.  Private names are the wild west, to be used only between consenting adults.

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

See my response to the related comment in the JWA doc

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?

Hopefully clarified.  Now says:  The algorithm specified by the "alg" value MUST be supported by the implementation and there MUST be a key for use with that algorithm associated with the intended recipient or the JWE MUST be rejected.

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?

Neither.  They could have been exchanged out of band.

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

Done

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

Done

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

The formulation you suggest is incomplete because it doesn't include the -----BEGIN CERTIFICATE----- /  -----END CERTIFICATE----- annotations that PEM uses to delimit the certificates in the certificate chain.  Are you OK leaving this as-is, or do you want to suggest different wording?  See the example at http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-B that's intended to make the format crystal clear.

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

I'm confused about this one.  Are you talking about the "first certificate" in 4.1.9?  I don't think network byte order applies here.

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

Done

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

Done

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

Done

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

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

Essentially the same response, since we're requiring generation of a random Content Master Key (CMK).  Note that we are using Label values of "Encryption" and "Integrity" to differentiate these cases.

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.

I'm confused by this comment as well.  Section 7 (Key Derivation) doesn't have much to do with the Key ID or X.509 Thumbprint parameters.  That being said, I did clarify that the "kid" value need not be unique.

19) s11.1: encoding considerations: isn't it base64url encoded?

Added:

                                Encoding considerations: JWE values are encoded as a

                                series of base64url encoded values (some of which may be the

                                empty string) separated by period ('.') characters

            applications that use this media type: is it just OpenId connect or can this be generalized a bit?

Now says "OpenID Connect and other applications using encrypted JWTs".  To be clear, the JWS spec stabilized first and so JWS adoption is ahead of JWE adoption at the moment.  More applications to come... :-)

spt

_______________________________________________

jose mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/jose