Subject: [Acme] Specify which JWS serialization is used

From: Jörn Heissler <[email-masked]>
Date: Thu, 4 Jan 2018 00:07:34 +0100

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

---

From: Logan Widick <[email-masked]>
Date: Wed, 3 Jan 2018 17:30:39 -0600

I agree that a serialization format (or set of formats) would need to be
standardized. Related thread:
https://www.ietf.org/mail-archive/web/acme/current/msg01690.html

Sincerely,

Logan Widick

On Wed, Jan 3, 2018 at 5:07 PM, Jörn Heissler <[email-masked]>
wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Fraser Tweedale <[email-masked]>
Date: Thu, 4 Jan 2018 09:47:19 +1000

> Depending on the clarification above, this might need to be amended too.

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

---

From: Logan Widick <[email-masked]>
Date: Wed, 3 Jan 2018 18:21:04 -0600

This looks good to me.

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.

Logan

---

From: Logan Widick <[email-masked]>
Date: Wed, 3 Jan 2018 19:51:53 -0600

Here is a pull request: https://github.com/ietf-wg-acme/acme/pull/382

Let me know what you think.

Sincerely,

Logan Widick

---

From: Jörn Heissler <[email-masked]>
Date: Thu, 4 Jan 2018 12:02:04 +0100

>   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

> +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.

>    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

---

From: Logan Widick <[email-masked]>
Date: Thu, 4 Jan 2018 08:03:55 -0600

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?

JWS Unprotected Header: Not currently used in ACME. Should this be banned
in ACME?

Multiple signatures: MAY be supported. Should messages signed by both MAC
keys and private keys be allowed? 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?

JWS Unencoded Payload Option (RFC 7797): Not allowed?

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? 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)?

Sincerely,
Logan Widick

---

From: Logan Widick <[email-masked]>
Date: Thu, 4 Jan 2018 09:21:52 -0600

To the best of my knowledge, the ACME signature solution was not fully
addressed years ago.

As far as I know, the only requirements for signatures discussed and
explicitly specified in the text of the ACME draft are:
Use JWS signatures (not JCS signatures) over HTTPS
Don't use the "none" algorithm
Use certain fields in the protected header as specified in the text
Use JSON objects specified in the text as the payloads
Don't use MAC keys/algorithms (with the exception of the value of the
externalAccountBinding field which is a JWS with a MAC signature).

(Related issues: If compact serialization is allowed, does the
externalAccountBinding change from an object to a string to indicate
compact serialization? What if this field is using an unsupported
serialization?)

Some things appear to be implied by the examples in the draft but don't
appear to be explicitly specified in the text of the draft (at least not
the current one), such as:
Use JSON serialization (most likely flattened but JWS implementations may
not give programmers control over this)
Don't use unprotected headers
Don't use the unencoded payload option
Don't use multiple signatures (except perhaps in previous drafts that I
think had multi-signature key changes instead of the nested key changes in
the current draft).

Implied in the examples but not explicitly specified in the text may hinder
interoperability.

I think ACME is in a last call.

Logan

On Jan 4, 2018 8:19 AM, "Anders Rundgren" <[email-masked]>
wrote:

> I thought the ACME signature solution was addressed years ago.  Isn't ACME
> in last call?
>
> F.Y.I.
> https://cyberphone.github.io/doc/security/jose-jcs.html#Sample_Signature
>
> Anders
>
> On 2018-01-04 15:03, Logan Widick wrote:
>
>> Content type application/jose: MAY be supported. If used, the JWS MUST
>> use the Compact serialization. Or should this content type not be allowed?
>>
>> On Jan 4, 2018 5:02 AM, "Jörn Heissler" <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>      >    request: [1]https://github.com/ietf-wg-acme/acme/pull/382 <
>> https://github.com/ietf-wg-acme/acme/pull/382>

---

From: Jörn Heissler <[email-masked]>
Date: Sat, 6 Jan 2018 01:11:26 +0100

> 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

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?

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.

> how to convert the serialization formats as needed?

Why, yes! Of course every programmer can do that! ;-)

> Or is the conversion

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

---

From: Logan Widick <[email-masked]>
Date: Fri, 12 Jan 2018 19:08:47 -0500

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 <[email-masked]>
wrote:

> use