Re: [Acme] Specify which JWS serialization is used

Fraser Tweedale <frase@frase.id.au> Wed, 03 January 2018 23:47 UTC

Return-Path: <frase@frase.id.au>
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 062F5127201 for <acme@ietfa.amsl.com>; Wed, 3 Jan 2018 15:47:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 iF4yz0kqf1ZY for <acme@ietfa.amsl.com>; Wed, 3 Jan 2018 15:47:26 -0800 (PST)
Received: from captainmorgan.hollandpark.frase.id.au (110-174-235-130.static.tpgi.com.au [110.174.235.130]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73471241F8 for <acme@ietf.org>; Wed, 3 Jan 2018 15:47:25 -0800 (PST)
Received: from bacardi.hollandpark.frase.id.au (bacardi.hollandpark.frase.id.au [192.168.0.100]) by captainmorgan.hollandpark.frase.id.au (8.14.9/8.14.9) with ESMTP id w03NlMMk098474; Wed, 3 Jan 2018 23:47:22 GMT (envelope-from frase@frase.id.au)
Received: from bacardi.hollandpark.frase.id.au (localhost [127.0.0.1]) by bacardi.hollandpark.frase.id.au (8.15.2/8.15.2) with ESMTPS id w03NlMhV008170 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Jan 2018 09:47:22 +1000 (EST) (envelope-from frase@frase.id.au)
Received: (from fraser@localhost) by bacardi.hollandpark.frase.id.au (8.15.2/8.15.2/Submit) id w03NlJoU008169; Thu, 4 Jan 2018 09:47:19 +1000 (EST) (envelope-from frase@frase.id.au)
X-Authentication-Warning: bacardi.hollandpark.frase.id.au: fraser set sender to frase@frase.id.au using -f
Date: Thu, 04 Jan 2018 09:47:19 +1000
From: Fraser Tweedale <frase@frase.id.au>
To: acme@ietf.org
Cc: Jörn Heissler <acme-specs@joern.heissler.de>
Message-ID: <20180103234718.GA1340@bacardi.hollandpark.frase.id.au>
References: <20180103230734.GM21695@carrot.tutnicht.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN"
Content-Disposition: inline
In-Reply-To: <20180103230734.GM21695@carrot.tutnicht.de>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/Lij5m4nZ0XWziNm7_E39F6S676c>
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: Wed, 03 Jan 2018 23:47:28 -0000

On Thu, Jan 04, 2018 at 12:07:34AM +0100, Jörn Heissler wrote:
> Hello and happy new Year!
> 
> I've found an inaccuracy in the ACME specs.
> 
> https://tools.ietf.org/html/rfc7515#section-7 states:
> 
>     Applications using this specification need to specify what serialization
>     and serialization features are used for that application.
> 
> Although this is neither a "SHOULD" nor a "MUST", I think ACME should specify
> which serialization formats need to be supported by server implementations.
> 
> RFC7515 defines four serialization formats:
> 
> * JWS Compact Serialization
> * General JWS JSON Serialization Syntax
>   * One signature only
>   * Multiple signatures
> * Flattened JWS JSON Serialization Syntax
> 
> https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.6.2
> states:
> 
>     In the examples below, JWS objects are shown in the JSON or
>     flattened JSON serialization
> 
> All examples in the ACME specification use only the flattened serialization.
> Depending on the clarification above, this might need to be amended too.
> 
> Best regards
> Jörn Heissler

I am the author of a JOSE library, and have had to deal with
interoperability issues arising from the multiple serialisations and
underspecified applications/protocols.  Please heed my advice.

Where there is a choice of JSON serialisation (i.e. exactly one
signature), JOSE does not require or recommend a particular
serialisation be used.  Not does the specification require or
recommend that there be a mechanism for telling a library what JSON
serialisation to use.  The outcome of this is that there are:

- implementations that unconditionally produce the General JSON
  serialisation

- implementations that unconditionally produce the Flattened JSON
  serialisation (and do not support multiple signatures at all)

- implementations that produce the Flattened serialisation when
  there is a single signature, and the General JSON serialisation
  otherwise

Therefore for interoperability and to avoid situations where a
conforming JOSE library cannot be used for ACME, I suggest that ACME
adopt the following regime:

- Conforming ACME implementations MUST process JWS objects using the
  Flattened JWS JSON Serialization and SHOULD process JWS objects
  using the General JWS JSON Serialization.

- Conforming ACME implementations MAY refuse to process JWS objects
  with multiple signatures.  If an implementation accepts
  multiple-signature JWS objects, it MUST validate at least one
  signature using the account's public key.

Cheers,
Fraser