Re: [jose] #23: Make crypto independent of binary encoding (base64)

Phillip Hallam-Baker <hallam@gmail.com> Thu, 13 June 2013 03:51 UTC

Return-Path: <hallam@gmail.com>
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 9925C21E8056 for <jose@ietfa.amsl.com>; Wed, 12 Jun 2013 20:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 L4yrT7HT1zPq for <jose@ietfa.amsl.com>; Wed, 12 Jun 2013 20:51:25 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A61F121E804D for <jose@ietf.org>; Wed, 12 Jun 2013 20:51:24 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id m46so7540670wev.16 for <jose@ietf.org>; Wed, 12 Jun 2013 20:51:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yef58B0Erxzcc5DEPkuGZMcPnuSHxBRIBfkKtC42hNQ=; b=f8zEh5YW1OxV6r7qQxFtsLsWYj5GT2s90JrK8vZcUuEnLKLmJytoQ47bQJhCON8PsT 768CYvOod4mVRXulf2mqulBuTKuLyvxvdPt6t+z66Lkc7xJhzsseMbjtaPhMqbs/4OAl bR/yJlgTJm8Y8ALPrFTxZp8HFBxTTZiqpT+P/xWDJyL3Mdptn7fwKZlR+haUVdexSlHS 2R+ZKiKJ8inZ1e4X0vLDxx+eW9PKHoQWZ0zV6YrIzxNLVXSGQrMYA85yGpcCOuncrDjx s+XTmoYHuVf1ZobowQkZljxDi1jOfqUigZGu/TOGrN7odkH2ojO/KO6WxlLudO/N/2df fqvQ==
MIME-Version: 1.0
X-Received: by 10.180.39.136 with SMTP id p8mr78020wik.11.1371095483802; Wed, 12 Jun 2013 20:51:23 -0700 (PDT)
Received: by 10.194.54.10 with HTTP; Wed, 12 Jun 2013 20:51:23 -0700 (PDT)
In-Reply-To: <F337BFF0-4194-405F-ACDA-644B253BA24E@ve7jtb.com>
References: <049.69ffc5ebf959c6eac7990651822fadf9@trac.tools.ietf.org> <064.e396e921644745f7bd339ad363a7d7f7@trac.tools.ietf.org> <BF7E36B9C495A6468E8EC573603ED94115283F43@xmb-aln-x11.cisco.com> <CAL02cgSpYtAVVNe7AOiNhnBUqP-=CWaXw7NH2XwUu6eXgfZJ+w@mail.gmail.com> <F337BFF0-4194-405F-ACDA-644B253BA24E@ve7jtb.com>
Date: Wed, 12 Jun 2013 23:51:23 -0400
Message-ID: <CAMm+Lwh0w5bxnvWWdjeQQfCYuMoz73utrg=fUG_HLdtaB3npzw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="001a11c366d643ed4004df010b3a"
Cc: Richard Barnes <rlb@ipv.sx>, "<draft-ietf-jose-json-web-encryption@tools.ietf.org>" <draft-ietf-jose-json-web-encryption@tools.ietf.org>, "<michael.jones@microsoft.com>" <michael.jones@microsoft.com>, jose issue tracker <trac+jose@trac.tools.ietf.org>, "<jose@ietf.org>" <jose@ietf.org>, "Matt Miller (mamille2)" <mamille2@cisco.com>
Subject: Re: [jose] #23: Make crypto independent of binary encoding (base64)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Thu, 13 Jun 2013 03:51:25 -0000

I also prefer to process bit as they appear on the wire.

A binary encoding is going to need different code for the parser/encoder. I
don't see a problem tweaking aspects of JOSE that were bound to the
particular JSON encoding.

While it would be nice in theory to be able to transform between encodings
and have signatures still work, I don't think that is possible except in
the very specific case where all that is being done is base64 encoding
binary blobs.

I don't believe that any canonicalization scheme has proved to be reliable
enough in practice to actually provide the alleged value. There seem to be
more corner cases than anyone imagines possible.


I certainly would not want to break JWT for the sake of an encoding that
JWT is not using.