From philippe.leothaud@42crunch.com Sun Nov 5 21:04:40 2017 Return-Path: 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 D90BF13FC13 for ; Sun, 5 Nov 2017 21:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=42crunch-com.20150623.gappssmtp.com 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 qvordgGLUYY7 for ; Sun, 5 Nov 2017 21:04:39 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3DB13FAFE for ; Sun, 5 Nov 2017 21:04:39 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id 15so7397285wrb.5 for ; Sun, 05 Nov 2017 21:04:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=42crunch-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=q1cqVzja+GtbbVbIRX8vSKuyaeZH/9bLEDgMhSGpT3A=; b=pjpRJlnld0T2jphC0EOF1wpNob7t0cLVpidQWibecY0WVGyDHkqgkEvzaD70bV7GrI +zJbwMvA77+WSXEc5xz4a//j89j0YioBha5jzXTPsKu0erh9laMpEn98TXCyeON041Ay B9srniFFcbE3+KGqXroF82pKoA08I3YdqIBPc/9l7eEJuCEuSl9oZlWTLuHzrtPPt5Mx CO4l2YUWwSlhSJsdOn7QKwvZjDx2e9+NELhlYUhSQWRlleFdcoLYDAsXQinG0BTWD+ke ZWOerrPvUKDBGWjEGM+94fV95+XyEHR7QAaaSE5hN2IvwM2Y9oSGEonaTSPIbs1CjcLA +qEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=q1cqVzja+GtbbVbIRX8vSKuyaeZH/9bLEDgMhSGpT3A=; b=QkStFpZyFudJf51mcYRh4GBK6KSCOe5pJeBXvgmwiwf/1i+kIYW4E111mc9Xt6ZRFd HVgHbHvqf60WSuR97p+TmpHQL8qCE3CFLtAwV+9Br31/qD0Cz0vOCAzXTe2DlQz/I8Jr kUfDpoiB1T4bKxMCCQdyo55m3oI3/xQ1iUILmvyt+G3ew1zThEgQp2ZVjMinkKi5l4xg MZpRX1v3yfOFqJeFKQDTytF3Qc7bCB/5ebXOxE00dzIBJt4N57YesGd9413JboXmor3e 3DZIdwp5969kQ0RG0v5Q3TS+pLhPXGiyrhmk6tTUGCvpsnDa88ah8mlZkjGNPRVlv8kh nvlA== X-Gm-Message-State: AMCzsaV4ZPbWUtVnJrNHYv3pMkUPcp5BGWbno2mzzZdJx6jZE+jfTgJN caMVYzkhdQmnklDVgKH43OG9OGtbQYekcxNefWJFA+3x0tI= X-Google-Smtp-Source: ABhQp+QSyjKxkHGnmHa9p1nIl1TjhJa7yNhcTmQKNM8AebGyvmS0jwTAlL5DYFNTCRryMOoIEwxW4zn28cKByO+vFuQ= X-Received: by 10.223.131.226 with SMTP id 89mr12114660wre.227.1509944677284; Sun, 05 Nov 2017 21:04:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.170.200 with HTTP; Sun, 5 Nov 2017 21:04:36 -0800 (PST) From: Philippe Leothaud Date: Mon, 6 Nov 2017 06:04:36 +0100 Message-ID: To: jose@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0d1fc21f14df055d4964a4" Archived-At: X-Mailman-Approved-At: Mon, 06 Nov 2017 08:51:47 -0800 Subject: [jose] Header parameter uniqueness related problem in RFC 7516? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 05:05:50 -0000 --94eb2c0d1fc21f14df055d4964a4 Content-Type: text/plain; charset="UTF-8" Hi there, In RFC 7516, page 23 at the end of section 7.2.2 (Flattened) it is written : "Note that when using the flattened syntax, just as when using the general syntax, any unprotected Header Parameter values can reside in either the "unprotected" member or the "header" member, or in both." While page 17, in the 5.2 Section (Message decryption) it is written : " 4. If using the JWE Compact Serialization, let the JOSE Header be the JWE Protected Header. Otherwise, when using the JWE JSON Serialization, let the JOSE Header be the union of the members of the JWE Protected Header, the JWE Shared Unprotected Header and the corresponding JWE Per-Recipient Unprotected Header, all of which must be completely valid JSON objects. During this step, verify that the resulting JOSE Header does not contain duplicate Header Parameter names. When using the JWE JSON Serialization, this restriction includes that the same Header Parameter name also MUST NOT occur in distinct JSON object values that together comprise the JOSE Header." My problem is that if a Header Parameter is in "both" the "unprotected" and the "header" member, it is therefore not unique. Am I missing something? Thanks in advance, Philippe Leothaud 42 Crunch --94eb2c0d1fc21f14df055d4964a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

In RFC 7516, page = 23 at the end of section 7.2.2 (Flattened) it is written :=C2=A0
=
=C2=A0 "Note that when using the flattened syntax, just= as when using the
=C2=A0 =C2=A0general syntax, any unprotected H= eader Parameter values can reside in=C2=A0
=C2=A0 =C2=A0either th= e "unprotected" member or the "header" member, or in bo= th."

While page 17, in the 5.2 Section (Messa= ge decryption) it is written :=C2=A0

