Re: [Acme] Specify which JWS serialization is used

[Martin Thomson]

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 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 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 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 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 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 
>> >> 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 

Re: [Acme] Specify which JWS serialization is used

[Richard Barnes]

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 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 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 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 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 
> >> 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 

Re: [Acme] Specify which JWS serialization is used

[Martin Thomson]

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 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 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 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 
>> 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 

Re: [Acme] Specify which JWS serialization is used

[Richard Barnes]

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 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 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 
> 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
>> 

Re: [Acme] Specify which JWS serialization is used

[Martin Thomson]

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 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 
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 

Re: [Acme] Specify which JWS serialization is used

[Martin Thomson]

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 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 
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 

Re: [Acme] Specify which JWS serialization is used

[Richard Barnes]

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 
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 

Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

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 
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 

Re: [Acme] Specify which JWS serialization is used

[Jörn Heissler]

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


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

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?

Logan


On Sun, Mar 4, 2018 at 6:58 AM, Jörn Heissler 
wrote:

> 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, 2018 at 2:29 PM, Logan Widick 
> wrote:
> >
> > > I think the follow-on (#398) includes the Accept header in error
> responses
> > > (to requests with unacceptable serializations).
> > >
> >
> > Indeed it does!
>
> The way I understand https://tools.ietf.org/html/rfc7231#section-6.5.6
> the 406 status and the Accept header are only valid to negotiate
> server-to-client
> content types.
>
> Is it really okay to use them for client-to-server?
> I think code 415 "Unsupported Media Type" is more appropriate:
> https://tools.ietf.org/html/rfc7231#section-6.5.13
> Together with an error document specifying the supported JWS
> serializations.
>
> Cheers
> Joern Heissler
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Specify which JWS serialization is used

[Jörn Heissler]

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, 2018 at 2:29 PM, Logan Widick  wrote:
> 
> > I think the follow-on (#398) includes the Accept header in error responses
> > (to requests with unacceptable serializations).
> >
> 
> Indeed it does!

The way I understand https://tools.ietf.org/html/rfc7231#section-6.5.6
the 406 status and the Accept header are only valid to negotiate 
server-to-client
content types.

Is it really okay to use them for client-to-server?
I think code 415 "Unsupported Media Type" is more appropriate:
https://tools.ietf.org/html/rfc7231#section-6.5.13
Together with an error document specifying the supported JWS
serializations.

Cheers
Joern Heissler


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Specify which JWS serialization is used

[Jörn Heissler]

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 use only the flattened serialization.

I opened a PR for this: https://github.com/ietf-wg-acme/acme/pull/406


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Specify which JWS serialization is used

[Jacob Hoffman-Andrews]

> If you have suggestions here, a PR would be welcome.  TBH, this issue
> kind of makes me want to reverse course and say "all flattened JSON",
> but I get the sense that other folks disagree?
I'd be very much in favor of "all flattened JSON." When we started ACME,
I think there was some concern that libraries might support only Compact
Serialization (https://tools.ietf.org/html/rfc7515#section-7.1). But
experience has shown that Flattened JSON Serialization
(https://tools.ietf.org/html/rfc7515#section-7.2.2) is pretty well
supported across languages.

FWIW, Let's Encrypt's ACMEv2 endpoint only supports Flattened JSON
Serialization.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

I think the follow-on (#398) includes the Accept header in error responses
(to requests with unacceptable serializations).

Also, there may need to be another follow-on regarding how to serialize
"nested" JWS instances (like the externalAccountBinding and the inner JWS
for a key change).

Logan

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?

-F

> On Mar 2, 2018, at 9:50 AM, Richard Barnes  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 
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/u2/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/u2/jwe-jws-serialization-conversion-guide)
>
> Logan
>
> On Fri, Jan 12, 2018 at 6:08 PM, Logan Widick 
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/u2/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 

Re: [Acme] Specify which JWS serialization is used

[Felipe Gasper]

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  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  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/u2/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/u2/jwe-jws-serialization-conversion-guide)
> 
> Logan
> 
> On Fri, Jan 12, 2018 at 6:08 PM, Logan Widick  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/u2/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  
> 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 

Re: [Acme] Specify which JWS serialization is used

[Richard Barnes]

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 
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/u2/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/u2/jwe-jws-serialization-c
> onversion-guide)
>
> Logan
>
> On Fri, Jan 12, 2018 at 6:08 PM, Logan Widick 
> 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/u2/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 

Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

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/u2/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/u2/jwe-jws-serialization-conversion-guide)

Logan

On Fri, Jan 12, 2018 at 6:08 PM, Logan Widick 
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/u2/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 

Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

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/u2/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 
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

Re: [Acme] Specify which JWS serialization is used

[Jörn Heissler]

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


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

To the best of my knowledge, the ACME signature solution was not fully
addressed years ago.

As far as I know, the only requirements for signatures discussed and
explicitly specified in the text of the ACME draft are:
Use JWS signatures (not JCS signatures) over HTTPS
Don't use the "none" algorithm
Use certain fields in the protected header as specified in the text
Use JSON objects specified in the text as the payloads
Don't use MAC keys/algorithms (with the exception of the value of the
externalAccountBinding field which is a JWS with a MAC signature).

