I won't pretend to know what the *right* thing to do is. But I do think James makes a valid point about the temporal interoperability problems that will arise if/when new parameters get introduced down the road.
On Sun, Jul 8, 2012 at 6:42 PM, Manger, James H < [email protected]> wrote: > Mike, > > >> Implementations MUST understand the entire contents of the > >> header; otherwise, the {JWS|JWE} MUST be rejected. > >> > >> We should drop this restriction. > > Mike replied: > > Since this is a security protocol, the way I see it, use of a not- > > understood parameter SHOULD break implementations if they’re not > > prepared to handle them (or at least them cause them to reject the > > input). For example, if we hypothetically added an audience > > restriction parameter, ignoring it would be a security error. (The > > need for audience restriction is being heavily discussed in the OAuth > > WG right now, and real exploits that have occurred for the lack of it, > > so this example is real and fresh on my mind.) If not understood, a > > token containing an audience restriction MUST be rejected. > > > Consider an ecosystem with hundreds of servers and thousands of client > apps all using a protocol involving JOSE messages that has been operating > for a few years. A researcher finds a vulnerability in the protocol and > responsibly discloses it to selected servers. The fix is to add an audience > restriction parameter "aud". > > What should a server do? > > If it adds the "aud" parameter immediately, every (compliant) client app > will immediately break. The outage will last until every app is updated, > which will takes weeks, months…? Total system shutdown to fix a flaw that > is currently theoretical… heads will role. > > If a server announces that it will add the "aud" parameter in, say, 3 > months to give time for app updates then it has just disclosed a > vulnerability and given attackers a 3 month window to exploit it. Many will > clamour for an immediate fix; many will say they need longer to fix apps; > it will still break for many users in 3 months… heads will role. > > On the other hand, if the spec says unknown parameters MUST be ignored > then the server can immediately add the "aud" parameter, and immediately > tell client apps to start supporting it. Each app is protected as soon as > it adds support. > If actual exploits need to be stopped the server can still shutdown the > whole system, or just selected client apps, or selected users. > > > X.509 certificates are an interesting example for comparison. Certs are > security-related, just like JOSE messages. Certs allow unrecognised > additions (eg non-critical extensions). These have been very widely used to > deploy new functionality. > > The X.509 spec (or at least its IETF profile) has one item that MUST be > understood if added: the name-constraints extension. This extension should > be really useful for security. However, because adding it in the > spec-compliant MUST-understand manner will break some clients, it has > barely been deployed for over a decade. > > > Lets drop the "MUST understand everything" requirement. > > -- > 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
