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 <r...@ipv.sx> 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 <martin.thom...@gmail.com> > 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 <r...@ipv.sx> 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 >> > <martin.thom...@gmail.com> >> > 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" <r...@ipv.sx> 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 <logan.wid...@gmail.com> >> >> 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 >> >>> <acme-sp...@joern.heissler.de> 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 >> >>> >> >>> >> >> >> >> >> > > > _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
