Subject: Re: [jose] MUST understand ALL header fields

From: "Manger, James H" <[email-masked]>
Date: Thu, 26 Jul 2012 12:38:51 +1000

How about stapling an OCSP response to a JOSE message?

Why should that be "MUST understand"?

--
James Manger

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 25 Jul 2012 20:11:59 -0700

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.

-- 
--Breno

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 26 Jul 2012 15:28:33 +1000

Breno,

> 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.

> 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?

--
James Manger

From: Breno de Medeiros [mailto:[email-masked]]
Sent: Thursday, 26 July 2012 1:12 PM
To: Manger, James H
Cc: [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
How about stapling an OCSP response to a JOSE message?

--
James Manger

--
--Breno

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 26 Jul 2012 09:16:52 -0700

On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H <
[email-masked]> 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-masked]]
> *Sent:* Thursday, 26 July 2012 1:12 PM
> *To:* Manger, James H
> *Cc:* [email-masked]
>
> *Subject:* Re: [jose] MUST understand ALL header fields****
>
> ** **
>
> to the security validation context.****
>
> ** **
>
> extensibility. ****
> ** **
> [email-masked]> wrote:****
>
> James Manger****
> ****
> ** **
> --Breno****

-- 
--Breno

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 26 Jul 2012 10:35:26 -0700

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-masked]> wrote:

>> 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?)?****
>>
>> ** **
>>
> 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
>> > 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.)****
>>
>> ** **
>>

-- 
--Breno

---

From: Mike Jones <[email-masked]>
Date: Thu, 26 Jul 2012 17:38:42 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Breno de Medeiros
Sent: Thursday, July 26, 2012 10:35 AM
To: Manger, James H
Cc: [email-masked]
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.

- 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-masked]<mailto:[email-masked]>> wrote:

On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H <[email-masked]<mailto:[email-masked]>> wrote:
Breno,

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, in…

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-masked]<mailto:[email-masked]>]
Sent: Thursday, 26 July 2012 1:12 PM
To: Manger, James H
Cc: [email-masked]<mailto:[email-masked]>

--
James Manger

--
--Breno

--
--Breno

--
--Breno

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 27 Jul 2012 13:44:44 +1000

Breno,

> 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.

Is there a good example of where this has occurred? That might help us reach a common understanding.

> - How to indicate that this object is an extension, and whether the extension is critical (can't be safely ignored) or not.

If we support extensibility with per-extension criticality flags, wouldn't it be almost as inevitable that an extension will be added that shouldn't be ignored but is marked non-critical to not break interop? Or do you think people will "do the right thing (not the easy thing)" with criticality flags?

P.S. If the 7 header parameters that are defined in JWS (draft 04) but never used in its examples were all defined as "extensions", would any be critical? jku? jwk? x5u? x5t? x5c? kid? cty? I doubt it.

> 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.

CMS [RFC5652] and its AEAD mode [RFC5083] both have authAttrs fields that can hold arbitrary attributes. I see no mention in those specs of a "MUST understand" rule for attributes in those fields. I haven't heard that that has made it impossible to write secure implementations of validation libraries.

Is it OK for CMS because there are dedicated fields for the primary items (eg signatureAlgorithm), separate from the authAttrs bucket? I don't think that can be the difference.

Lots of CMS attributes have been defined by different parties. For instance, CMS Advanced Electronic Signatures (CAdES) [RFC5126] defines or mentions dozens (signer-location, content-hints, signing-certificate, commitment-type, …). Some MUST be present in a CAdES message, others are OPTIONAL. From a quick glance I didn't see a statement about which MUST be understood.

--
James Manger

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 26 Jul 2012 21:35:49 -0700

<personal>

I don't know if it is a good idea, but James has already given you a simple
way of tagging fields that cannot be ignored - just append a '!' character.
I guess you could just as easily append a '?' to those that could be
ignored.

That being said, I don't know that having optional mandatoriness is a good
or a bad thing.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Thursday, July 26, 2012 10:39 AM
To: Breno de Medeiros; Manger, James H
Cc: [email-masked]
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-masked] [mailto:[email-masked]] On Behalf Of
Breno de Medeiros
Sent: Thursday, July 26, 2012 10:35 AM
To: Manger, James H
Cc: [email-masked]
Subject: Re: [jose] MUST understand ALL header fields

 

 

On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H
<[email-masked]> wrote:

Breno,

 

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?)?

 

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.

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?

 

--

James Manger

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-masked]> wrote:

--
James Manger

-- 
--Breno

-- 
--Breno

-- 
--Breno

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 26 Jul 2012 21:41:45 -0700

<personal>

