Re: [Acme] Specify which JWS serialization is used
Richard Barnes <rlb@ipv.sx> Fri, 02 March 2018 22:29 UTC
Return-Path: <rlb@ipv.sx>
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 3F32C126BF7 for <acme@ietfa.amsl.com>; Fri, 2 Mar 2018 14:29:10 -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=ipv-sx.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 taJmknJVNvli for <acme@ietfa.amsl.com>; Fri, 2 Mar 2018 14:29:07 -0800 (PST)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 7B9541250B8 for <acme@ietf.org>; Fri, 2 Mar 2018 14:29:06 -0800 (PST)
Received: by mail-wr0-x231.google.com with SMTP id o76so11558189wrb.7 for <acme@ietf.org>; Fri, 02 Mar 2018 14:29:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dJCMf2iP5DLy43RGLBEfv/hMhIQJCFdbWe4XguDRPaA=; b=Ys/JtNar1zPFGKWw+YhrNMwmG5pyCAOGuRPdYeQWi3ue6agsiiIU8YnO8jVdwN5deF WbWyKzrjAzFie768R708rjYv17ix2fRsqO+S9czv0kURrVBMzhrKk6TavvquRbX3XhQz o6u8lpYRoW+SByKYxFu7jWIyoT4Ad0qdQtoIvtN61Edx8c/rM8HcOekowiDxkyr+Wa2q m7z45W80uCpb7KyXQE845zZbVI0R2ypRBy/sSgKURVh4KVtA9XrWuGO/nyIfWk4Q0m9j l2Kr3N0KJz9NJ4P+XV/MZkWgYeqftbUHmFrbcW3RvXzYwM3oiofhScF7YA67Ka00Qk9y jrjw==
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=dJCMf2iP5DLy43RGLBEfv/hMhIQJCFdbWe4XguDRPaA=; b=er4j5QNkLQjV7WJ3J8q/AUso9c3mIQxBrMJFaAhoR9DcXJ7KoltMpYs9QH3808Dmpp UZtyK+9FCyQ1tgXFDF/f6xMutfnHlJYrfLxn4mk5ImTItT8eWrZoIfLOIYFnyU4twFkc gXiyXYuZn669VL46y3ERsF+pn14EDAybYi6brnUVQh38A7I1VXb0dh+MA0Ex5shK2zAv LgcWt3vPlH/xoG6JBEp2EUo9O8RJM1Qk8uPCVAkCbMXNoypT1VnQPXqY2VnCAmsgWqJu A3jjPiY+D94OZyeL+7ywL26wlD2mnky4y0p7tkqj1uhBuUhrfALzSuWX/Y7Qv2kSm2kl r+LA==
X-Gm-Message-State: APf1xPA3elpb8YjY//Hab72UBjbHTeO/OsCduCqqpS6gSLVvwMOkPmg1 /XMqPnH7EMIbIUW/XukmJOxTqFRBsOz7UQIrfqlonA==
X-Google-Smtp-Source: AG47ELt76hAk1kr6x+diaqNyR5twsqWA7N/D5XLLrCsV2jKBMQDE2IpGIqRMxfXyRldJhfMqlVdPmyeCa5x5f5pQ3kQ=
X-Received: by 10.223.171.167 with SMTP id s36mr5870116wrc.52.1520029744876; Fri, 02 Mar 2018 14:29:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.12.140 with HTTP; Fri, 2 Mar 2018 14:29:04 -0800 (PST)
In-Reply-To: <CAMmAzEKksnuBi0LPHsAsd2qs1brbMqrJBdtsbArTr6HhGrkN+A@mail.gmail.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> <CAMmAzEKksnuBi0LPHsAsd2qs1brbMqrJBdtsbArTr6HhGrkN+A@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 02 Mar 2018 17:29:04 -0500
Message-ID: <CAL02cgRrH9fG-E9_oc4naSNvE4igaUcs9wXDfTtCTUCx+c4wbg@mail.gmail.com>
To: Logan Widick <logan.widick@gmail.com>
Cc: Felipe Gasper <felipe@felipegasper.com>, ACME WG <acme@ietf.org>, Jörn Heissler <acme-specs@joern.heissler.de>, Fraser Tweedale <frase@frase.id.au>
Content-Type: multipart/alternative; boundary="001a113b37b6fde651056675804e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/ipdmXRTERYMh8jQokJmTpN1g9jg>
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 22:29:10 -0000
On Fri, Mar 2, 2018 at 2:29 PM, Logan Widick <logan.widick@gmail.com> wrote: > I think the follow-on (#398) includes the Accept header in error responses > (to requests with unacceptable serializations). > Indeed it does! > 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). > If you have suggestions here, a PR would be welcome. TBH, this issue kind of makes me want to reverse course and say "all flattened JSON", but I get the sense that other folks disagree? --Richard > > 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-ac > me/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