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] Example requests

[Richard Barnes]

Hey Joern,

This is a probably a good thing to have.  I think that rather than putting
these in the main spec, it might be better to have them in a second draft.
This is a pretty common pattern.  For example, for TLS 1.3, there's a "test
vectors" document separate from the main spec [0].  There are a few
documents with example "call flows" for SIP [1][2].  ACME is probably
somewhere in the middle of those two cases.

--Richard

[0] https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-03
[1] https://tools.ietf.org/html/rfc3665
[2] https://tools.ietf.org/html/rfc5589



On Sun, Mar 4, 2018 at 4:36 PM, Jörn Heissler 
wrote:

> Hello,
>
> I'm not sure if this should be included, so not making a PR yet.
>
> Complete examples for requests may help implementers (of both servers
> and clients) to understand the specifications. All existing examples
> have pseudo-code like base64url({...}) and no untruncated keys or
> signatures.
>
> I wrote two examples, one for account creation, another for key
> roll-over to demonstrate nested JWS:
>
> https://github.com/joernheissler/acme/commit/
> a8a303ddbe3280b49ce8f10508dcdf95a6dc6de9
>
> That commit also adds "--- back" (Backmatter to get Appendices in the
> rendered document) and I'm not happy with the wording on top.
>
> To check correctness of the signatures and make the requests
> human-readable, I also wrote a small test program:
>
> https://gist.github.com/joernheissler/04d9dcfb3a99e318871e451c9043f2dc
>
> Do you think those examples should be included? And if so, is there any
> time left to actually do it?
>
> Cheers
> Joern 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

[Acme] Example requests

[Jörn Heissler]

Hello,

I'm not sure if this should be included, so not making a PR yet.

Complete examples for requests may help implementers (of both servers
and clients) to understand the specifications. All existing examples
have pseudo-code like base64url({...}) and no untruncated keys or
signatures.

I wrote two examples, one for account creation, another for key
roll-over to demonstrate nested JWS:

https://github.com/joernheissler/acme/commit/a8a303ddbe3280b49ce8f10508dcdf95a6dc6de9

That commit also adds "--- back" (Backmatter to get Appendices in the
rendered document) and I'm not happy with the wording on top.

To check correctness of the signatures and make the requests
human-readable, I also wrote a small test program:

https://gist.github.com/joernheissler/04d9dcfb3a99e318871e451c9043f2dc

Do you think those examples should be included? And if so, is there any
time left to actually do it?

Cheers
Joern Heissler


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

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

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : Extensions to Automatic Certificate Management 
Environment for end user S/MIME certificates
Author  : Alexey Melnikov
Filename: draft-ietf-acme-email-smime-02.txt
Pages   : 4
Date: 2018-03-04

Abstract:
   This document specifies identifiers and challenges required to enable
   the Automated Certificate Management Environment (ACME) to issue
   certificates for use by email users that want to use S/MIME.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-email-smime-02
https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

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

[Jörn Heissler]

Hi,

another PR that slightly changes meaning (SHOULD NOT -> MUST NOT):
https://github.com/ietf-wg-acme/acme/pull/407

Section "Request Authentication" says:
"Servers MUST NOT respond to GET requests for resources that might be
considered sensitive. Account resources are the only sensitive resources
defined in this specification."

I agree with the "MUST NOT" here as account contains e.g. my contact data.
Therefore section "Account Information" should also says "MUST NOT":
"Servers MUST NOT respond to GET requests for account resources..."

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

[Acme] Include finalize step in Protocol Overview

[Jörn Heissler]

Hi,

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

Cheers
Joern Heissler


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