Re: [Acme] Specify which JWS serialization is used

Jörn Heissler <acme-specs@joern.heissler.de> Sun, 04 March 2018 14:33 UTC

Return-Path: <acme-specs@joern.heissler.de>
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 E6BEF127201 for <acme@ietfa.amsl.com>; Sun, 4 Mar 2018 06:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.05
X-Spam-Level:
X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, SPF_PASS=-0.001] autolearn=no autolearn_force=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 HJXztWjqS4Mb for <acme@ietfa.amsl.com>; Sun, 4 Mar 2018 06:33:16 -0800 (PST)
Received: from lvps87-230-93-31.dedicated.hosteurope.de (kappa.tutnicht.de [87.230.93.31]) (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 139CF1243F6 for <acme@ietf.org>; Sun, 4 Mar 2018 06:33:05 -0800 (PST)
Received: from [10.255.0.6] (helo=carrot.tutnicht.de) by lvps87-230-93-31.dedicated.hosteurope.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <acme-specs@joern.heissler.de>) id 1esUhC-0006ah-AD; Sun, 04 Mar 2018 15:33:02 +0100
Date: Sun, 04 Mar 2018 15:33:00 +0100
From: Jörn Heissler <acme-specs@joern.heissler.de>
To: Logan Widick <logan.widick@gmail.com>
Cc: Richard Barnes <rlb@ipv.sx>, Felipe Gasper <felipe@felipegasper.com>, ACME WG <acme@ietf.org>, Fraser Tweedale <frase@frase.id.au>
Message-ID: <20180304143300.GI2161@carrot.tutnicht.de>
References: <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> <CAL02cgRrH9fG-E9_oc4naSNvE4igaUcs9wXDfTtCTUCx+c4wbg@mail.gmail.com> <20180304125854.GH2161@carrot.tutnicht.de> <CAMmAzEJ0A2iOd2ASSHGJRfuB6Ss-BaOCXWsxUKUZx9UUzbT1ng@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="/rDaUNvWv5XYRSKj"
Content-Disposition: inline
In-Reply-To: <CAMmAzEJ0A2iOd2ASSHGJRfuB6Ss-BaOCXWsxUKUZx9UUzbT1ng@mail.gmail.com>
User-Agent: Mutt/1.9.3 (2018-01-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/6NmEqKPB8gAk_jYdnCrtmlU5cSU>
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: Sun, 04 Mar 2018 14:33:18 -0000

On Sun, Mar 04, 2018 at 07:45:36 -0600, Logan Widick wrote:
> Good catch. Should it be 415 (Unsupported Media Type) plus which of the
> following (or which combination of the following):
> 
>    - A new problem document field (tentatively named
>    "supportedSerializations": an array of media type strings)?
>    - A new directory field (tentatively named "supportedSerializations": an
>    array of media type strings)?
>       - Should this go in the directory's "meta" object, or in the
>       directory object itself?
>    - A HTTP header?
>    - Something else?

I like the directory approach with meta. Then a client could
use this information before sending the first POST. Else the client
would need to change an internal state after receiving the error
message. For my own client, I'm planning to support the OpenPGP smart
card. It takes 3 seconds to generate a signature. If a signature is
wasted to find out that the default serialization is not supported, it
would be annoying. Having to write a configuration file "use compact by
default for CA foo" would be stupid too.

This, and the problem document field. "supportedSerializations" sounds
fine.

Should the two features be OPTIONAL?

I don't like HTTP headers, it's quite complicated to parse them correctly.
JSON is so much easier.


Or... specify that flattened MUST BE used :-)

Cheers
Joern Heissler