Re: [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31

Stephen Kent <kent@bbn.com> Tue, 16 September 2014 20:07 UTC

Return-Path: <kent@bbn.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF211A0030; Tue, 16 Sep 2014 13:07:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Level:
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bRuaXUwkF6J; Tue, 16 Sep 2014 13:07:36 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 165011A009C; Tue, 16 Sep 2014 13:07:34 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:37441 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XTz2N-0007GZ-BD; Tue, 16 Sep 2014 16:07:43 -0400
Message-ID: <5418987E.1060307@bbn.com>
Date: Tue, 16 Sep 2014 16:07:26 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Mike Jones <Michael.Jones@microsoft.com>, Tim Bray <tbray@textuality.com>
References: <CAHbuEH4Ccn2Z=8kEECzvgjmtshwsFoa-EH_NpkJPos7zirGeaQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> <CAHBU6iu3GfsLCAint3z7risZUnVW4EK0WrGVW6Dv=gvppiHSxQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AECCCDD@TK5EX14MBXC292.redmond.corp.microsoft.com> <54173546.5000400@bbn.com> <CAHBU6ivb3BeEufcnJB+eSk8wgETMx+qzH3miE6Z1jtrQkXNR3w@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439AECE40B@TK5EX14MBXC292.redmond.corp.microsoft.com> <54184EBA.3010109@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AED1727@TK5EX14MBXC292.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AED1727@TK5EX14MBXC292.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------070202060203030204070004"
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/VjNsoS9pcTGneBdXlJcg2mPR8Jw
Cc: "draft-ietf-jose-json-web-key.all@tools.ietf.org" <draft-ietf-jose-json-web-key.all@tools.ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, "jose@ietf.org" <jose@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 16 Sep 2014 20:07:41 -0000

Mike,
>
> ...
>
> JWK objects are already used in production to distribute public keys.  
> For instance, the keys for Salesforce's identity services are in JWK 
> format at https://login.salesforce.com/id/keys. (Note that I'm not 
> saying that just because the current specs are in use, that no changes 
> are possible.)
>
> if not that, what is the point of this comment?
>
> The point of the comment was simply to answer your question "What is 
> the existing software to which you and Tim refer...?"
>
And I have not yet received an answer to that question, in terms I can 
understand.

Let me try again.

What is the impediment to requiring a receiver of a JWK object to reject 
the object if
it contains more than one instance of a key?

Is it a limitation of a parser that are completely independent of the 
JOSE work that defines
the JWK objects, or is it the result of how folks have written code to 
parse such objects?

If the answer is the first clause, then I understand the reluctance to 
impose that requirement.

If the answer is the latter, then this is an argument based on early 
implementation
of an IETF spec, and that is not an good reason to accommodate such 
sloppiness.

Steve