Good point. Yes, the current language already allows for extensibility, though not as general as others have advocated here.
On Fri, Jul 27, 2012 at 1:57 PM, Mike Jones <[email protected]>wrote: > I just spoke with Tony, and a clarifying point is worth making. He’s > saying that there will have to be additional header parameters at some > point for some use cases. He’s using additional ECC modes as an example > that might require them. He’s not saying that those header parameters, if > present, do not have to be understood.**** > > ** ** > > Put another way, he’s saying that extensions are inevitable and having no > extensibility model is not an option. Fortunately, we already have the > JSON Web Signature and Encryption Header Parameters Registry > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-04#section-7.1.1that > provides just such an extensibility point. > **** > > ** ** > > -- Mike*** > * > > ** ** > > *From:* Anthony Nadalin > *Sent:* Friday, July 27, 2012 1:49 PM > *To:* [email protected]; Mike Jones; [email protected]; > [email protected] > *Cc:* [email protected] > *Subject:* RE: [jose] MUST understand ALL header fields**** > > ** ** > > 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**** > -- --Breno
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