(Related issues: If compact serialization is allowed, does the
externalAccountBinding change from an object to a string to indicate
compact serialization? What if this field is using an unsupported
serialization?)

Some things appear to be implied by the examples in the draft but don't
appear to be explicitly specified in the text of the draft (at least not
the current one), such as:
Use JSON serialization (most likely flattened but JWS implementations may
not give programmers control over this)
Don't use unprotected headers
Don't use the unencoded payload option
Don't use multiple signatures (except perhaps in previous drafts that I
think had multi-signature key changes instead of the nested key changes in
the current draft).

Implied in the examples but not explicitly specified in the text may hinder
interoperability.

I think ACME is in a last call.

Logan

On Jan 4, 2018 8:19 AM, "Anders Rundgren" 
wrote:

> I thought the ACME signature solution was addressed years ago.  Isn't ACME
> in last call?
>
> F.Y.I.
> https://cyberphone.github.io/doc/security/jose-jcs.html#Sample_Signature
>
> Anders
>
> On 2018-01-04 15:03, 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?
>>
>> JWS Unprotected Header: Not currently used in ACME. Should this be banned
>> in ACME?
>>
>> Multiple signatures: MAY be supported. Should messages signed by both MAC
>> keys and private keys be allowed? 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?
>>
>> JWS Unencoded Payload Option (RFC 7797): Not allowed?
>>
>> 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? 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)?
>>
>> Sincerely,
>> Logan Widick
>>
>> On Jan 4, 2018 5:02 AM, "Jörn Heissler" > > wrote:
>>
>> On Thu, Jan 04, 2018 at 09:47:19 +1000, Fraser Tweedale wrote:
>>  > I am the author of a JOSE library, and have had to deal with
>>  > interoperability issues arising from the multiple serialisations
>> and
>>  > underspecified applications/protocols.  Please heed my advice.
>>  >
>>  > Where there is a choice of JSON serialisation (i.e. exactly one
>>  > signature), JOSE does not require or recommend a particular
>>  > serialisation be used.  Not does the specification require or
>>  > recommend that there be a mechanism for telling a library what JSON
>>  > serialisation to use.  The outcome of this is that there are:
>>  >
>>  > - implementations that unconditionally produce the General JSON
>>  >   serialisation
>>  >
>>  > - implementations that unconditionally produce the Flattened JSON
>>  >   serialisation (and do not support multiple signatures at all)
>>  >
>>  > - implementations that 

Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

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?

JWS Unprotected Header: Not currently used in ACME. Should this be banned
in ACME?

Multiple signatures: MAY be supported. Should messages signed by both MAC
keys and private keys be allowed? 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?

