Re: [Acme] Specify which JWS serialization is used

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 wrote: > I also note that there's no issue with Accept if we

Re: [Acme] Specify which JWS serialization is used

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 wrote: > That's a bit silly. I'll

Re: [Acme] Specify which JWS serialization is used

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 wrote: > How

Re: [Acme] Specify which JWS serialization is used

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 wrote: > 415 is for the case where a client

Re: [Acme] Specify which JWS serialization is used

There needs to be a stronger benefit demonstrated than this. As Richard says, implementing flat serialization is near trivial. Rather than add more complexity, settling on precisely one format solves the problem neatly. On 5 Mar. 2018 02:43, "Logan Widick" wrote: How

Re: [Acme] Specify which JWS serialization is used

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" wrote: The lengths of the emails in this thread illustrate the complexity

Re: [Acme] Specify which JWS serialization is used

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

Re: [Acme] Example requests

Hey Joern, This is a probably a good thing to have. I think that rather than putting these in the main spec, it might be better to have them in a second draft. This is a pretty common pattern. For example, for TLS 1.3, there's a "test vectors" document separate from the main spec [0]. There

[Acme] Example requests

Hello, I'm not sure if this should be included, so not making a PR yet. Complete examples for requests may help implementers (of both servers and clients) to understand the specifications. All existing examples have pseudo-code like base64url({...}) and no untruncated keys or signatures. I

[Acme] I-D Action: draft-ietf-acme-email-smime-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment WG of the IETF. Title : Extensions to Automatic Certificate Management Environment for end user S/MIME certificates

Re: [Acme] Specify which JWS serialization is used

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

Re: [Acme] Specify which JWS serialization is used

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

Re: [Acme] Specify which JWS serialization is used

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

Re: [Acme] Specify which JWS serialization is used

On Fri, Mar 02, 2018 at 17:29:04 -0500, Richard Barnes wrote: > > On Mar 2, 2018 9:47 AM, "Felipe Gasper" wrote: > > > > Could there be some way of using a header like “Accept” for a server to > > indicate whether it supports jose, jose+json, or both? > On Fri, Mar 2,

[Acme] Explicitly forbid to answer GET requests for account info

Hi, another PR that slightly changes meaning (SHOULD NOT -> MUST NOT): https://github.com/ietf-wg-acme/acme/pull/407 Section "Request Authentication" says: "Servers MUST NOT respond to GET requests for resources that might be considered sensitive. Account resources are the only sensitive

Re: [Acme] Specify which JWS serialization is used

On Thu, Jan 04, 2018 at 00:07:34 +0100, Jörn Heissler wrote: > 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

[Acme] Include finalize step in Protocol Overview

Hi, I filed a PR (https://github.com/ietf-wg-acme/acme/pull/408) that adds the finalization step to the Protocol Overview. I assume when this section was orignally written, CSR was submitted as part of the order request. Cheers Joern Heissler signature.asc Description: PGP signature