On Thu, Aug 1, 2013 at 6:04 PM, Manger, James H < [email protected]> wrote:
> > 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! > If you base64 the content, it will never look like JOSE. It won't look like a compact JOSE object, since it's a base64 string with the wrong number of components (1 instead of 3/5). It won't look like a JSON JOSE object, because it won't be JSON. So, I actually proposed some syntax on this on the OAuth list. The proposal allows a header, but the concept is the same. <http://www.ietf.org/mail-archive/web/oauth/current/msg11857.html> The important thing here is that however the unprotected stuff is represented, it must have the property that if I feed it into a JOSE library, the library will say "This is not a JWS or JWE", not "This is a valid JWS". --Richard > > -- > 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