JWS Unencoded Payload Option (RFC 7797): Not allowed?

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? 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)?

Sincerely,
Logan Widick

On Jan 4, 2018 5:02 AM, "Jörn Heissler" 
wrote:

> On Thu, Jan 04, 2018 at 09:47:19 +1000, Fraser Tweedale wrote:
> > I am the author of a JOSE library, and have had to deal with
> > interoperability issues arising from the multiple serialisations and
> > underspecified applications/protocols.  Please heed my advice.
> >
> > Where there is a choice of JSON serialisation (i.e. exactly one
> > signature), JOSE does not require or recommend a particular
> > serialisation be used.  Not does the specification require or
> > recommend that there be a mechanism for telling a library what JSON
> > serialisation to use.  The outcome of this is that there are:
> >
> > - implementations that unconditionally produce the General JSON
> >   serialisation
> >
> > - implementations that unconditionally produce the Flattened JSON
> >   serialisation (and do not support multiple signatures at all)
> >
> > - implementations that produce the Flattened serialisation when
> >   there is a single signature, and the General JSON serialisation
> >   otherwise
> >
> > Therefore for interoperability and to avoid situations where a
> > conforming JOSE library cannot be used for ACME, I suggest that ACME
> > adopt the following regime:
> >
> > - Conforming ACME implementations MUST process JWS objects using the
> >   Flattened JWS JSON Serialization and SHOULD process JWS objects
> >   using the General JWS JSON Serialization.
> >
> > - Conforming ACME implementations MAY refuse to process JWS objects
> >   with multiple signatures.  If an implementation accepts
> >   multiple-signature JWS objects, it MUST validate at least one
> >   signature using the account's public key.
>
> This would work for me. I'm currently writing a new client (We need more
> ACME clients!) and I'd prefer to stick to a single hard coded
> serialization format which works with every conforming CA. Adding
> flexibility (Use "flat" for this CA, use "general" for that CA, etc.)
> would be troublesome.
>
> But I'm worried about client implementations that use the next best JOSE
> library which "unconditionally produces the General JSON serialisation".
> Most CAs would support it ("SHOULD"). But some might decide not to:
> "Yeah, we SHOULD support this. But our JOSE library only understands
> the flat format and everyone but YOU does use the flat format".
> Then who's to blame, the client or the CA?
>
> Should this be changed to "MUST" or to "MAY"?
> I.e. "flat" MUST be supported, "general" MUST/MAY be supported,
> "compact" MAY be supported but needs a "application/jose" content type.
>
>
> On Wed, Jan 03, 2018 at 19:51:53 -0600, Logan Widick wrote:
> >Here is a pull
> >request: [1]https://github.com/ietf-wg-acme/acme/pull/382
> >Let me know what you think.
>
> > +Conforming ACME implementations MUST NOT process JWS objects using
> > +the Compact JWS Serialization.
>
> I think "compact" should be acceptable ("MAY process") iff the client sends
> a 

Re: [Acme] Specify which JWS serialization is used

[Jörn Heissler]

On Thu, Jan 04, 2018 at 09:47:19 +1000, Fraser Tweedale wrote:
> I am the author of a JOSE library, and have had to deal with
> interoperability issues arising from the multiple serialisations and
> underspecified applications/protocols.  Please heed my advice.
> 
> Where there is a choice of JSON serialisation (i.e. exactly one
> signature), JOSE does not require or recommend a particular
> serialisation be used.  Not does the specification require or
> recommend that there be a mechanism for telling a library what JSON
> serialisation to use.  The outcome of this is that there are:
> 
> - implementations that unconditionally produce the General JSON
>   serialisation
> 
> - implementations that unconditionally produce the Flattened JSON
>   serialisation (and do not support multiple signatures at all)
> 
> - implementations that produce the Flattened serialisation when
>   there is a single signature, and the General JSON serialisation
>   otherwise
> 
> Therefore for interoperability and to avoid situations where a
> conforming JOSE library cannot be used for ACME, I suggest that ACME
> adopt the following regime:
> 
> - Conforming ACME implementations MUST process JWS objects using the
>   Flattened JWS JSON Serialization and SHOULD process JWS objects
>   using the General JWS JSON Serialization.
> 
> - Conforming ACME implementations MAY refuse to process JWS objects
>   with multiple signatures.  If an implementation accepts
>   multiple-signature JWS objects, it MUST validate at least one
>   signature using the account's public key.

