Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)

Mike Jones <Michael.Jones@microsoft.com> Tue, 21 October 2014 19:06 UTC

Return-Path: <Michael.Jones@microsoft.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 EFE801A8775; Tue, 21 Oct 2014 12:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 r_c_ztWXadLB; Tue, 21 Oct 2014 12:06:57 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7701A882B; Tue, 21 Oct 2014 12:06:43 -0700 (PDT)
Received: from CO2PR03CA0028.namprd03.prod.outlook.com (10.141.194.155) by DM2PR03MB399.namprd03.prod.outlook.com (10.141.84.148) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 19:06:42 +0000
Received: from BY2FFO11FD028.protection.gbl (2a01:111:f400:7c0c::177) by CO2PR03CA0028.outlook.office365.com (2a01:111:e400:1414::27) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Tue, 21 Oct 2014 19:06:42 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Tue, 21 Oct 2014 19:06:41 +0000
Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0210.003; Tue, 21 Oct 2014 19:05:58 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Richard Barnes <rlb@ipv.sx>
Thread-Topic: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
Thread-Index: AQHP3fhplIq+W4ZoEEasWTGBJnPDQpwiYnawgAeSH4CAAXKiMIAN3xGAgAHAfFA=
Date: Tue, 21 Oct 2014 19:05:57 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB1E387@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <20141002042150.11117.29199.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C55@TK5EX14MBXC286.redmond.corp.microsoft.com> <CAL02cgRSufwEk1eF=AFOXMSzkWpSTRbdtBX9yMOtkMN58uH1zQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439BAFAD6E@TK5EX14MBXC286.redmond.corp.microsoft.com> <CAL02cgQipR7b8AgOtopgkj4TJjLivWfYU+4tWA35Oqwvw3cRjw@mail.gmail.com>
In-Reply-To: <CAL02cgQipR7b8AgOtopgkj4TJjLivWfYU+4tWA35Oqwvw3cRjw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.35]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(189002)(199003)(85806002)(76176999)(54356999)(55846006)(87936001)(47776003)(20776003)(46102003)(86362001)(106116001)(23676002)(81156004)(106466001)(4396001)(97736003)(77096002)(85852003)(64706001)(107046002)(2656002)(80022003)(92566001)(31966008)(99396003)(120916001)(76482002)(85306004)(21056001)(93886004)(104016003)(110136001)(230783001)(50466002)(50986999)(69596002)(6806004)(95666004)(84676001)(26826002)(44976005)(66066001)(92726001)(86612001)(33656002)(68736004)(561944003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB399; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB399;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0371762FE7
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/WX2VkfMMRFJupxp7bav8G5OuaVA
Cc: "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>, "draft-ietf-jose-json-web-signature@tools.ietf.org" <draft-ietf-jose-json-web-signature@tools.ietf.org>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
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, 21 Oct 2014 19:06:59 -0000

> > > Section 7.2.
> > > I've had several implementers trying to use JWS in the JSON serialization ask why
> > > it was necessary to include a "signatures" array in cases where there's only one
> > > signer.  It seems like this is going to be a major barrier to deployment and re-
> > > use, so I would propose including the following text:
> > >
> > > """
> > > In cases where the JWS has been signed by only a single signer, the "signatures"
> > > array will contain a single object.  In such cases, the elements of the single
> > > "signatures" object MAY be included at the top level of the JWS object.  A JSON-
> > > formatted JWS that contains a "signatures" field MUST NOT contain a
> > > "protected", "header", or "signature" field, and vice versa.
> > > """
> > >
> > > This may also require some other changes where "signatures" is relied on, e.g.,
> > > in Section 9 of the JWE spec.
> > This was previously proposed (I believe during the Denver interim meeting) and rejected by the working group because it complicates both producers and parsers by introducing an unnecessary special case.  Currently, by design, whether there are single or multiple signatures, the same syntax is used.  Your proposal would use a different syntax in the single signature case than in the multiple signature case.  This is likely to result in implementation bugs and inconsistencies.
> >
> > This assertion of complexity is bogus.  Have you implemented this syntax, or can you point me to someone who has, and has had problems?  I have implemented it and I'm asking for the simpler syntax.  I've gotten the same request from others, for JWE.
> 
> I'm not saying that anything is insurmountable.  I'm saying that having two equivalent syntaxes in the JSON Serialization for the same thing is going to make it more likely that some implementations won't correctly support both of them.  For those following along, those two syntaxes would be:
> 
>   {
>    "payload":"<payload contents>",
>    "signatures":[
>     {"protected":"<integrity-protected header 1 contents>",
>      "header":<non-integrity-protected header 1 contents>,
>      "signature":"<signature 1 contents>"}]
>   }
> 
> and
> 
>   {
>    "payload":"<payload contents>",
>    "protected":"<integrity-protected header 1 contents>",
>    "header":<non-integrity-protected header 1 contents>,
>    "signature":"<signature 1 contents>"
>   }
> 
> It's worth noting that the multi-signer case reduces to the single-signer case, e.g.:
> 
> <script>
> var JWS = get_jws();
> if ("signatures" in JWS) {
>   // i = index of a signature we'll use
>   JWS.protected = JWS.signatures[i].protected
>   JWS.header = JWS.signatures[i].header
>   JWS.signature = JWS.signatures[i].signature
> } else if (! ("signature" in JWS) && (("protected" in JWS) || ("header" in JWS))) {
>   throw "malformed JWS";
> }
> var result = validate_single_signer_jws(JWS)
> </script>
> Or copy "payload" up into each signature object.  Or iterate through signatures and see which ones work.  Either way, you're going to build this with a "verify single signature" primitive.
>  
> Is your motivating use case a profile of the JSON Serialization in which multiple signatures aren't used or supported, and so for which the array notation would always be superfluous syntax?  Are you concerned that if this profile becomes the predominant use case, that some/many implementations wouldn't implement the more general multi-signature syntax (or would implement it incorrectly, since it would normally not ever be used or tested)?
> 
> If you look at existing uses for signed objects (such as they are), single-signer is by far the dominant use case, so requiring the multiple signer notation is would almost always be superfluous syntax.
> I'm not all that concerned about support for multi-sig.  If implementations care about it, it will get built.  And because of the way this has been designed, it's easy to build once you've got the single-signer version (see above).
> 
>  
> I'd love to hear others in the working group chime in on this topic...

There appears to be working group support for this position and the related position for JWE.  I'm writing to let you know that, unless I hear objections from the working group in the next few days, I will plan to accept this suggestion and incorporate it into the -36 drafts.

				-- Mike