Re: [jose] #14: Support longer wrapped keys than OAEP allows

"jose issue tracker" <> Sat, 30 March 2013 22:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3968321F8633 for <>; Sat, 30 Mar 2013 15:13:49 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ONMSrcPndlcV for <>; Sat, 30 Mar 2013 15:13:48 -0700 (PDT)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id 6817421F862B for <>; Sat, 30 Mar 2013 15:13:48 -0700 (PDT)
Received: from localhost ([]:46945 ident=www-data) by with esmtp (Exim 4.80) (envelope-from <>) id 1UM41u-0002qN-I6; Sat, 30 Mar 2013 23:13:42 +0100
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: Sat, 30 Mar 2013 22:13:42 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 14
In-Reply-To: <>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Resent-Message-Id: <>
Resent-Date: Sat, 30 Mar 2013 15:13:48 -0700
Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows
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: Sat, 30 Mar 2013 22:13:49 -0000

#14: Support longer wrapped keys than OAEP allows

Comment (by

 As pointed out by James Manger in
 archive/web/jose/current/msg01853.html, "Keys for all of the algorithms
 fit within OAEP with a 2048-bit RSA key. JWA already says RSA key sizes
 MUST be at least 2048 bits.

 This already looks sufficient."

 I agree with James that I know of no use case where this limit will be hit
 in practice.  However it could be that Richard is thinking of encrypting
 JWKs, rather than wrapping keys, in which case we already have a solution
 in the form of draft-miller-jose-jwe-protected-jwk.  Also, see my comments
 at on the
 desirability of distinguishing between (1) Encrypting the ephemeral
 symmetric key value used within a JWE and (2) encrypting a JWK or JWK Set
 containing symmetric and/or private key information and potentially other
 key attributes, enabling the encrypted JWK or JWK Set to be safely stored
 or transported.

 Finally, as Matt Miller wrote in
 archive/web/jose/current/msg01863.html, "Personally, I don't think it's
 worth discussing this much further without a more complete counter-
 proposal on the table."  I agree that a concrete set of proposed changes
 would be needed to make this actionable.

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

Ticket URL: <>
jose <>