This would work for me. I'm currently writing a new client (We need more
ACME clients!) and I'd prefer to stick to a single hard coded
serialization format which works with every conforming CA. Adding
flexibility (Use "flat" for this CA, use "general" for that CA, etc.)
would be troublesome.

But I'm worried about client implementations that use the next best JOSE
library which "unconditionally produces the General JSON serialisation".
Most CAs would support it ("SHOULD"). But some might decide not to:
"Yeah, we SHOULD support this. But our JOSE library only understands
the flat format and everyone but YOU does use the flat format".
Then who's to blame, the client or the CA?

Should this be changed to "MUST" or to "MAY"?
I.e. "flat" MUST be supported, "general" MUST/MAY be supported,
"compact" MAY be supported but needs a "application/jose" content type.


On Wed, Jan 03, 2018 at 19:51:53 -0600, Logan Widick wrote:
>Here is a pull
>request: [1]https://github.com/ietf-wg-acme/acme/pull/382
>Let me know what you think.

> +Conforming ACME implementations MUST NOT process JWS objects using
> +the Compact JWS Serialization.

I think "compact" should be acceptable ("MAY process") iff the client sends
a "Content-Type: application/jose" header.

>As for using JOSE implementations that lack support for the JSON
>serialization formats (and only support the compact one), is there an
>RFC, Internet-Draft, or similar document with an explanation of the
>conversion process already prepared (that can simply be thrown into the
>ACME draft's references section)? Or would it be necessary to include
>an appendix in the ACME draft with an outline of the conversion
>process? The conversion process looks fairly straightforward. However,
>it would be nice if there was a document or part of a document that
>could be easily referenced.

Your conversion guide sounds good. But personally I'd move this to a
separate document (like you were looking for) because it would be useful
in non-ACME related applications too.

Cheers,
Jörn


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

Here is a pull request: https://github.com/ietf-wg-acme/acme/pull/382

Let me know what you think.

Sincerely,

Logan Widick

On Wed, Jan 3, 2018 at 6:21 PM, Logan Widick  wrote:

> This looks good to me.
>
> As for using JOSE implementations that lack support for the JSON
> serialization formats (and only support the compact one), is there an RFC,
> Internet-Draft, or similar document with an explanation of the conversion
> process already prepared (that can simply be thrown into the ACME draft's
> references section)? Or would it be necessary to include an appendix in the
> ACME draft with an outline of the conversion process? The conversion
> process looks fairly straightforward. However, it would be nice if there
> was a document or part of a document that could be easily referenced.
>
> Logan
>
> On Wed, Jan 3, 2018 at 5:47 PM, Fraser Tweedale  wrote:
>
>> On Thu, Jan 04, 2018 at 12:07:34AM +0100, Jörn Heissler wrote:
>> > Hello and happy new Year!
>> >
>> > I've found an inaccuracy in the ACME specs.
>> >
>> > https://tools.ietf.org/html/rfc7515#section-7 states:
>> >
>> > Applications using this specification need to specify what
>> serialization
>> > and serialization features are used for that application.
>> >
>> > Although this is neither a "SHOULD" nor a "MUST", I think ACME should
>> specify
>> > which serialization formats need to be supported by server
>> implementations.
>> >
>> > RFC7515 defines four serialization formats:
>> >
>> > * JWS Compact Serialization
>> > * General JWS JSON Serialization Syntax
>> >   * One signature only
>> >   * Multiple signatures
>> > * Flattened JWS JSON Serialization Syntax
>> >
>> > https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm
>> l#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 use only the flattened
>> serialization.
>> > Depending on the clarification above, this might need to be amended too.
>> >
>> > Best regards
>> > Jörn Heissler
>>
>> I am the author of a JOSE library, and have had to deal with
>> interoperability issues arising from the multiple serialisations and
>> underspecified applications/protocols.  Please heed my advice.
>>
>> Where there is a choice of JSON serialisation (i.e. exactly one
>> signature), JOSE does not require or recommend a particular
>> serialisation be used.  Not does the specification require or
>> recommend that there be a mechanism for telling a library what JSON
>> serialisation to use.  The outcome of this is that there are:
>>
>> - implementations that unconditionally produce the General JSON
>>   serialisation
>>
>> - implementations that unconditionally produce the Flattened JSON
>>   serialisation (and do not support multiple signatures at all)
>>
>> - implementations that produce the Flattened serialisation when
>>   there is a single signature, and the General JSON serialisation
>>   otherwise
>>
>> Therefore for interoperability and to avoid situations where a
>> conforming JOSE library cannot be used for ACME, I suggest that ACME
>> adopt the following regime:
>>
>> - Conforming ACME implementations MUST process JWS objects using the
>>   Flattened JWS JSON Serialization and SHOULD process JWS objects
>>   using the General JWS JSON Serialization.
>>
>> - Conforming ACME implementations MAY refuse to process JWS objects
>>   with multiple signatures.  If an implementation accepts
>>   multiple-signature JWS objects, it MUST validate at least one
>>   signature using the account's public key.
>>
>> Cheers,
>> Fraser
>>
>> ___
>> 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

Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

This looks good to me.

As for using JOSE implementations that lack support for the JSON
serialization formats (and only support the compact one), is there an RFC,
Internet-Draft, or similar document with an explanation of the conversion
process already prepared (that can simply be thrown into the ACME draft's
references section)? Or would it be necessary to include an appendix in the
ACME draft with an outline of the conversion process? The conversion
process looks fairly straightforward. However, it would be nice if there
was a document or part of a document that could be easily referenced.

Logan

On Wed, Jan 3, 2018 at 5:47 PM, Fraser Tweedale  wrote:

> On Thu, Jan 04, 2018 at 12:07:34AM +0100, Jörn Heissler wrote:
> > Hello and happy new Year!
> >
> > I've found an inaccuracy in the ACME specs.
> >
> > https://tools.ietf.org/html/rfc7515#section-7 states:
> >
> > Applications using this specification need to specify what
> serialization
> > and serialization features are used for that application.
> >
> > Although this is neither a "SHOULD" nor a "MUST", I think ACME should
> specify
> > which serialization formats need to be supported by server
> implementations.
> >
> > RFC7515 defines four serialization formats:
> >
> > * JWS Compact Serialization
> > * General JWS JSON Serialization Syntax
> >   * One signature only
> >   * Multiple signatures
> > * Flattened JWS JSON Serialization Syntax
> >
> > 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 use only the flattened
> serialization.
> > Depending on the clarification above, this might need to be amended too.
> >
> > Best regards
> > Jörn Heissler
>
> I am the author of a JOSE library, and have had to deal with
> interoperability issues arising from the multiple serialisations and
> underspecified applications/protocols.  Please heed my advice.
>
> Where there is a choice of JSON serialisation (i.e. exactly one
> signature), JOSE does not require or recommend a particular
> serialisation be used.  Not does the specification require or
> recommend that there be a mechanism for telling a library what JSON
> serialisation to use.  The outcome of this is that there are:
>
> - implementations that unconditionally produce the General JSON
>   serialisation
>
> - implementations that unconditionally produce the Flattened JSON
>   serialisation (and do not support multiple signatures at all)
>
> - implementations that produce the Flattened serialisation when
>   there is a single signature, and the General JSON serialisation
>   otherwise
>
> Therefore for interoperability and to avoid situations where a
> conforming JOSE library cannot be used for ACME, I suggest that ACME
> adopt the following regime:
>
> - Conforming ACME implementations MUST process JWS objects using the
>   Flattened JWS JSON Serialization and SHOULD process JWS objects
>   using the General JWS JSON Serialization.
>
> - Conforming ACME implementations MAY refuse to process JWS objects
>   with multiple signatures.  If an implementation accepts
>   multiple-signature JWS objects, it MUST validate at least one
>   signature using the account's public key.
>
> Cheers,
> Fraser
>
> ___
> 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

Re: [Acme] Specify which JWS serialization is used

[Fraser Tweedale]

On Thu, Jan 04, 2018 at 12:07:34AM +0100, Jörn Heissler wrote:
> Hello and happy new Year!
> 
> I've found an inaccuracy in the ACME specs.
> 
> https://tools.ietf.org/html/rfc7515#section-7 states:
> 
> Applications using this specification need to specify what serialization
> and serialization features are used for that application.
> 
> Although this is neither a "SHOULD" nor a "MUST", I think ACME should specify
> which serialization formats need to be supported by server implementations.
> 
> RFC7515 defines four serialization formats:
> 
> * JWS Compact Serialization
> * General JWS JSON Serialization Syntax
>   * One signature only
>   * Multiple signatures
> * Flattened JWS JSON Serialization Syntax
> 
> 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 use only the flattened serialization.
> Depending on the clarification above, this might need to be amended too.
> 
> Best regards
> Jörn Heissler

I am the author of a JOSE library, and have had to deal with
interoperability issues arising from the multiple serialisations and
underspecified applications/protocols.  Please heed my advice.

Where there is a choice of JSON serialisation (i.e. exactly one
signature), JOSE does not require or recommend a particular
serialisation be used.  Not does the specification require or
recommend that there be a mechanism for telling a library what JSON
serialisation to use.  The outcome of this is that there are:

- implementations that unconditionally produce the General JSON
  serialisation

- implementations that unconditionally produce the Flattened JSON
  serialisation (and do not support multiple signatures at all)

- implementations that produce the Flattened serialisation when
  there is a single signature, and the General JSON serialisation
  otherwise

Therefore for interoperability and to avoid situations where a
conforming JOSE library cannot be used for ACME, I suggest that ACME
adopt the following regime:

- Conforming ACME implementations MUST process JWS objects using the
  Flattened JWS JSON Serialization and SHOULD process JWS objects
  using the General JWS JSON Serialization.

- Conforming ACME implementations MAY refuse to process JWS objects
  with multiple signatures.  If an implementation accepts
  multiple-signature JWS objects, it MUST validate at least one
  signature using the account's public key.

Cheers,
Fraser


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

I agree that a serialization format (or set of formats) would need to be
standardized. Related thread:
https://www.ietf.org/mail-archive/web/acme/current/msg01690.html

Sincerely,

Logan Widick

On Wed, Jan 3, 2018 at 5:07 PM, Jörn Heissler 
wrote:

> Hello and happy new Year!
>
> I've found an inaccuracy in the ACME specs.
>
> https://tools.ietf.org/html/rfc7515#section-7 states:
>
> Applications using this specification need to specify what
> serialization
> and serialization features are used for that application.
>
> Although this is neither a "SHOULD" nor a "MUST", I think ACME should
> specify
> which serialization formats need to be supported by server implementations.
>
> RFC7515 defines four serialization formats:
>
> * JWS Compact Serialization
> * General JWS JSON Serialization Syntax
>   * One signature only
>   * Multiple signatures
> * Flattened JWS JSON Serialization Syntax
>
> 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 use only the flattened
> serialization.
> Depending on the clarification above, this might need to be amended too.
>
> Best regards
> Jörn Heissler
>
> ___
> 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