Re: [Acme] Specify which JWS serialization is used
Logan Widick <logan.widick@gmail.com> Fri, 02 March 2018 19:29 UTC
Return-Path: <logan.widick@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD4F124217 for <acme@ietfa.amsl.com>; Fri, 2 Mar 2018 11:29:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 FoNY3EgdcTbK for <acme@ietfa.amsl.com>; Fri, 2 Mar 2018 11:29:43 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 DA509126C22 for <acme@ietf.org>; Fri, 2 Mar 2018 11:29:42 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id d71so11734696iog.4 for <acme@ietf.org>; Fri, 02 Mar 2018 11:29:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x//JyLDqHf5SNBnlw5dpZ3oS+VbU1VHSPCnXayAwrcs=; b=nCYkFxCJY8TZ4vllPCAWmwbWQDjhQTW/79GGc29RkVjKFT7BTTGtagEmu7N9bOFHh4 i13WE//JGvheTIAnbhmggFwg8DhlRN+R5CZpIeJV0R4X+nv/+WCQCAOdZg8aNOIUY1i7 RHmwvXPhfimu8yVZi/+yvREF9l1L75P1OKUT4PSF+Tdfo82XWiFNNxoTUi8r87P5OxeJ Spc5M5NitRYk063gnBjtjxZ2KzZ97xJCNaDeq3fyE92vm8vu3jOl9ZAJSvrAGVcQX1YP 21EYpiGcGDQPLd4+eQgjuiQ16CY8Lm6difGKlbGVh1i5c+wjiSt6JlboIjgI2t1VpWvJ sB0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x//JyLDqHf5SNBnlw5dpZ3oS+VbU1VHSPCnXayAwrcs=; b=LHKAg13durLDhgVx8CzthlXltglGNGwijk9X94ngJbp5Bl0L7EUPe3SLtENVVSA86e Zcod6eNFrVKGa+wRAc7fzCb98o8sslPI7ANyWPClDrPgyv+HnmsyZAcQtuS+L6NqZPTd BH9BL9BDPRg3E6EYSN1EOJyTltAnAMdhSAvNxOjmpuW5KF3YglYQctCDXJ1P7UrAk+jA x2LiU2jq+GNBGUT80jQwcT1fVIOxiJWklKSjBby7pyS5rKKjAfH4z0v19A5AoOm3GSp+ w5vL1nLWMtwXiTDXVhG5+V3Jkj/mKP2R7DBjEFqWecFFAQEE5HO1ucY9Rkx/qLwvgGK3 dNtA==
X-Gm-Message-State: AElRT7HORN55sdL+zYFEWYFhdMYOxXeGhWY+y92/2+7LjPz2lPGXropp t+7hb2kUreLKHknj4JRrcZe6D9Ea1S8B03z4Kn8=
X-Google-Smtp-Source: AG47ELto7d/W+lEHJbg2ZFv46G8MbPPVayviZx1Eg7SjELxZ0TSM/L+RbqygXwniTzybMBxOI7kGI+aVsC1w1nXlbgM=
X-Received: by 10.107.163.78 with SMTP id m75mr5123583ioe.26.1520018981888; Fri, 02 Mar 2018 11:29:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.27.77 with HTTP; Fri, 2 Mar 2018 11:29:41 -0800 (PST)
Received: by 10.2.27.77 with HTTP; Fri, 2 Mar 2018 11:29:41 -0800 (PST)
In-Reply-To: <63F4F466-8398-41E6-BD25-5414ADA9D1B3@felipegasper.com>
References: <20180103230734.GM21695@carrot.tutnicht.de> <20180103234718.GA1340@bacardi.hollandpark.frase.id.au> <CAMmAzEKj33xOVhUK+i2UrHpvTBj=hz89DRyaFvTqAig4f66K-Q@mail.gmail.com> <CAMmAzEKSv1pbKC80JLpRQxTrGApc7KVu6A7cqDp-Tmrcq4vvLg@mail.gmail.com> <20180104110204.GP21695@carrot.tutnicht.de> <CAMmAzEKJhMaUBtCWSNZyGv-f+-edZ-WTq3=WFD_b1bXfvua89A@mail.gmail.com> <20180106001126.GB3076@carrot.tutnicht.de> <CAMmAzELgjpAmVCX6YB0VMvNQV3NH3NDdM_pdcz6d+h=ZO2rJww@mail.gmail.com> <CAMmAzEKMffffrxAihotVWPpqy=LaRkpSJuW9CpSVoQfLQ-nBwQ@mail.gmail.com> <CAL02cgRLXkkQECF5ssGh39uFL0xJp-3EODxGSQVzfPuEnE7FgA@mail.gmail.com> <63F4F466-8398-41E6-BD25-5414ADA9D1B3@felipegasper.com>
From: Logan Widick <logan.widick@gmail.com>
Date: Fri, 02 Mar 2018 13:29:41 -0600
Message-ID: <CAMmAzEKksnuBi0LPHsAsd2qs1brbMqrJBdtsbArTr6HhGrkN+A@mail.gmail.com>
To: Felipe Gasper <felipe@felipegasper.com>
Cc: Richard Barnes <rlb@ipv.sx>, ACME WG <acme@ietf.org>, Jörn Heissler <acme-specs@joern.heissler.de>, Fraser Tweedale <frase@frase.id.au>
Content-Type: multipart/alternative; boundary="001a114028d877a628056672ff87"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/h5lDD1Madx7q72XQsYcuEtnZxPI>
Subject: Re: [Acme] Specify which JWS serialization is used
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2018 19:29:48 -0000
I think the follow-on (#398) includes the Accept header in error responses (to requests with unacceptable serializations). Also, there may need to be another follow-on regarding how to serialize "nested" JWS instances (like the externalAccountBinding and the inner JWS for a key change). Logan On Mar 2, 2018 9:47 AM, "Felipe Gasper" <felipe@felipegasper.com> wrote: Could there be some way of using a header like “Accept” for a server to indicate whether it supports jose, jose+json, or both? -F > On Mar 2, 2018, at 9:50 AM, Richard Barnes <rlb@ipv.sx> wrote: > > Hey all, > > I merged #395 last night (thanks, Logan!). While I was reviewing that, I noticed that we need to cover the case where the client sends an encoding that the server doesn't understand. So I've posted a follow-on that adds an error code and requires its usage. LMK if you have any objections, otherwise I'll merge before submission on Monday. > > https://github.com/ietf-wg-acme/acme/pull/398 > > Thanks, > --Richard > > On Mon, Feb 12, 2018 at 2:37 PM, Logan Widick <logan.widick@gmail.com> wrote: > I've created a new pull request (https://github.com/ietf-wg- acme/acme/pull/395) to partially address the lack of serialization format specification. This pull request requires use of the Content-Type HTTP header to indicate the serialization format of the outermost JWS. The pull request also includes restrictions on the serializations (no detached payload, no unencoded payload, no unprotected header, etc.). In addition, the pull request bans multiple signatures, regardless of the serialization used. The use of the Content-Type header, and the list of currently possible serializations, is mentioned in its own subsection of "Message Transport". > > The pull request does not contain advice on how to convert different serialization formats before and/or after use with a pre-existing JWS library. I have started on a separate conversion guide ( https://github.com/uhhhh2/jwe-jws-serialization-conversion-guide) for that purpose. > > The pull request does not specify how a "nested" JWS should be serialized. However, I have included an outline of one possible approach to this in the pull request's description. > > Please let me know what you think about the pull request ( https://github.com/ietf-wg-acme/acme/pull/395), and the separate conversion guide (https://github.com/uhhhh2/jwe-jws-serialization-conversion-guide) > > Logan > > On Fri, Jan 12, 2018 at 6:08 PM, Logan Widick <logan.widick@gmail.com> wrote: > Last night, I briefly surveyed the listings of JWT implementations on jwt.io. I could find only a small handful that appeared to support all serializations, and even fewer that appeared to give programmers control over what serialization was produced. Thus, assuming jwt.io is a sufficiently accurate and comprehensive listing of implementations of all and/or part of the JOSE specs, the developers of many ACME client and server implementations may find themselves needing to convert between serializations before and/or after using JOSE libraries. Such conversion processes, if needed, should be well-documented somewhere. > > I've started on a very rough draft of a possible JWS and JWE serialization conversion guide at https://github.com/uhhhh2/jwe- jws-serialization-conversion-guide. I made the conversion guide draft by copying a few items from the ACME GitHub repository (the Markdown file, the makefile, and the .gitignore), replacing the text from the Markdown file, and renaming the Markdown file. I designed the conversion guide draft to be non-ACME specific, so I've tried to include things like unencoded JWS payloads, JWEs, multiple signatures, detached payloads, etc. If you have any changes or suggestions, please let me know. > > Logan > > On Fri, Jan 5, 2018 at 7:11 PM, Jörn Heissler < acme-specs@joern.heissler.de> wrote: > On Thu, Jan 04, 2018 at 08:03:55 -0600, Logan Widick wrote: > > What do you think of the following: > > > Content type application/jose+json: MUST be supported. If used, the JWS > > will need to be in the Flattened or General serialization. Flattened MUST > > be supported; General MAY be supported. > > > Content type application/jose: MAY be supported. If used, the JWS MUST use > > the Compact serialization. Or should this content type not be allowed? > > Agreed. I wouldn't disallow "compact". And it could be clarified: > > The server SHOULD use the "Content-Type" HTTP header as an indication > for the request format. > > > JWS Unprotected Header: Not currently used in ACME. Should this be banned > > in ACME? > > I don't see much sense in those. But some client implementations might > automatically add an unprotected header like e.g. "cty". > Maybe with a "SHOULD NOT"? > > > Multiple signatures: MAY be supported. > > > Should messages signed by both MAC keys and private keys be allowed? > > This is already forbidden. > > > What about Key IDs not issued by the CA? > > Or are multiple signatures more trouble than they're worth to the point of > > banning them entirely? > > > > Multiple signatures on messages that need to be signed by account key: At > > least one signature MUST be from the account key > > > > Multiple signatures on revokeCert: Should this be allowed? > > > > Multiple signatures on externalAccountBinding field of newAccount: Should > > it be possible to bind to multiple pre-existing accounts? Or should this > > not be allowed? > > > > Multiple signatures on newAccount: Not allowed? > > > > Multiple signatures on keyChange: Not allowed for outer or inner JWS? > > I see no use case. All the authentication is based on accounts and those > have exactly one keypair. Having multiple signatures would equal using > multiple accounts at the same time. That makes no sense to me. > Client libs would probably not generate multiple signatures > automatically. > Multiple signatures should be banned in my opinion. > > > JWS Unencoded Payload Option (RFC 7797): Not allowed? > > Yep, they would make things very complicated. > > > Conversion guide between the different JWS serialization formats: Is it > > completely safe to assume that any and all programmers given the JWS RFC, > > pre-existing JWS implementations with sufficient documentation, and > > pre-existing JSON libraries with sufficient documentation could figure out > > how to convert the serialization formats as needed? > > Why, yes! Of course every programmer can do that! ;-) > > > Or is the conversion > > guide necessary? If the guide is necessary, then include a reference to a > > separate new or pre-existing conversion guide. If the guide is necessary, > > and there is no pre-existing conversion guide, how should the new > > conversion guide be published? Should the new conversion guide be > > ACME-specific, or more general (possibly with coverage of JWE as well as > > JWS features not utilized in ACME)? > > It's not necessary, *most* programmers can figure it out. But it would > doubtlessly be helpful. E.g. I didn't consider the possibility to do > this conversion in an ACME implementation before/after using a preexisting > JOSE lib. > If such a guide were to be published, it should not be ACME-specific. > > > Cheers > Jörn > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme
- [Acme] Specify which JWS serialization is used Jörn Heissler
- Re: [Acme] Specify which JWS serialization is used Logan Widick
- Re: [Acme] Specify which JWS serialization is used Fraser Tweedale
- Re: [Acme] Specify which JWS serialization is used Logan Widick
- Re: [Acme] Specify which JWS serialization is used Logan Widick
- Re: [Acme] Specify which JWS serialization is used Jörn Heissler
- Re: [Acme] Specify which JWS serialization is used Logan Widick
- Re: [Acme] Specify which JWS serialization is used Logan Widick
- Re: [Acme] Specify which JWS serialization is used Jörn Heissler
- Re: [Acme] Specify which JWS serialization is used Logan Widick
- Re: [Acme] Specify which JWS serialization is used Logan Widick
- Re: [Acme] Specify which JWS serialization is used Richard Barnes
- Re: [Acme] Specify which JWS serialization is used Felipe Gasper
- Re: [Acme] Specify which JWS serialization is used Logan Widick
- Re: [Acme] Specify which JWS serialization is used Richard Barnes
- Re: [Acme] Specify which JWS serialization is used Jacob Hoffman-Andrews
- Re: [Acme] Specify which JWS serialization is used Logan Widick
- Re: [Acme] Specify which JWS serialization is used Jörn Heissler
- Re: [Acme] Specify which JWS serialization is used Jörn Heissler
- Re: [Acme] Specify which JWS serialization is used Logan Widick
- Re: [Acme] Specify which JWS serialization is used Jörn Heissler
- Re: [Acme] Specify which JWS serialization is used Logan Widick
- Re: [Acme] Specify which JWS serialization is used Richard Barnes
- Re: [Acme] Specify which JWS serialization is used Martin Thomson
- Re: [Acme] Specify which JWS serialization is used Martin Thomson
- Re: [Acme] Specify which JWS serialization is used Richard Barnes
- Re: [Acme] Specify which JWS serialization is used Martin Thomson
- Re: [Acme] Specify which JWS serialization is used Richard Barnes
- Re: [Acme] Specify which JWS serialization is used Martin Thomson
- [Acme] Concerning alternative formats … Felipe Gasper
- Re: [Acme] Concerning alternative formats … Jörn Heissler
- Re: [Acme] Concerning alternative formats … Felipe Gasper
- Re: [Acme] Concerning alternative formats … Matthew D. Hardeman
- Re: [Acme] Concerning alternative formats … Felipe Gasper
- Re: [Acme] Concerning alternative formats … Richard Barnes
- Re: [Acme] Concerning alternative formats … Martin Thomson
- Re: [Acme] Concerning alternative formats … Matthew D. Hardeman
- Re: [Acme] Concerning alternative formats … Felipe Gasper