Re: [jose] #26: Allow for signature payload to not be base64 encoded

"jose issue tracker" <trac+jose@trac.tools.ietf.org> Wed, 26 June 2013 00:22 UTC

Return-Path: <trac+jose@trac.tools.ietf.org>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BC711E8160 for <jose@ietfa.amsl.com>; Tue, 25 Jun 2013 17:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMYk5DFxDYrb for <jose@ietfa.amsl.com>; Tue, 25 Jun 2013 17:22:52 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EA4D521F9D64 for <jose@ietf.org>; Tue, 25 Jun 2013 17:22:51 -0700 (PDT)
Received: from localhost ([127.0.0.1]:33712 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+jose@trac.tools.ietf.org>) id 1UrdVV-0000Hd-4J; Wed, 26 Jun 2013 02:22:45 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: jose issue tracker <trac+jose@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-jose-json-web-signature@tools.ietf.org, michael.jones@microsoft.com
X-Trac-Project: jose
Date: Wed, 26 Jun 2013 00:22:45 -0000
X-URL: http://tools.ietf.org/jose/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/26#comment:1
Message-ID: <076.3f5d1244c042cd87bfb07814924fcbc9@trac.tools.ietf.org>
References: <061.c2fcfec0a75d48eb8b194991ce56157e@trac.tools.ietf.org>
X-Trac-Ticket-ID: 26
In-Reply-To: <061.c2fcfec0a75d48eb8b194991ce56157e@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-signature@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org
X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: mbj@microsoft.com, n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com
Resent-Message-Id: <20130626002251.EA4D521F9D64@ietfa.amsl.com>
Resent-Date: Tue, 25 Jun 2013 17:22:51 -0700
Resent-From: trac+jose@trac.tools.ietf.org
Cc: jose@ietf.org
Subject: Re: [jose] #26: Allow for signature payload to not be base64 encoded
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2013 00:22:54 -0000

#26: Allow for signature payload to not be base64 encoded


Comment (by michael.jones@microsoft.com)

 Having multiple ways to do something is one of the classic pitfalls to
 avoid in standards.  They tend to generate interop problems because
 developers will often only build the way that they think they need, never
 getting around to the others.   I don’t think the potential benefits of
 having multiple ways to encode the payload outweigh this cost.

 Next, this feature would only work with the JSON serialization; it would
 not work for the Compact Serialization because the payload must be URL
 safe.  The base64url encoding accomplishes that, and so is a necessary
 part of the encoding.  Having the two serializations diverge in this
 manner seems suboptimal.

 Third, I am concerned that the payload will sometimes change during
 transmission if not encoded in some manner.  Tabs can change to spaces.
 LFs can change to CRLFs.  HTML is notorious for adding a blank at the end
 of each line.  Two spaces can change to a space and a non-breaking space.
 Etc.  Not encoding the payload would open us up to all of these potential
 modification-during-transmission problems – all of which would render the
 JWS useless by breaking the signature.

 Finally, this feature seems to be motivated by detached signatures, which
 per my comment on Ticket #25, can be accomplished at the application layer
 without adding general-purpose support for detached signatures.  Thus, I
 don’t think this related feature is needed either.

 For all these reasons, I believe that this issue should be closed as
 “won’t fix”.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-jose-json-web-
  ietf@augustcellars.com |  signature@tools.ietf.org
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  signature              |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/26#comment:1>
jose <http://tools.ietf.org/jose/>