> -----Original Message-----
> Manger, James H
> Sent: Thursday, July 26, 2012 8:45 PM
> To: Breno de Medeiros; [email-masked]
> modifies the meaning of some other widely understood header entry,
> followed by usual antics and general perplexity.
> 
> If we support extensibility with per-extension criticality flags, wouldn't it be
> almost as inevitable that an extension will be added that shouldn't be
> ignored but is marked non-critical to not break interop? Or do you think
> people will "do the right thing (not the easy thing)" with criticality flags?

Anyone who believes this to be a true statement is more than welcome to read the current firestorm about name constraints on the PKIX mailing list.  They were defined and said to be critical when the first draft (RFC2459) came out in 1999 and people are saying that they need to make it non-critical because too many people did not implement it.  The JOSE documents are better in that there are not as many "extensions" defined.  But the history is still there.

Jim

> 
> P.S. If the 7 header parameters that are defined in JWS (draft 04) but never
> used in its examples were all defined as "extensions", would any be critical?
> jku? jwk? x5u? x5t? x5c? kid? cty? I doubt it.
> 
> 
> > 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.
> 
> CMS [RFC5652] and its AEAD mode [RFC5083] both have authAttrs fields that
> can hold arbitrary attributes. I see no mention in those specs of a "MUST
> understand" rule for attributes in those fields. I haven't heard that that has
> made it impossible to write secure implementations of validation libraries.
> 
> Is it OK for CMS because there are dedicated fields for the primary items (eg
> signatureAlgorithm), separate from the authAttrs bucket? I don't think that
> can be the difference.
> 
> Lots of CMS attributes have been defined by different parties. For instance,
> CMS Advanced Electronic Signatures (CAdES) [RFC5126] defines or mentions
> dozens (signer-location, content-hints, signing-certificate, commitment-type,
> �). Some MUST be present in a CAdES message, others are OPTIONAL. From
> a quick glance I didn't see a statement about which MUST be understood.
> 
> 
> --
> James Manger
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 27 Jul 2012 17:20:23 +1000

Proposal:

Define a header field named "!".
Its value is a string.
A sender MUST include a "!" field in every JOSE message.
A receiver MUST reject a JOSE message if the value of the "!" field is not recognized.
The value of the "!" field defines the meaning of the message, including which other fields MUST be understood to correctly interpret the message in a fail-safe manner. Any other fields that the receiver does not recognize MUST be ignored.
It is RECOMMENDED that receivers log the name of an unrecognized field the first time they see it as it is likely to provide a hint as to how the receiver could be improved (including being made more secure).

By making the "!" field define the meaning of the message, the obvious & easy implementation choice for a receiver is to switch to appropriate handling code based on the "!" value. Implementing the "MUST understand" rule for the "!" value occurs naturally as part of such switching. Consequently, senders can be confident that this "MUST understand" rule will be enforced by legitimate receivers.
[In contrast, an alternative rule to reject messages with any unrecognized fields requires receivers to write extra code to filter out all known fields and see what remains. That extra code offers no extra functionality to the receiver; it is not needed for the receiver to process a message. Consequently, senders can have little confidence that such a "MUST understand" rule will be consistently enforced.]

On defining a new form of JOSE message, a new value for the "!" field MUST be chosen if the message could be misinterpreted if it used an existing "!" value.

(Example) initial values for the "!" field:

"!":"sig" = the JOSE message contains a digital signature over the content using an asymmetric algorithm. The "alg" field MUST be understood. ...

"!":"enc" = the JOSE message uses a known symmetric key with an AEAD algorithm to encrypt the content. The content may first be compressed. The "enc" and "zip" fields MUST be understood. ...

"!":"env" = the JOSE message contains contents encrypted with an AEAD algorithm using a randomly-chosen per-message key that is conveyed to the receiver using an asymmetric key transport algorithm, or an asymmetric key agreement algorithm combined with a symmetric key wrapping algorithm. The content may first be compressed. The "enc", "trp", "agr", "wrp", and "zip" fields MUST be understood. ...

Later

"!":"env2" = as per "env" but supporting identity-based encryption (IBE) or a symmetric master key or ephemeral public keys for key exchange. The "ibe"... fields MUST be understood, in addition to the fields listed for "env".

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 27 Jul 2012 17:31:27 +1000

> > If we support extensibility with per-extension criticality flags,
> > wouldn't it be almost as inevitable that an extension will be added
> > that shouldn't be ignored but is marked non-critical to not break
> > interop? Or do you think people will "do the right thing (not the
> > easy thing)" with criticality flags?

