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 <j...@eff.org> 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. >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme