I don't know that the two ECC algorithms in JWA should support all possible ECC permutations.
If some new exotic combination needs to be supported a new algorithm name is added to JWA and both sides need to support it. Only understanding some of the ECC parameters could cause significant security failures. John B. On 2012-07-27, at 1:49 PM, Anthony Nadalin wrote: > So not sure this is at all possible for all the permutations that there might > be for all the parameters that one could specify for ECC > > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Friday, July 27, 2012 1:30 AM > To: Mike Jones; [email protected]; [email protected] > Cc: [email protected] > Subject: Re: [jose] MUST understand ALL header fields > > I agree with Breno’s analysis and support to ditch extensibility. Instead the > JWA must specify which alg/enc/int algorithm needs what mandatory parameters. > JWTs with a header with unknown parameters must be rejected. > > If somebody needs to new algorithms or new extra parameters they should write > a new draft. With all the interoperability issues that this implies… > If later somebody finds that one alg/enc/int from this spec is not secure > enough then the implementations need to decide whether they can take the risk > to continue to support it or pull it. My hope is that our current set of > specified algs/encs/ints is broad enough that a secure alternative exists if > this ever happens. > > The cost for extensibility is too high and there is a real danger that this > WG gets stuck like the OAUTH-WG for years. > > Let’s specify something that is useful now. > > Axel > > > > From: [email protected] [mailto:[email protected]] On Behalf Of Mike > Jones > Sent: Thursday, July 26, 2012 7:39 PM > To: Breno de Medeiros; Manger, James H > Cc: [email protected] > Subject: Re: [jose] MUST understand ALL header fields > > I agree with this analysis. If there’s an explicit way defined to indicate > which additional header parameters may be ignored, that would be OK. > Allowing ignore-by-default would be a recipe for disaster. > > -- Mike > > From: [email protected] [mailto:[email protected]] On Behalf Of Breno > de Medeiros > Sent: Thursday, July 26, 2012 10:35 AM > To: Manger, James H > Cc: [email protected] > Subject: Re: [jose] MUST understand ALL header fields > > Put it another way: If we want the JWT security header to be extensible we > need to define an explicit extension mechanism. It is NOT sufficient to say > MUST ignore non-understood fields in the header. This will make it impossible > to write secure implementations of validation libraries in practice. > > An extension mechanism would define: > > - How to bundle fields of an extension as a single object. > - How to indicate that this object is an extension, and whether the extension > is critical (can't be safely ignored) or not. > > You can't get extensibility cheaply in a security spec. A choice is needed > whether to support extensibility explicitly (at the expense of significant > increase of spec complexity, since a lot will have to be spelled out right > now) or not. Giving up clear security semantics to get cheap extensibility is > not an acceptable 3rd option. > > > > On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros <[email protected]> wrote: > > > > On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H > <[email protected]> wrote: > Breno, > > >> How about stapling an OCSP response to a JOSE message? > > That's a more compelling use case -- it's security-specific but only adds > > to the security validation context. > > > How about the signing time? > > How about some DNS records with DANE and DNSSEC info giving evidence that the > public key is associated with a domain? > > How about a blob of data related to Sovereign Keys, or Perspectives, or > Convergence, or some other proposal to bolster PKI? > > How about a domain_parameter_seed so you can verify that the common domain > parameters (eg p & q in DSA) were not chosen to have special properties? > > How about data to allow you to validate a public key (eg co-factor for EC? > Something complicated for RSA?)? > > How about a timestamp from a timestamp service? > > > I’m not sure which, where, or when an item like the ones mentioned above will > be needed. I am confident that someone will need some items like these. When > that happens they should have a choice about whether including the item needs > to break interop with all existing receivers. A mode field that MUST be > understood (eg “t”:”sig”) coupled with MUST ignored any unrecognized > parameters keeps our future choices open. > > That's not good enough for a security spec. If fields are added and not all > MUST be understood, then we need explicit syntax about what fields are to be > ignored when not understood. E.g., in X509 certificates, extensions (while > optional) have the ability to declare themselves critical, so that > implementations that don't understand that extension MUST reject the > certificate as invalid. > > > > > However declaring that any header you don't understand could be optional is > > a far worse balance on the extensibility versus simplicity spectrum (where > > simplicity here is a stand-in for security, interoperability, etc.) > > I’m not sure I understand this “simplicity” argument. Ignoring unrecognized > fields is the simplest implementation choice. Is your idea that if you > tightly constrain extensibility (by making them MUST understand) then > messages will not accumulate as many “enhancements” of dubious value. That > is, over time a MUST ignore rule allows messages to get more complex (and > hence less secure/interoperable). Do you want “MUST understand” to strongly > discourage people misusing the header to carry content metadata, for instance? > > Inevitably, a field will be added that shouldn't be ignored because it > modifies the meaning of some other widely understood header entry, followed > by usual antics and general perplexity. > > > > -- > James Manger > > From: Breno de Medeiros [mailto:[email protected]] > Sent: Thursday, 26 July 2012 1:12 PM > To: Manger, James H > Cc: [email protected] > > Subject: Re: [jose] MUST understand ALL header fields > > That's a more compelling use case -- it's security-specific but only adds to > the security validation context. > > There may be a case to define optional entries in the JWT header. However > declaring that any header you don't understand could be optional is a far > worse balance on the extensibility versus simplicity spectrum (where > simplicity here is a stand-in for security, interoperability, etc.) So I am > not convinced that losing the ability to declare OCSP bindings in JWTs > justifies dropping the MUST language. If there is rough consensus that > defining optional security fields in the header is prudent from the viewpoint > of future spec extensibility then we should devise some simple way to declare > a JWT header field optional and exempt _only_those_ from the MUST fail when > not understanding clause. Changing the default behavior even to SHOULD > appears to me to sacrifice too much on the altar of extensibility. > > > On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H > <[email protected]> wrote: > How about stapling an OCSP response to a JOSE message? > > Why should that be "MUST understand"? > > -- > James Manger > > > > -- > --Breno > > > > -- > --Breno > > > > -- > --Breno > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