> Anyone who believes this to be a true statement is more than welcome to
> read the current firestorm about name constraints on the PKIX mailing
> list.  They were defined and said to be critical when the first draft
> (RFC2459) came out in 1999 and people are saying that they need to make
> it non-critical because too many people did not implement it.  The JOSE
> documents are better in that there are not as many "extensions"
> defined.  But the history is still there.

Jim,

What is you conclusion for JOSE’s "MUST understand everything" rule
from the critical name constraints firestorm?

My conclusion is that the criticality of name constraints has
prevented its widescale deployment for a decade -- so internet
security has suffered. A "MUST understand everything" rule in
JOSE will similarly freeze its functionality, preventing
security improvements.

--
James Manger

---

From: <[email-masked]>
Date: Fri, 27 Jul 2012 10:29:34 +0200

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-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Thursday, July 26, 2012 7:39 PM
To: Breno de Medeiros; Manger, James H
Cc: [email-masked]
Subject: Re: [jose] MUST understand ALL header fields

                                                            -- Mike

--
James Manger

--
James Manger

--
--Breno

--
--Breno

--
--Breno

---

From: Mike Jones <[email-masked]>
Date: Fri, 27 Jul 2012 16:19:41 +0000

The problem I have with this proposal is that it imposes a burden in the normal case, where no extensions are used.  Should the working group decide to allow ANY not-understood fields (and only if), I would make this counter-proposal:

Define an "ext" (extras) header field, the value of which is an array of the extra fields in the header that may be ignored.  It would be illegal to include any of the specification-defined fields in this array.  So for example, a header could then legally contain:

{"alg":"ES256",
 "ext":["notes"],
 "notes":"This signature need not be checked when the moon is full"
}

This counter-proposal would impose a space burden on implementations only when extra that need not be understood are actually used.

Again, my personal preference would be to have no such mechanism, for exactly the reasons that Breno and Axel have stated.  But should the working group decide to have one, we could use my counter-proposal above.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Friday, July 27, 2012 12:20 AM
To: [email-masked]
Subject: Re: [jose] MUST understand ALL header fields: "!" field

Proposal:

Later

--
James Manger

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 27 Jul 2012 20:49:17 +0000

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-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, July 27, 2012 1:30 AM
To: Mike Jones; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [jose] MUST understand ALL header fields

Axel

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Breno de Medeiros
Sent: Thursday, July 26, 2012 10:35 AM
To: Manger, James H
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] MUST understand ALL header fields

--
James Manger

--
James Manger

--
--Breno

--
--Breno

--
--Breno

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 27 Jul 2012 13:55:33 -0700

If they were truly non-critical and marked as critical then there was a
decision process that arrived at the incorrect conclusion. There are
several examples of critical extensions that if ignored will cause the
processing of a certificate to lead to wide security problems. An example
is name constraints.

On Thu, Jul 26, 2012 at 9:41 PM, Jim Schaad <[email-masked]> wrote:

> wouldn't it be
> read the current firestorm about name constraints on the PKIX mailing list.
>  They were defined and said to be critical when the first draft (RFC2459)
> came out in 1999 and people are saying that they need to make it
> non-critical because too many people did not implement it.  The JOSE
> documents are better in that there are not as many "extensions" defined.
>  But the history is still there.
>
> Jim
>
> >

-- 
--Breno

---

From: Mike Jones <[email-masked]>
Date: Fri, 27 Jul 2012 20:57:31 +0000

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.1 that provides just such an extensibility point.

                                                                -- Mike

From: Anthony Nadalin
Sent: Friday, July 27, 2012 1:49 PM
To: [email-masked]; Mike Jones; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [jose] MUST understand ALL header fields

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, July 27, 2012 1:30 AM
To: Mike Jones; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] MUST understand ALL header fields

Axel

                                                            -- Mike

--
James Manger

--
James Manger

--
--Breno

--
--Breno

--
--Breno

---

From: John Bradley <[email-masked]>
Date: Fri, 27 Jul 2012 14:02:51 -0700

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:

> On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H <[email-masked]> wrote:
> Breno,
> 
>  
> 
> On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H <[email-masked]> wrote:
>

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 27 Jul 2012 14:03:37 -0700

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-masked]>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-masked]; Mike Jones; [email-masked];
> [email-masked]
> *Cc:* [email-masked]
> *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-masked] [mailto:[email-masked]] *On Behalf
> Of [email-masked]
> *Sent:* Friday, July 27, 2012 1:30 AM
> *To:* Mike Jones; [email-masked]; [email-masked]
> *Cc:* [email-masked]
> 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-masked] [mailto:[email-masked]] *On Behalf
> Of *Mike Jones
> *Sent:* Thursday, July 26, 2012 7:39 PM
> *To:* Breno de Medeiros; Manger, James H
> *Cc:* [email-masked]
> 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-masked] [mailto:[email-masked]] *On Behalf
> Of *Breno de Medeiros
> *Sent:* Thursday, July 26, 2012 10:35 AM
> *To:* Manger, James H
> *Cc:* [email-masked]
> practice.****
> An extension mechanism would define:****
>
> ** **
>
> - How to bundle fields of an extension as a single object.****
>
> extension is critical (can't be safely ignored) or not.****
>
> ** **
>
> is not an acceptable 3rd option.****
>
> ** **
>
> ** **
>
> On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros <[email-masked]>
> wrote:****
>
> ** **
>
> ** **
>
> unrecognized parameters keeps our future choices open.****
>
> ** **
>
> certificate as invalid.****
>
>  ****
>
>    ****
>
>  ****
>
> content metadata, for instance?****
>
>  ** **
>
> by usual antics and general perplexity.****
>
>  ****
>
>   ****
>
>  ****
>
> --****
>
> James Manger****
>
>  ****
>
> *Cc:* [email-masked]****

-- 
--Breno

---

From: John Bradley <[email-masked]>
Date: Fri, 27 Jul 2012 14:13:25 -0700

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:

> 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.
> If somebody needs to new algorithms or new extra parameters they should write a new draft. With all the interoperability issues that this implies…
> Let’s specify something that is useful now.
>  
> Axel
>  
>  
>  
> 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: "Jim Schaad" <[email-masked]>
Date: Fri, 27 Jul 2012 14:12:08 -0700

I don’t disagree with that, however they were not widely implemented and used, so they cannot be easily rolled out today without having a large number of implementations roll over and play dead.  This is what James is talking about when he is saying that we need to have the ability to roll out new items in a non-critical manner.

Jim

From: Breno de Medeiros [mailto:[email-masked]] 
Sent: Friday, July 27, 2012 1:56 PM
To: Jim Schaad
Cc: Manger, James H; [email-masked]
Subject: Re: [jose] MUST understand ALL header fields

If they were truly non-critical and marked as critical then there was a decision process that arrived at the incorrect conclusion. There are several examples of critical extensions that if ignored will cause the processing of a certificate to lead to wide security problems. An example is name constraints. 

<personal>

Jim

 

-- 
--Breno

---

From: <[email-masked]>
Date: Fri, 27 Jul 2012 23:52:59 +0200

We have something for ECC that seems to "work" for those who have a use case for ECC.
New parameters "that one COULD specify" are not in the current draft.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anthony Nadalin
Sent: Friday, July 27, 2012 10:49 PM
To: Nennker, Axel; Mike Jones; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [jose] MUST understand ALL header fields

Axel

                                                            -- Mike

--
James Manger

--
James Manger

--
--Breno

--
--Breno

--
--Breno

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 27 Jul 2012 17:54:08 -0700

> From: Manger, James H [mailto:[email-masked]]
> Sent: Friday, July 27, 2012 12:31 AM
> To: Jim Schaad; [email-masked]
> > Anyone who believes this to be a true statement is more than welcome
> > to read the current firestorm about name constraints on the PKIX
> > mailing list.  They were defined and said to be critical when the
> > first draft
> > (RFC2459) came out in 1999 and people are saying that they need to
> > make it non-critical because too many people did not implement it.
> > The JOSE documents are better in that there are not as many "extensions"
> What is you conclusion for JOSE s "MUST understand everything" rule from
> the critical name constraints firestorm?
> 
> My conclusion is that the criticality of name constraints has prevented its
> widescale deployment for a decade -- so internet security has suffered. A
> "MUST understand everything" rule in JOSE will similarly freeze its
> functionality, preventing security improvements.

My conclusion on the name constraints issues is that it was correctly defined as being critical by the specification; however nobody understood why they would ever need it so it was never implemented.  This means that nobody today can roll out using the name criticality functionality that should have been there from the start.

My personal opinion on the "MUST understand everything" rule is that we are looking at the wrong place for making this statement.  The correct statement is really that a library implementing the JW* documents needs to return a set of fields that it either 1) used in processing the document or 2) would have used in processing the document and it is up to the application (i.e. JWT) to decide if any given field is either mandatory, optional or required to be present.

This punts the problem from the process library which would not know how to deal with application specific items (i.e. the application would need to pass in a complete list of everything under the sun that it could possible permit being there) and moves it to where it makes sense - the application.

This is the basic position that is espoused by the CMS documents.  We can validate a signature and will use some items, but the rest are left up to the interpretation of the application for both what they mean and if they need to be there or need to be absent.  The default being that one ignores what one does not care about for most applications but not all.

Jim