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/>
- [jose] #26: Allow for signature payload to not be… jose issue tracker
- Re: [jose] #26: Allow for signature payload to no… jose issue tracker
- Re: [jose] #26: Allow for signature payload to no… Jim Schaad
- Re: [jose] #26: Allow for signature payload to no… Mike Jones
- Re: [jose] #26: Allow for signature payload to no… John Bradley
- Re: [jose] #26: Allow for signature payload to no… n-sakimura
- Re: [jose] #26: Allow for signature payload to no… Jim Schaad
- Re: [jose] #26: Allow for signature payload to no… Jim Schaad
- Re: [jose] #26: Allow for signature payload to no… Mike Jones
- Re: [jose] #26: Allow for signature payload to no… Jim Schaad
- Re: [jose] #26: Allow for signature payload to no… Richard Barnes
- Re: [jose] #26: Allow for signature payload to no… Mike Jones
- Re: [jose] #26: Allow for signature payload to no… Dick Hardt
- Re: [jose] #26: Allow for signature payload to no… Edmund Jay
- Re: [jose] #26: Allow for signature payload to no… Matias Woloski
- Re: [jose] #26: Allow for signature payload to no… Richard Barnes
- Re: [jose] #26: Allow for signature payload to no… Richard Barnes
- Re: [jose] #26: Allow for signature payload to no… Dick Hardt
- Re: [jose] #26: Allow for signature payload to no… Mike Jones
- Re: [jose] #26: Allow for signature payload to no… Richard Barnes
- Re: [jose] #26: Allow for signature payload to no… Dick Hardt
- Re: [jose] #26: Allow for signature payload to no… Richard Barnes
- Re: [jose] #26: Allow for signature payload to no… Dick Hardt
- Re: [jose] #26: Allow for signature payload to no… Richard Barnes
- Re: [jose] #26: Allow for signature payload to no… Dick Hardt
- Re: [jose] #26: Allow for signature payload to no… John Bradley
- Re: [jose] #26: Allow for signature payload to no… Mike Jones
- Re: [jose] #26: Allow for signature payload to no… Mike Jones
- Re: [jose] #26: Allow for signature payload to no… Manger, James H
- Re: [jose] #26: Allow for signature payload to no… jose issue tracker