Re: [jose] #12: x5c incorrect in JWE

Richard Barnes <rlb@ipv.sx> Thu, 04 April 2013 03:36 UTC

Return-Path: <rlb@ipv.sx>
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 DAF1511E80A4 for <jose@ietfa.amsl.com>; Wed, 3 Apr 2013 20:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level:
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 qVIsKRd1js77 for <jose@ietfa.amsl.com>; Wed, 3 Apr 2013 20:36:40 -0700 (PDT)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0934611E80A2 for <jose@ietf.org>; Wed, 3 Apr 2013 20:36:39 -0700 (PDT)
Received: by mail-ob0-f177.google.com with SMTP id uz6so2151117obc.36 for <jose@ietf.org>; Wed, 03 Apr 2013 20:36:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=tKzSY76ftaa7Utib43UVfau0wTUfP10EwKxNHWI2Uc8=; b=Anhf7b6EVwI+OAHdaMffL4hxqnAAaPIshE+QxZPjLwBUTnCDB7VnFelOqGbyJaniwi jSXqJAe+cvgtRI9mdEc3/9FfVT3U8ODIznunuYVYNvM5dphTRgfov4gIy0jgbPkA0cxV +bH70mZ2sJ8P3gjjFD6mYGzPXnZzHL+giqMIgIC1TbCwC9mLbszUHf+SXoHRp/l7bhsM e4y6QA51UaCNMMfuFt2TjDk9fTtYgCOrHB1mydvcQ+JVxPJuyB5GT5GXgtxEBTARDp+f BpR+7YWKRlyNVlFWDQnHVpub+baX44cGyCQfU/WrMkTrMbMj8w44goYNamnqcHHKjFtD D+mA==
MIME-Version: 1.0
X-Received: by 10.60.85.35 with SMTP id e3mr2917672oez.117.1365046599475; Wed, 03 Apr 2013 20:36:39 -0700 (PDT)
Received: by 10.60.37.229 with HTTP; Wed, 3 Apr 2013 20:36:39 -0700 (PDT)
X-Originating-IP: [12.104.13.2]
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150C06EA61@WSMSG3153V.srv.dir.telstra.com>
References: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> <080.fec3c931ff7caa6172df3c6f437eb638@trac.tools.ietf.org> <255B9BB34FB7D647A506DC292726F6E1150C06EA61@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 03 Apr 2013 23:36:39 -0400
Message-ID: <CAL02cgSxrq9TVie4ccc-U=9F_x7cnpVcGgVWi4F2p838zDcT=Q@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
Content-Type: multipart/alternative; boundary="089e0111be00aa4d6704d980ad83"
X-Gm-Message-State: ALoCoQkIYoVzu6Kv0Q0irW1G/Voptv95b4dEXtdJZDMfkwBLUoR/+KPEFRk7uO2U0DLWcthHrPbR
Cc: "michael.jones@microsoft.com" <michael.jones@microsoft.com>, "bcampbell@pingidentity.com" <bcampbell@pingidentity.com>, jose issue tracker <trac+jose@trac.tools.ietf.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] #12: x5c incorrect in JWE
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, 04 Apr 2013 03:36:41 -0000

I don't have much feeling one way or another, especially since header
fields are non-critical now.
--Richard


On Mon, Apr 1, 2013 at 6:48 AM, Manger, James H <
James.H.Manger@team.telstra.com> wrote:

> > #12: x5c incorrect in JWE
> >
> >
> > Comment (by michael.jones@microsoft.com):
> >
> >  For generality, I'll note that if people believe that "x5c" should be
> > removed from JWE, then the same logic probably suggests that "x5u",
> > "jku"
> >  should be removed, as all are ways of including or referencing public
> > key  values corresponding to the private key used to encrypt the
> > content.  And  by that logic, if we don't need a way to reference or
> > include public key  values for JWEs, then the "x5t" and possibly "kid"
> > parameters would then  also be of dubious value.  At least by that
> > reasoning, the inclusion of  all the key reference parameters would
> > likely stand or fall together.
>
> Yay! Drop the lot ("jku", "jwk", "x5u", "x5t", "x5c") from JWE; keep "kid".
>
>
> Should we describe how to get a "kid" value from a certificate or a raw
> public key (in case an explicit "kid" value is not available to a JWE
> originator)? If you only have a cert you can look for a
> subjectKeyIdentifier extension -- though that is an OCTET STRING so it may
> need to be base64url-encoded (without padding) to give a "kid" string. A
> raw public key could be hashed to synthetise a "kid" value, but then you
> need a canonical form of the public key to hash.
>
> --
> James Manger
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>