Could there be some way of using a header like “Accept” for a server to indicate whether it supports jose, jose+json, or both?
-F > On Mar 2, 2018, at 9:50 AM, Richard Barnes <r...@ipv.sx> wrote: > > Hey all, > > I merged #395 last night (thanks, Logan!). While I was reviewing that, I > noticed that we need to cover the case where the client sends an encoding > that the server doesn't understand. So I've posted a follow-on that adds an > error code and requires its usage. LMK if you have any objections, otherwise > I'll merge before submission on Monday. > > https://github.com/ietf-wg-acme/acme/pull/398 > > Thanks, > --Richard > > On Mon, Feb 12, 2018 at 2:37 PM, Logan Widick <logan.wid...@gmail.com> wrote: > I've created a new pull request > (https://github.com/ietf-wg-acme/acme/pull/395) to partially address the lack > of serialization format specification. This pull request requires use of the > Content-Type HTTP header to indicate the serialization format of the > outermost JWS. The pull request also includes restrictions on the > serializations (no detached payload, no unencoded payload, no unprotected > header, etc.). In addition, the pull request bans multiple signatures, > regardless of the serialization used. The use of the Content-Type header, and > the list of currently possible serializations, is mentioned in its own > subsection of "Message Transport". > > The pull request does not contain advice on how to convert different > serialization formats before and/or after use with a pre-existing JWS > library. I have started on a separate conversion guide > (https://github.com/uhhhh2/jwe-jws-serialization-conversion-guide) for that > purpose. > > The pull request does not specify how a "nested" JWS should be serialized. > However, I have included an outline of one possible approach to this in the > pull request's description. > > Please let me know what you think about the pull request > (https://github.com/ietf-wg-acme/acme/pull/395), and the separate conversion > guide (https://github.com/uhhhh2/jwe-jws-serialization-conversion-guide) > > Logan > > On Fri, Jan 12, 2018 at 6:08 PM, Logan Widick <logan.wid...@gmail.com> wrote: > Last night, I briefly surveyed the listings of JWT implementations on jwt.io. > I could find only a small handful that appeared to support all > serializations, and even fewer that appeared to give programmers control over > what serialization was produced. Thus, assuming jwt.io is a sufficiently > accurate and comprehensive listing of implementations of all and/or part of > the JOSE specs, the developers of many ACME client and server implementations > may find themselves needing to convert between serializations before and/or > after using JOSE libraries. Such conversion processes, if needed, should be > well-documented somewhere. > > I've started on a very rough draft of a possible JWS and JWE serialization > conversion guide at > https://github.com/uhhhh2/jwe-jws-serialization-conversion-guide. I made the > conversion guide draft by copying a few items from the ACME GitHub repository > (the Markdown file, the makefile, and the .gitignore), replacing the text > from the Markdown file, and renaming the Markdown file. I designed the > conversion guide draft to be non-ACME specific, so I've tried to include > things like unencoded JWS payloads, JWEs, multiple signatures, detached > payloads, etc. If you have any changes or suggestions, please let me know. > > Logan > > On Fri, Jan 5, 2018 at 7:11 PM, Jörn Heissler <acme-sp...@joern.heissler.de> > wrote: > On Thu, Jan 04, 2018 at 08:03:55 -0600, Logan Widick wrote: > > What do you think of the following: > > > Content type application/jose+json: MUST be supported. If used, the JWS > > will need to be in the Flattened or General serialization. Flattened MUST > > be supported; General MAY be supported. > > > Content type application/jose: MAY be supported. If used, the JWS MUST use > > the Compact serialization. Or should this content type not be allowed? > > Agreed. I wouldn't disallow "compact". And it could be clarified: > > The server SHOULD use the "Content-Type" HTTP header as an indication > for the request format. > > > JWS Unprotected Header: Not currently used in ACME. Should this be banned > > in ACME? > > I don't see much sense in those. But some client implementations might > automatically add an unprotected header like e.g. "cty". > Maybe with a "SHOULD NOT"? > > > Multiple signatures: MAY be supported. > > > Should messages signed by both MAC keys and private keys be allowed? > > This is already forbidden. > > > What about Key IDs not issued by the CA? > > Or are multiple signatures more trouble than they're worth to the point of > > banning them entirely? > > > > Multiple signatures on messages that need to be signed by account key: At > > least one signature MUST be from the account key > > > > Multiple signatures on revokeCert: Should this be allowed? > > > > Multiple signatures on externalAccountBinding field of newAccount: Should > > it be possible to bind to multiple pre-existing accounts? Or should this > > not be allowed? > > > > Multiple signatures on newAccount: Not allowed? > > > > Multiple signatures on keyChange: Not allowed for outer or inner JWS? > > I see no use case. All the authentication is based on accounts and those > have exactly one keypair. Having multiple signatures would equal using > multiple accounts at the same time. That makes no sense to me. > Client libs would probably not generate multiple signatures > automatically. > Multiple signatures should be banned in my opinion. > > > JWS Unencoded Payload Option (RFC 7797): Not allowed? > > Yep, they would make things very complicated. > > > Conversion guide between the different JWS serialization formats: Is it > > completely safe to assume that any and all programmers given the JWS RFC, > > pre-existing JWS implementations with sufficient documentation, and > > pre-existing JSON libraries with sufficient documentation could figure out > > how to convert the serialization formats as needed? > > Why, yes! Of course every programmer can do that! ;-) > > > Or is the conversion > > guide necessary? If the guide is necessary, then include a reference to a > > separate new or pre-existing conversion guide. If the guide is necessary, > > and there is no pre-existing conversion guide, how should the new > > conversion guide be published? Should the new conversion guide be > > ACME-specific, or more general (possibly with coverage of JWE as well as > > JWS features not utilized in ACME)? > > It's not necessary, *most* programmers can figure it out. But it would > doubtlessly be helpful. E.g. I didn't consider the possibility to do > this conversion in an ACME implementation before/after using a preexisting > JOSE lib. > If such a guide were to be published, it should not be ACME-specific. > > > Cheers > Jörn > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
