Re: [Acme] Specify which JWS serialization is used

[Richard Barnes <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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 <
>> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>
>