I agree ignore by default is going to cause too many problems down the road.
I am not against having a way to indicate non critical as long as the default is critical put in x.509 terminology. John B. On 2012-07-26, at 10:35 AM, Breno de Medeiros wrote: > 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
