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-c > onversion-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/j >> we-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
