Subject: Re: [Acme] Minor fix for JWS signature algorithms

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Dec 2016 14:31:56 -0500

On Wed, Nov 30, 2016 at 12:15 AM, Martin Thomson <[email-masked]>
wrote:

> On 30 November 2016 at 15:52, Richard Barnes <[email-masked]> wrote:
> > So, dear HTTP editor, which code should we use?
>
> No need to be facetious :)
>
> I was agreeing with Ted, if that wasn't clear.  400 is your grab bag
> for "requests you don't like".  403 is generally used for cases where
> authentication has been dealt with, but that is (still) insufficient.
> I think that it's perfectly good for cases where the account or
> signature is forbidden from making a change.
>
> Changes of Terms of Service [sic - Changed?] 403 => 400 seems like a
> better choice
> Pre-Authorization 403 is probably OK here
>
> There doesn't seem to be a good rule in these cases, but the risk is
> that you slap 403 on every request that the server might want to
> reject on the basis of ...stuff.
>

My inclination here would be to basically cut "stuff" into two tranches:

- 400 for stuff that can go wrong at the transport layer, e.g., signature
validation failure, nonce reuse
- 403 for stuff that can go wrong at the application logic layer, e.g.,
refusal to authorize for an identifier

That means 403 for changes to terms of service / userActionRequired, but
400 for badSignatureAlgorithm.  I've updated the PR correspondingly.

https://github.com/ietf-wg-acme/acme/pull/218

--Richard

On Wed, Nov 30, 2016 at 12:15 AM, Martin Thomson <[email-masked]>
wrote:

> On 30 November 2016 at 15:52, Richard Barnes <[email-masked]> wrote:
> > So, dear HTTP editor, which code should we use?
>
> No need to be facetious :)
>
> I was agreeing with Ted, if that wasn't clear.  400 is your grab bag
> for "requests you don't like".  403 is generally used for cases where
> authentication has been dealt with, but that is (still) insufficient.
> I think that it's perfectly good for cases where the account or
> signature is forbidden from making a change.
>
> Changes of Terms of Service [sic - Changed?] 403 => 400 seems like a
> better choice
> Pre-Authorization 403 is probably OK here
>
> There doesn't seem to be a good rule in these cases, but the risk is
> that you slap 403 on every request that the server might want to
> reject on the basis of ...stuff.
>