Re: [Acme] Specify which JWS serialization is used

[Martin Thomson <[e-mail]>]

Unless you believe that an alternative format is ever desirable.  CBOR
for version 2 might be a terrible idea, but I know the IETF well
enough not to rule that out entirely.

On Mon, Mar 5, 2018 at 3:38 PM, Richard Barnes <[e-mail]> wrote:
> I also note that there's no issue with Accept if we require the use of the
> Flattened JSON serialization.
>
> https://i.imgflip.com/25r2ui.jpg
>
> https://github.com/ietf-wg-acme/acme/pull/410
>
> On Sun, Mar 4, 2018 at 6:28 PM, Martin Thomson <[e-mail]>
> wrote:
>>
>> That's a bit silly.  I'll follow-up with httpbis.  I think that's an
>> error, though probably only an error of omission.  7694 was so fixated
>> on solving the content-coding issue, it neglected the obvious
>> accompanying fix.
>>
>> On Mon, Mar 5, 2018 at 9:38 AM, Richard Barnes <[e-mail]> wrote:
>> > How about Accept?  It looks like 7694 gives the server a way to specify
>> > encodings, but not the content type.  But 7231 says that Accept only
>> > replies
>> > to response media types.
>> >
>> > On Sun, Mar 4, 2018 at 5:33 PM, Martin Thomson
>> > <[e-mail]>
>> > wrote:
>> >>
>> >> 415 is for the case where a client provides bad request content, so
>> >> yes.
>> >> See rfc7694 for details.
>> >>
>> >>  406 is for failed conneg. Not something you expect to see much here.
>> >>
>> >>
>> >> On 5 Mar. 2018 09:25, "Richard Barnes" <[e-mail]> wrote:
>> >>
>> >> The lengths of the emails in this thread illustrate the complexity risk
>> >> here :)
>> >>
>> >> In the interest of simplicity, I would really like to stick to
>> >> Flattened
>> >> JSON unless someone has **strong** objections.
>> >>
>> >> Logan, to your point about library compatibility, two notes: (1) it's
>> >> OK
>> >> if we front-run libraries a little.  It's not hard for libraries to
>> >> upgrade;
>> >> this is only formatting, no crypto changes needed.  (2) Empirically,
>> >> this
>> >> must not be too big a blocker for people, since as Jacob notes, Let's
>> >> Encrypt only supports Flattened JSON right now and they've got a bunch
>> >> of
>> >> clients talking to them.
>> >>
>> >> As far as headers / response codes: You're correct that 406 is wrong /
>> >> 415
>> >> is right.  But ISTM that Accept is still the right header to say what
>> >> is
>> >> right.  So the server should return 415+Accept.  Copying Thomson to
>> >> check
>> >> our work here.
>> >>
>> >> --Richard
>> >>
>> >> On Sun, Mar 4, 2018 at 10:43 AM, Logan Widick <[e-mail]>
>> >> wrote:
>> >>>
>> >>> How about this: Specify a default format (either "application/jose"
>> >>> for
>> >>> Compact Serialization, or "application/jose+json" with Flattened
>> >>> Serialization - I have no preference which one), with optional support
>> >>> for
>> >>> other formats if needed? Even with JOSE libraries that don't support
>> >>> all
>> >>> serializations and/or don't provide control over which serialization
>> >>> is
>> >>> used, a programmer would at least need to know (or experimentally find
>> >>> out)
>> >>> if a JSON serialization or if the compact one is being produced. If a
>> >>> JSON
>> >>> serialization is selected as the default, a programmer should be able
>> >>> to
>> >>> convert between the two JSON serializations easily as needed before
>> >>> and/or
>> >>> after using a JOSE library. If a JSON format is declared as the
>> >>> default but
>> >>> the JOSE library only has the compact one, or vice-versa, conversion
>> >>> before
>> >>> and/or after the JOSE library would be more complex but should still
>> >>> be
>> >>> doable with guidance.
>> >>>
>> >>> The directory meta item could be defined as something like:
>> >>>
>> >>> supportedSerializations: An array of supported serialization formats
>> >>> as
>> >>> described in {{jws-serialization-formats}}. If this is not specified,
>> >>> assume
>> >>> that the server only supports [insert selected default here].
>> >>>
>> >>> Then, the JWS Serialization Formats section could be changed to
>> >>> something
>> >>> like the following:
>> >>>
>> >>> The JSON Web Signature (JWS) specification {{!RFC7515}} contains
>> >>> multiple
>> >>> JWS serialization formats. When sending an ACME request with a
>> >>> non-empty
>> >>> body, an ACME client implementation SHOULD use the HTTP Content-Type
>> >>> {{!RFC7231}} header to indicate which JWS serialization format is used
>> >>> for
>> >>> encapsulating the ACME request payload.
>> >>>
>> >>> Each serialization format defined for use in ACME is described with a
>> >>> content type, and a series of ACME-specific restrictions on root JWS
>> >>> and
>> >>> nested JWS instances.  A "root JWS" is a JWS used to encapsulate an
>> >>> entire
>> >>> ACME request payload, and a "nested JWS" is a JWS contained within the
>> >>> ACME
>> >>> request payload (such as the "externalAccountBinding" described in
>> >>> {{external-account-binding}} or the "key-change" object described in
>> >>> {{account-key-roll-over}}). Below are the JWS serialization formats
>> >>> that are
>> >>> defined for use in ACME:
>> >>>
>> >>> [same list as before but with the default format coming first]
>> >>>
>> >>> If no Content-Type is provided, the default serialization type is
>> >>> [insert
>> >>> selected default here]. Servers MUST support [insert selected default
>> >>> here].
>> >>> [NOTE: If a JSON format is selected as the default, say that a server
>> >>> SHOULD
>> >>> support the other JSON format.] A server MAY support additional
>> >>> serializations, such as [insert serialization(s) not picked here], by
>> >>> including a "supportedSerializations" field in the directory "meta"
>> >>> object
>> >>> as described in {{directory}}.
>> >>>
>> >>> If a server receives a request using a serialization it does not
>> >>> support,
>> >>> the server MUST send a response with HTTP status code 415
>> >>> (Unacceptable
>> >>> Media Type) and a problem document with error type
>> >>> "unsupportedSerialization". This problem document SHOULD contain a
>> >>> "supportedSerializations" array of strings indicating the acceptable
>> >>> serialization content types.
>> >>>
>> >>> [TODO: If a client uses the General JSON Serialization but it turns
>> >>> out
>> >>> the server only supports the Flattened JSON Serialization (or
>> >>> vice-versa),
>> >>> explain that a 415 response indicates that the client will need to
>> >>> switch
>> >>> JSON formats]
>> >>>
>> >>> [TODO: Insert a sentence or two specifying what happens if a supported
>> >>> serialization is used but the serialization is malformed? Should this
>> >>> be 400
>> >>> Bad Request + malformed error code + supportedSerializations?]
>> >>>
>> >>> In the examples below, JWS objects are shown in the Flattened JSON
>> >>> serialization, with the protected header and payload expressed as
>> >>> base64url(content) instead of the actual base64-encoded value, so that
>> >>> the
>> >>> content is readable. [Example readability is a very high priority
>> >>> regardless
>> >>> of which serialization format is actually chosen as the default, and
>> >>> the
>> >>> current convention of Flattened JSON + base64url(content) is about as
>> >>> readable as it gets, so I don't think any changes will need to be made
>> >>> here]
>> >>>
>> >>>
>> >>> On Sun, Mar 4, 2018 at 8:33 AM, Jörn Heissler
>> >>> <[e-mail]> wrote:
>> >>>>
>> >>>> On Sun, Mar 04, 2018 at 07:45:36 -0600, Logan Widick wrote:
>> >>>> > Good catch. Should it be 415 (Unsupported Media Type) plus which of
>> >>>> > the
>> >>>> > following (or which combination of the following):
>> >>>> >
>> >>>> >    - A new problem document field (tentatively named
>> >>>> >    "supportedSerializations": an array of media type strings)?
>> >>>> >    - A new directory field (tentatively named
>> >>>> > "supportedSerializations": an
>> >>>> >    array of media type strings)?
>> >>>> >       - Should this go in the directory's "meta" object, or in the
>> >>>> >       directory object itself?
>> >>>> >    - A HTTP header?
>> >>>> >    - Something else?
>> >>>>
>> >>>> I like the directory approach with meta. Then a client could
>> >>>> use this information before sending the first POST. Else the client
>> >>>> would need to change an internal state after receiving the error
>> >>>> message. For my own client, I'm planning to support the OpenPGP smart
>> >>>> card. It takes 3 seconds to generate a signature. If a signature is
>> >>>> wasted to find out that the default serialization is not supported,
>> >>>> it
>> >>>> would be annoying. Having to write a configuration file "use compact
>> >>>> by
>> >>>> default for CA foo" would be stupid too.
>> >>>>
>> >>>> This, and the problem document field. "supportedSerializations"
>> >>>> sounds
>> >>>> fine.
>> >>>>
>> >>>> Should the two features be OPTIONAL?
>> >>>>
>> >>>> I don't like HTTP headers, it's quite complicated to parse them
>> >>>> correctly.
>> >>>> JSON is so much easier.
>> >>>>
>> >>>>
>> >>>> Or... specify that flattened MUST BE used :-)
>> >>>>
>> >>>> Cheers
>> >>>> Joern Heissler
>> >>>
>> >>>
>> >>
>> >>
>> >
>
>