Re: [jose] #4: Remove wrapped keys from integrity check (allow separation of keys from data)

"jose issue tracker" <> Wed, 03 April 2013 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3F1721F8C6F for <>; Wed, 3 Apr 2013 12:52:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fp7Q1PIYCgvc for <>; Wed, 3 Apr 2013 12:52:27 -0700 (PDT)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id DC7C721F8BF2 for <>; Wed, 3 Apr 2013 12:52:26 -0700 (PDT)
Received: from localhost ([]:44899 ident=www-data) by with esmtp (Exim 4.80) (envelope-from <>) id 1UNTjB-0001Dc-9i; Wed, 03 Apr 2013 21:52:13 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "jose issue tracker" <>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
X-Trac-Project: jose
Date: Wed, 03 Apr 2013 19:52:13 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 4
In-Reply-To: <>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Resent-Message-Id: <>
Resent-Date: Wed, 3 Apr 2013 12:52:26 -0700 (PDT)
Subject: Re: [jose] #4: Remove wrapped keys from integrity check (allow separation of keys from data)
X-Mailman-Version: 2.1.12
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Apr 2013 19:52:27 -0000

#4: Remove wrapped keys from integrity check (allow separation of keys from

Comment (by

 This write-up is missing the fact that even if the wrapped keys were
 removed from the integrity calculation, there's still per-recipient
 content in the headers, such as information about the key used for that
 recipient.  So I believe what you're really asking for, Richard, is to
 remove both the wrapped key and the header from the integrity calculation,
 so there is no per-recipient information protected.  (Please correct me if
 I'm wrong.)

 For starters, not protecting the headers could open us up to algorithm
 substitution attacks, because the "alg" and/or "enc" values could be
 modified by the attacker.

 Furthermore, protecting the headers cryptographically binds the
 information in them to the Ciphertext, which is a very good thing.
 Especially given that we've now allowed additional information to be
 passed in the headers (by saying that header parameter values that are not
 understood must be ignored), I fully expect that some of that information
 will only be of any value when cryptographically bound to the Ciphertext,
 so attackers cannot modify it.

 Protecting the headers values is a "secure by default" architecture.  It
 removes the need to ask questions about what attacks are enabled if header
 parameter A or header parameter B can be modified by the attacker, because
 we've taken that possibility away from the attacker.  Especially given
 that we know that we don't know what all the header parameters will be,
 from a security viewpoint, continuing to protect them seems like the only
 sensible choice.

 Reporter:               |       Owner:  draft-ietf-jose-json-web-        |
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  encryption             |  Resolution:
 Severity:  Active WG    |
  Document               |
 Keywords:               |

Ticket URL: <>
jose <>