Re: [Acme] Specify which JWS serialization is used

[Logan Widick <[e-mail]>]

I don't really have a preference for which serializations are used, as long
as all ACME implementations (regardless of the programming language used)
can support the chosen serializations, and new serializations can be added
later if necessary.

When I searched the listings on GitHub and jwt.io a month or two ago, I
found some JOSE libraries that didn't support reading all serialization
formats, and/or didn't provide programmers with control over the format
produced. Thus, serialization may still be an issue unless one can convert
between serializations before and/or after using such libraries.

Here is a PR for one possible way to resolve the "root JWS" and "nested
JWS" issue: https://github.com/ietf-wg-acme/acme/pull/403 . This PR
includes the following:

   - Initial definitions of "root JWS" and "nested JWS"
   - Updated requirement for "root JWS" and "nested JWS" under the two
   currently defined content types (application/jose and application/jose+json)
   - Revisions to the registries already defined in the spec (to label
   nested JWS things as such and indicate that the actual types may change
   depending on the serialization formats used)
   - A new serializations registry (so that serializations can be added as
   needed)
      - I put it as a new registry under the "New Registries" section
      because it includes ACME-specific constraints on existing content types
      instead of new content types.
      - I have no experience adding new material to an IANA Considerations
      section. I'm not sure if I put the new material in the right place,
      formatted it correctly, included all required information (like what
      guidance, if any, should be provided), etc.

If it is decided to change course and stick with one serialization format
for now, I can make the following changes to this PR:

   - Clean up the "JWS Serialization Formats" section:
      - In PR #403 as it is today:
         -  "One of the following Content-Type header values MUST be used
         to indicate the JWS serialization format"
         - This section includes a list describing the requirements for
         both JSON (Flattened and General) and Compact Serializations
      - To change course:
         - "The following Content-Type header value MUST be used to
         indicate the JWS serialization format"
         - Delete the unused serialization format from the list
      - Delete the unnecessary format from the new serializations registry

Let me know what you think of this PR.

Logan



On Fri, Mar 2, 2018 at 4:51 PM, Jacob Hoffman-Andrews <[e-mail]> wrote:

>
> 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?
>
> I'd be very much in favor of "all flattened JSON." When we started ACME, I
> think there was some concern that libraries might support only Compact
> Serialization (https://tools.ietf.org/html/rfc7515#section-7.1). But
> experience has shown that Flattened JSON Serialization (
> https://tools.ietf.org/html/rfc7515#section-7.2.2) is pretty well
> supported across languages.
>
> FWIW, Let's Encrypt's ACMEv2 endpoint only supports Flattened JSON
> Serialization.
>