> Done.
> checkHeader function is called in all encrypt, decrypt, sign and verify
> functions now.
That was pretty quick, but also petty awful.
If an app using your library now receives a JWE with, say, a "creationTime"
field (suggested at the IETF meeting I think) it will fail unnecessarily. The
app needs to modify the *library source code* and recompile to continue.
checkHeader accepts a "zip" field, but I don't think the jsoncrypto code
implements this field (same for "kdf", "typ" etc).
checkHeader accepts an "epk" field when "alg" is "RSA-OAEP" even though it
cannot understand such a combination because it hasn't been defined.
checkHeader accepts "kdf" even if its value is an object (eg "kdf":{"xyz":...})
instead of having a string value. Again, who knows what that might mean?
You have introduced some more failure modes. There are still plenty of JOSE
message that your code will accept despite not understanding. Your library was
more useful without checkHeader().
P.S. Slightly better code might be:
if (!knownKeysSet.containsAll(jweHeader.keys()) throw SomeException(...)
--
James Manger
> public static void checkHeader(JSONObject jweHeader) throws
> Exception {
> @SuppressWarnings("rawtypes")
> Iterator iter = jweHeader.keys();
> while (iter.hasNext()) {
> String key = (String) iter.next();
> if ("alg".equals(key)) continue;
> if ("enc".equals(key)) continue;
> if ("int".equals(key)) continue;
> if ("kdf".equals(key)) continue;
> if ("iv".equals(key)) continue;
> if ("epk".equals(key)) continue;
> if ("zip".equals(key)) continue;
> if ("jku".equals(key)) continue;
> if ("jwk".equals(key)) continue;
> if ("x5u".equals(key)) continue;
> if ("x5t".equals(key)) continue;
> if ("x5c".equals(key)) continue;
> if ("kid".equals(key)) continue;
> if ("typ".equals(key)) continue;
> if ("cty".equals(key)) continue;
> if ("jku".equals(key)) continue;
> if ("jwk".equals(key)) continue;
> throw new Exception("unknown key in header: " +
> key);
> }
> }
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Nennker, Axel
> Sent: Thursday, August 02, 2012 6:56 AM
> To: [email protected]; [email protected]
> Subject: Re: [jose] implementing JOSE in Java: jsoncrypto
>
> I wanted to wait a little more before implementing that because the
> discussion here about it seems to bring too many changes to the code.
> There are other things too that need to be improved. But jsoncrypto
> implements all proposed alg and enc values other than none (which I
> find strange) and dir (which I had implemented first but the group at
> that time seemed to think that this might make it too easy for
> developers to use the same cek too often (always)).
>
> -----Original Message-----
> From: Manger, James H [mailto:[email protected]]
> Sent: Thursday, August 02, 2012 3:26 AM
> To: Nennker, Axel; [email protected]
> Subject: RE: implementing JOSE in Java: jsoncrypto
>
> Axel,
>
> > I moved my JOSE implementation out of my openinfocard project into a
> > new repository:
> > https://code.google.com/p/jsoncrypto/
>
> It is good to see another JOSE implementation.
>
> Does jsoncrypto implement the "MUST understand everything" rule?
>
> [JWE-05, section 4]
> Implementations MUST understand the entire contents of the
> header; otherwise, the JWE MUST be rejected.
>
> [JWE-05, section 6]
> 4. The resulting JWE Header MUST be validated to only include
> parameters and values whose syntax and semantics are both
> understood and supported.
>
> Jsoncrypto does not appear to implement this rule. It appears to take
> the obvious approach of looking in the header for the fields it needs -
> - and ignoring anything else that might be there.
>
> [Regardless of any possible merit in a "MUST understand everything"
> rule, the fact that it will often not be implemented seems like a
> really good reason to drop the rule so the spec reflects reality.]
>
> --
> James Manger
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
