Dear list, Believe or not but there is a new multi-party IETF effort in the workings for dealing with "clear text" versions of JWS and JWE. Our BOF request was though turned down due to lack of published drafts and "customers" so issues will have to go through the mailing list only.
The goal is reusing as much as possible of the existing specifications, essentially limiting the work to repackaging. However, it turned out that I wasn't fully up-to-date on the JOSE concept "Key Guessing": https://tools.ietf.org/html/rfc7515#appendix-D As far I can tell they only way you would ever need to do "Key Guessing" as described in appendix-D is if you have a scheme where the sender doesn't inform the receiver which key it actually used which sounds like a poor idea as well as highly unlikely to be used anywhere in practice. Therefore I didn't bother too much with that until I had implemented support for JKU where the sender supplies a URL to a set of keys for the receiver to try out. That is, "Key Guessing" is not only a possibility, it is an intrinsic part of the JOSE specifications. So the question simply boils down to: Should derived standards-to-be, inherit obvious design flaws as well? IMO, they should not. JKU could be redefined to point to a single JWK, removing the need for "Key Guessing" altogether. Yes, there are "workarounds" like requiring additional key identification properties... thanx, Anders _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
