> James, > > Could you say what you mean by an "unprotected JOSE message"?
A JOSE message that offers no cryptographic protection to its payload. > 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? To distinguish content from content+crypto. If a field in a protocol usually needs integrity, authenticity, or confidentiality protection, but in some circumstances those protections are unnecessary (eg they come from a lower layer), then the protocol should define its value to be a JOSE message. You need to be able to indicate whether a given field value is content+crypto or content. You cannot define the field as holding: a JOSE message (compact serialization), or raw string content. Because the raw content might look like a JOSE message! -- James Manger > > --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