=C2=A0" = 4.=C2=A0 =C2=A0If using the JWE Compact Serialization, let the JOSE Header = be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the JWE Protected Header.=C2=A0 Ot= herwise, when using the JWE JSON
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Seri= alization, let the JOSE Header be the union of the members
=C2=A0= =C2=A0 =C2=A0 =C2=A0 of the JWE Protected Header, the JWE Shared Unprotect= ed Header
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and the corresponding JWE P= er-Recipient Unprotected Header, all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = of which must be completely valid JSON objects.=C2=A0 During this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 step, verify that the resulting JOSE Header do= es not contain
=C2=A0 =C2=A0 =C2=A0 =C2=A0 duplicate Header Param= eter names.=C2=A0 When using the JWE JSON
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Serialization, this restriction includes that the same Header
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Parameter name also MUST NOT occur in disti= nct JSON object=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 values that tog= ether comprise the JOSE Header."

My problem i= s that if a Header Parameter is in "both" the "unprotected&q= uot; and the=C2=A0 "header" member, it is therefore not unique.

Am I missing something?

Th= anks in advance,

Philippe Leothaud
42 Cr= unch
--94eb2c0d1fc21f14df055d4964a4-- From nobody Thu Nov 16 22:53:21 2017 Return-Path: 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 67A34128D0F for ; Thu, 16 Nov 2017 22:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zGosV3seyT8p for ; Thu, 16 Nov 2017 22:53:17 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42551286C7 for ; Thu, 16 Nov 2017 22:53:16 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id g130so2263218wme.0 for ; Thu, 16 Nov 2017 22:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=MMW8v0RI6LD12Znq+Gnq1zBo2ogEb1W0/1OuNIvqJUU=; b=XdBvgCIWhPwaZuIjcNNCFEMV13R4G7xpSdlajWT4fGqXeiWkvLID7WZ5MDw4v8o84f 2l7flQXvNJmtq8tLfRwiI9brlORQYU4jC7WzH6wSjb6Ok5nyFHmkfbCO2CcsSsfVKq6s cfou1Z5Df16WectQOCNb2dw4VxFIQoP4SSCKl/PqYY+EysiMUZwKlsPOfaNXB9oDInOB 194vOL0KmEm9899bf7UTQ8Y9j0C3Dw/ioXqpZ2DDeaVJi4NmF5bFR87YtuRZ5U0edMNk 0Aqn+ezCLyMcyherHq5JeDNdMfk2CzVJfo2/EvjFWvOuz3Z0JK89NzZS1hilPowt8BCh Z7hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=MMW8v0RI6LD12Znq+Gnq1zBo2ogEb1W0/1OuNIvqJUU=; b=h2DUHo2kD+1urEO+SaaJJgSwFbz5RRfslU377MlOPYZieoPwbr2DTRersITZSNJHsM e3RmhkAwfteyBAn3bwp+puBFBXvAw5Rl5oPNE+RpbvoX8MjrkHRGtkoHREBbzYwPH1Sr ut9JolYKIMhcODjtHi7bxZedMoJXWn8Ef4x26DEbORz2dbRlfweCX1WqQ+AomoV7E14q gFa+1/xGiC1gThN8OfqNTMR1MlBGXO7VqpdsA2bPffWftt3/QwZeqQCbMf7mpG7aLDRt EndC+JQOPpZeO6R6AVK9qNqEawdhrHmSwmKb4MRLHUWEuETd4OxodRv5h1S6NHL8GZbi KtaQ== X-Gm-Message-State: AJaThX7nQOxn0AHPgLy4wvLEZBv+AbIdYLEH52NbgZKTV3hhZP3aZPOJ 1Anh33astxxhqb4pxMdl0QVujQ== X-Google-Smtp-Source: AGs4zMZ0eS3HjMYTtS/f0+7mdHUHBODmir9bmGVTAzS7+cSZTrTnLIQ3LAXbvBcfmqLTmvoP9/G5gg== X-Received: by 10.80.213.90 with SMTP id f26mr6110480edj.225.1510901595431; Thu, 16 Nov 2017 22:53:15 -0800 (PST) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id r4sm2197455edd.4.2017.11.16.22.53.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 22:53:14 -0800 (PST) From: Anders Rundgren To: "jose@ietf.org" Message-ID: Date: Fri, 17 Nov 2017 07:53:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [jose] Signed JSON for "Open Banking" - An implementation report X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 06:53:19 -0000 Dear List, Here is a list of the three most well-known APIs for Open Banking and their take on "Signed JSON": http://openid.net/specs/openid-financial-api-part-2.html#request In-line JWS (base64url-encoded messages) https://www.stet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.2.pdf#page=56 HTTP-Signatures (clear text messages using a not yet standardized signature scheme) https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-1-0/#usage-examples-merchant-illustrative-interactions-payment-setup Detached JWS (clear text messages signed by a JWS in a specific HTTP header) I believe this supports my view that base64-encoded JSON will continue to be a hard sell no matter how good it may be. Other "uncool" side-effects include lookup services providing signed responses in base64url https://tools.ietf.org/html/draft-ietf-oauth-discovery-07#section-2.1 and security protocols needing artificial outer layers in order to make objects recognizable https://tools.ietf.org/html/draft-pei-opentrustprotocol-01#section-8.2.1.1 May I propose a JOSE2 effort based on ES6.JSON serialization [1] to end the current proliferation of "DIY standards" and reducing the need for [ugly] workarounds like used by UK's Open Banking? Making JOSE more Browser/JS friendly wouldn't be a terrible idea, either. Availability of ES6.JSON compatible tools isn't really a showstopper, we are talking about < 2000 lines of pretty simple [2] code for parsing and serialization. thanx, Anders 1] https://cyberphone.github.io/doc/security/jcs.html#Normalization_and_Signature_Validation 2] Well, number serialization is non-trivial so implementers probably need to build on already written code and algorithms out there like I did.