James, Could you say what you mean by an "unprotected JOSE message"? A JOSE message is nothing more than (1) content, and (2) crypto processing instructions. If you're not doing any crypto, you're left with the content, so why do you need the JOSE wrapper?
--Richard On Thu, Aug 1, 2013 at 5:39 PM, Manger, James H < [email protected]> wrote: > Supporting unprotected JOSE messages is a useful option. > > Pretending an unprotected message is a subclass of a signed message is the > problem. It is a cute, but unnecessary, hack. It encourages libraries and > APIs to hide the *crucial* distinction between unprotected and signed > messages (eg by represented both with a single JWS class). > > An unprotected JOSE message needs to be a distinct type (distinct from JWE > and JWS) that consists of a header and payload (no extra dot or empty > signature field). > > We should not distinguish some classes of JOSE message by dot-count, > others looking up the "alg" value in a table, and others by the presence or > absence of "enc". We need one mechanism. We desperately need a proper type > field, but without that we can try to fudge our way through by overloading > the "alg" field. > > "alg":"none" can identify an unprotected JOSE message. > > Unprotected JOSE messages need to be defined in JOSE, not JWT. > > > The organization of JOSE specs is causing real grief due to the lack of > the concept of a JOSE message. Instead we only have JWS and JWE messages. A > lot of text is duplicated between JWS and JWE; a lots of text is > similar-but-not-quite-identical between JWS and JWE. Things have to be > contorted to fit JWS or JWE: Unprotected messages treated as signed; MACs > and asymmetric signatures treated as the same; symmetric key establishment > working for symmetric encryption but not for symmetric MACs... > > > > Applications always have to make a security decision about whether an > algorithm is acceptable in its context or not. > > Deciding if, say, SHA-1 or SHA-256 is acceptable is very different than > deciding if signed, encrypted, or unprotected is acceptable. Theoretically, > apps make both choices, but in practice the former is often left to the > library or O/S. The former should be a matter of configuring a list of > strings; the latter requires explicit code support. > > > Minimal suggestion: > Add a new section to the JWS spec (eg 7. Unprotected message); consists of > header and payload; header contains "alg":"none". > > Sensible suggestion: > A JOSE spec; a proper type field; separate sections for unprotected > messages, MAC messages, and asymmetrically-signed messages; could leave the > encryption (and key exchange) message in a separate spec. > > -- > James Manger >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
