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]<mailto:[email protected]>> wrote:
On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H
<[email protected]<mailto:[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]<mailto:[email protected]>]
Sent: Thursday, 26 July 2012 1:12 PM
To: Manger, James H
Cc: [email protected]<mailto:[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]<mailto:[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
