Re: [jose] Header criticality -- hidden consensus?

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 : vladimir@nimbusds.com

-------- Original Message --------
Subject: Re: [jose] Header criticality -- hidden consensus?
From: "Manger, James H" <James.H.Manger@team.telstra.com>
Date: Sun, February 10, 2013 10:14 pm
To: Vladimir Dzhuvinov / NimbusDS <vladimir@nimbusds.com>,
"jose@ietf.org" <jose@ietf.org>

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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Vladimir Dzhuvinov / NimbusDS
> Sent: Saturday, 9 February 2013 5:35 PM
> To: Richard Barnes; jose@ietf.org
> 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 : vladimir@nimbusds.com
> 
> 
> 
> 
> -------- Original Message --------
> Subject: [jose] Header criticality -- hidden consensus?
> From: Richard Barnes <rlb@ipv.sx>
> Date: Fri, February 08, 2013 11:11 pm
> To: "jose@ietf.org" <jose@ietf.org>
> 
> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose