Re: [Acme] Specify which JWS serialization is used

Jörn Heissler <acme-specs@joern.heissler.de> Thu, 04 January 2018 11:02 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 D99A7120727 for <acme@ietfa.amsl.com>; Thu, 4 Jan 2018 03:02:13 -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 ehDYLpXibKVn for <acme@ietfa.amsl.com>; Thu, 4 Jan 2018 03:02:11 -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 599051200C5 for <acme@ietf.org>; Thu, 4 Jan 2018 03:02:09 -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 1eX3Hi-0003fF-HG; Thu, 04 Jan 2018 12:02:06 +0100
Date: Thu, 04 Jan 2018 12:02:04 +0100
From: Jörn Heissler <acme-specs@joern.heissler.de>
To: Logan Widick <logan.widick@gmail.com>
Cc: Fraser Tweedale <frase@frase.id.au>, ACME WG <acme@ietf.org>
Message-ID: <20180104110204.GP21695@carrot.tutnicht.de>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="h/77pM/XNBmEJr8g"
Content-Disposition: inline
In-Reply-To: <CAMmAzEKSv1pbKC80JLpRQxTrGApc7KVu6A7cqDp-Tmrcq4vvLg@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/DEOICacDv7n89Hse_QzcEqmRvV0>
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: Thu, 04 Jan 2018 11:02:14 -0000

On Thu, Jan 04, 2018 at 09:47:19 +1000, Fraser Tweedale wrote:
> 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.

This would work for me. I'm currently writing a new client (We need more
ACME clients!) and I'd prefer to stick to a single hard coded
serialization format which works with every conforming CA. Adding
flexibility (Use "flat" for this CA, use "general" for that CA, etc.)
would be troublesome.

But I'm worried about client implementations that use the next best JOSE
library which "unconditionally produces the General JSON serialisation".
Most CAs would support it ("SHOULD"). But some might decide not to:
"Yeah, we SHOULD support this. But our JOSE library only understands
the flat format and everyone but YOU does use the flat format".
Then who's to blame, the client or the CA?

Should this be changed to "MUST" or to "MAY"?
I.e. "flat" MUST be supported, "general" MUST/MAY be supported,
"compact" MAY be supported but needs a "application/jose" content type.


On Wed, Jan 03, 2018 at 19:51:53 -0600, Logan Widick wrote:
>    Here is a pull
>    request: [1]https://github.com/ietf-wg-acme/acme/pull/382
>    Let me know what you think.

> +Conforming ACME implementations MUST NOT process JWS objects using
> +the Compact JWS Serialization.

I think "compact" should be acceptable ("MAY process") iff the client sends
a "Content-Type: application/jose" header.

>    As for using JOSE implementations that lack support for the JSON
>    serialization formats (and only support the compact one), is there an
>    RFC, Internet-Draft, or similar document with an explanation of the
>    conversion process already prepared (that can simply be thrown into the
>    ACME draft's references section)? Or would it be necessary to include
>    an appendix in the ACME draft with an outline of the conversion
>    process? The conversion process looks fairly straightforward. However,
>    it would be nice if there was a document or part of a document that
>    could be easily referenced.

Your conversion guide sounds good. But personally I'd move this to a
separate document (like you were looking for) because it would be useful
in non-ACME related applications too.

Cheers,
Jörn