Hi James, Yes, the three JWS validators (MAC/RSA/EC) that we have in the crypto algs package are intended to be extended. They do just the basic signature validation and accept only the "alg", "typ" and "cty" parameters. They could serve as a starting point for creating more complex validators, e.g. a validator that uses the "kid" to look up the MAC key in a database.
We will probably add extended validators with key lookup support as we progress into our OIDC server implementation (the part which deals with signed OpenID request objects). Inside the crypto package there's also a hidden JWSHeaderFilter implementation, we'll probably make it public, as an aid to other developers who choose to write their own extended validators. https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/bef49c225aae/src/main/java/com/nimbusds/jose/crypto/DefaultJWSHeaderFilter.java?at=master Vladimir -- Vladimir Dzhuvinov : www.NimbusDS.com : [email protected] -------- Original Message -------- Subject: Re: [jose] Header criticality -- hidden consensus? From: "Manger, James H" <[email protected]> Date: Sun, February 10, 2013 10:14 pm To: Vladimir Dzhuvinov / NimbusDS <[email protected]>, "[email protected]" <[email protected]> Vladimir, It is useful to see actual APIs and code trying to implement this MUST-understand-everything rule. I can't quite see how your API allows a caller to indicate that is understands a new header parameter. Your HeaderFilter lets the caller *see* which field names the library "understands". JWSHeaderFilter goes further and allows the caller to *set* the accepted algorithms. I couldn't find, say, setAcceptedParameters(...). Perhaps you are supposed to extend, say, MACVerifier with your own class that lists an extra field? -- James Manger > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Vladimir Dzhuvinov / NimbusDS > Sent: Saturday, 9 February 2013 5:35 PM > To: Richard Barnes; [email protected] > Subject: Re: [jose] Header criticality -- hidden consensus? > > Hi Richard, > > I understand your concern. With some bit of interface engineering we > managed to have this requirement covered at library level, by allowing > client apps to specify additional accepted parameters. If the JOSE > library encounters a header with an unexpected name, it will mark the > message as bad on the spot, so it won't be passed on to the app code at > all. > > You can take a look at the interface Javadocs here: > > http://nimbusds.com/files/jose- > jwt/javadoc/com/nimbusds/jose/HeaderFilter.html > > And the actual code at the Git repo: > > https://bitbucket.org/nimbusds/nimbus-jose- > jwt/src/bef49c225aae194b6c40a376aee36b9af37a5da6/src/main/java/com/nimb > usds/jose/HeaderFilter.java?at=master > > > > What's more, this interface allows even certain standard headers from > the JWS/JWE spec to not be denied (say if the client app doesn't want > to > accept X509 cert URLs, etc). > > > I hope this helps, > > Vladimir > > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : [email protected] > > > > > -------- Original Message -------- > Subject: [jose] Header criticality -- hidden consensus? > From: Richard Barnes <[email protected]> > Date: Fri, February 08, 2013 11:11 pm > To: "[email protected]" <[email protected]> > > We're 24 votes into the header criticality poll, so I thought I would > go > ahead and take a look at how the results are shaping up. My initial > tabulation is below. The result on the FIRST POLL (the main one) is as > follows: > > No: 10 > Yes: 14 > > > What I find striking, however, is that every single person that voted > "Yes" on the FIRST POLL also voted "Yes" on the SECOND POLL. So nobody > who thinks that all headers should be critical thinks that a JOSE > library should actually be required to enforce this constraint. And > that means that enforcing that all headers are supported cannot be a > MUST according to RFC 2119. > > > So I wonder if there's consensus to remove the following text from JWE > and JWS: > -----BEGIN-JWE----- > 4. The resulting JWE Header MUST be validated to only include > parameters and values whose syntax and semantics are both > understood and supported. > > -----END-JWE----- > -----BEGIN-JWS----- > 4. The resulting JWS Header MUST be validated to only include > parameters and values whose syntax and semantics are both > understood and supported. > > -----END-JWS----- > > > Otherewise, a JOSE library conforming to these specifications would be > REQUIRED (a synonym to MUST in 2119) to reject a JWE/JWS that contains > an unknown header, contradicting all those "Yes" votes on the SECOND > POLL. > > > --Richard > > > > > > > -----BEGIN-Tabulation----- > 1 2 3 Name: > N - - Bradley > N - - Ito > N N A Yee > N N B Barnes > N N B Rescorla > N N C Manger > N N C Octman > N Y A Fletcher > N Y A Miller > N Y A Sakimura > Y Y - D'Agostino > Y Y A Biering > Y Y A Brault > Y Y A Hedberg > Y Y A Jay > Y Y A Jones > Y Y A Marais > Y Y A Nadalin > Y Y A Nara > Y Y A Nennker > Y Y A Solberg > Y Y B Hardt > Y Y B Medeiros > Y Y C Matake > Y Y C Mishra > > -----END-Tabulation----- > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
