Re: [jose] issues with x5c in JWE

John Bradley <ve7jtb@ve7jtb.com> Thu, 31 January 2013 16:54 UTC

Return-Path: <ve7jtb@ve7jtb.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 28B5521F85D2 for <jose@ietfa.amsl.com>; Thu, 31 Jan 2013 08:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_12=1, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snaW57-fMxVU for <jose@ietfa.amsl.com>; Thu, 31 Jan 2013 08:54:47 -0800 (PST)
Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0483F21F8563 for <jose@ietf.org>; Thu, 31 Jan 2013 08:54:46 -0800 (PST)
Received: by mail-qe0-f43.google.com with SMTP id 3so818114qeb.2 for <jose@ietf.org>; Thu, 31 Jan 2013 08:54:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8Y+C5aMwsSHyZDcH8oFkynoQ6RRfi5ezewdI9zUhEuA=; b=XXB2BXKqK9rqwFHCOOgphonnLqyqb5mwj/EsqxKKAh66FlpE2qgv67Vv7TxbT5eFcR d0Zrml+xHKfH/GrYMA5XfHv/HLI7/SfXPxRRoZDiOKCW8ILwHzLAvRkvDCgDdZ0QfTM7 0PnHOuIQKtXI5rbTeWUDJe5buIwdz327QjzOS2lzYtFJaxq0qCLBqA1/8oEC7CoY5KG1 mEdCIbgzoFvgSueDRBDqtLEzIbTgk4OlWlIqVocpipdXPjnmWGaVAzi4txAv/iozUYY7 k9zIRZEia+sgcuJScjBITxbgg0aCVCIjD4IKPmaXcr+m9DFDFtluEWc2CBTNaSk16dos hdyA==
X-Received: by 10.229.136.139 with SMTP id r11mr1449550qct.3.1359651285282; Thu, 31 Jan 2013 08:54:45 -0800 (PST)
Received: from [192.168.1.211] (190-20-20-78.baf.movistar.cl. [190.20.20.78]) by mx.google.com with ESMTPS id f5sm4747427qac.5.2013.01.31.08.54.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 08:54:44 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <BF7E36B9C495A6468E8EC573603ED94115109840@xmb-aln-x11.cisco.com>
Date: Thu, 31 Jan 2013 13:54:33 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BC322C1-A6C5-46B8-BC2A-3A7E000952EF@ve7jtb.com>
References: <CA+k3eCRbkefo3M+7QK_anM+H-VQLj2b+Jvw+8EXKPnSuc4Y_7Q@mail.gmail.com> <DAD9D0F9-1889-41B8-8F87-2FC689E9397B@ve7jtb.com> <CA+k3eCQqTpiTdDwdkqFNU9UApM8H4TjjkKq+XupSQuhLkbjRsg@mail.gmail.com> <BF7E36B9C495A6468E8EC573603ED94115109840@xmb-aln-x11.cisco.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkxUmWCjCCbO+q33Ja/ZS0lKTUrOfvwBZ4y+VizFAQ15P8LxIXNr7wPzTa16Mb+HAlEnDC5
Cc: Brian Campbell <bcampbell@pingidentity.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] issues with x5c 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, 31 Jan 2013 16:54:51 -0000

Brian and I were discussing a couple of options off the list.

One possible thing might be to add x5c and/or x5u elements to jwk.

In Connect we are looking at how to deal with key rollover for signing.

The problem with specifying a x5u is that while it is a vert chain it is a single cert chain, so you need to have multiple and there is no easy way to have the same keyid for a jwk key and a x5u key.

My idea was to allow x5u elements in a jwk so that you can have a single keyid and key use that apples to both formats.

I can see a use for x5c in jwk as well especially where it is being sent in band.

So while it may sound crazy a number of us may be thinking the same thing.

John B.

On 2013-01-31, at 1:42 PM, "Matt Miller (mamille2)" <mamille2@cisco.com> wrote:

> 
> On Jan 31, 2013, at 9:20 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
> 
>> Seems to me that something like x5c would be a lot more meaningful and
>> useful for a possible future ECDH-SS algorithm for JWE. But it would be
>> about the encrypting party or sender's certs in that case, right? Which
>> would be different than how it's currently being used. And that might be
>> another argument for not having it in JWE right now.
>> 
>> Of course that starts to beg the "must understand headers" question but I
>> digress...
> 
> I was starting to come to similar conclusions.
> 
> This probably sounds crazy, but maybe we can pretend x.509 certs can be wrapped into a JSON Web Key?
> 
> {
>  "kty":"X509",
>  "x5c": [....]
> }
> 
> 
> - m&m
> 
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.
> 
>> On Tue, Jan 29, 2013 at 8:04 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>> 
>>> Yes for encryption (Leaving ECDH-SS aside ) the recipoient decrypts with a
>>> secret.  I would expect a kid in the header.
>>> 
>>> I suppose they if the recipient published a x5c that the sender used to
>>> encrypt with then you could include the x5c as a reference though a
>>> thumbprint would be simpler as the recipient is probably keeping its
>>> private keys in a key-store of some sort.
>>> 
>>> In any event we would minimally want to change that to
>>> 
>>> "The certificate containing the public key of the entity that is to
>>> decrypt the JWE MUST be the first certificate."
>>> 
>>> 
>>> Thanks Brian
>>> 
>>> John B.
>>> 
>>> 
>>> On 2013-01-29, at 11:08 PM, Brian Campbell <bcampbell@pingidentity.com>
>>> wrote:
>>> 
>>> I just noticed a couple of things in the JWE's x5c definition that struck
>>> me as maybe not right.
>>> 
>>> From
>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-4.1.9
>>> 
>>> "The certificate containing the public key of the entity that encrypted
>>> the JWE MUST be the first certificate." - but it's not the public key of
>>> the entity that encrypted, is it? It's the public key of the entity that
>>> will decrypt. The other entity.
>>> 
>>> "The recipient MUST verify the certificate chain according to [RFC5280]
>>> and reject the JWE if any validation failure occurs." - maybe I'm missing
>>> something but why would the recipient verify it's own certificate chain?
>>> 
>>> And the first hyperlink in "See Appendix B<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-B>of [
>>> JWS<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#ref-JWS>]
>>> for an example "x5c" value" takes you to Appendix B of JWE, which is
>>> Acknowledgements, rather than JWS as the text would suggest.
>>> 
>>> So all those little nits could be fixed. But maybe it'd be better to just
>>> remove x5c from JWE all together? As Richard pointed out previously,
>>> http://www.ietf.org/mail-archive/web/jose/current/msg01434.html, there's
>>> really no point in sending a whole chain to help the recipient identify its
>>> own key.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>>> 
>>> 
>>> 
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>