Subject: Re: [Acme] Add badPublicKey error

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Jan 2019 15:51:11 +0000

As WG co-chair, I am not thrilled with making this addition so very very late in the process.  If the WG wants to do it, we'd need (a) clear consensus and (b) a quick approval from the IESG.

As an individual, I dislike putting "here's what's wrong with your key" in the error message. For example, it encourages a thief to do "venue shopping" looking for a CA that will certify their stolen keypair.

On 1/24/19, 9:27 AM, "Rob Stradling" <[email-masked]> wrote:

    I realize it's very late for making non-editorial changes to 
    draft-ietf-acme-acme, but I'd like to propose adding a new badPublicKey 
    error.  This error would be returned by the server whenever it does not 
    support, or wishes to reject, a "jwk" public key supplied in a client's 
    request.
    
    Proposed text: https://github.com/ietf-wg-acme/acme/pull/478
    
    The 'array of supported "alg" values' in a badSignatureAlgorithm 
    response is useful, but ISTM that it doesn't provide detailed enough 
    information to assist a client in generating a suitable public key.
    
    (If the consensus is that it's too late to add a new error type, then my 
    alternative proposal will be to use "malformed" instead of adding 
    "badPublicKey", but keep the rest of PR 478 as is; I think it's a good 
    idea to call out the need for a server to sanity check each 
    client-supplied public key).
    
    -- 
    Rob Stradling
    Senior Research & Development Scientist
    Sectigo Limited
    
    _______________________________________________
    Acme mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/acme

---

From: Richard Barnes <[email-masked]>
Date: Thu, 24 Jan 2019 11:09:09 -0500

On Thu, Jan 24, 2019 at 10:52 AM Salz, Rich <[email-masked]> wrote:

> As WG co-chair, I am not thrilled with making this addition so very very
> late in the process.  If the WG wants to do it, we'd need (a) clear
> consensus and (b) a quick approval from the IESG.
>

Note that since the registration policy is "specification required", doing
this in an extension spec instead would not require the consent of the IESG.

> As an individual, I dislike putting "here's what's wrong with your key" in
> the error message. For example, it encourages a thief to do "venue
> shopping" looking for a CA that will certify their stolen keypair.
>

I think you're confused here, Rich.  This error code relates to *account
keys*, not keys that are certified by the CA.

--Richard

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Jan 2019 16:18:48 +0000

*   Note that since the registration policy is "specification required", doing this in an extension spec instead would not require the consent of the IESG.

Right, which is how I prefer to see this move forward.  Putting it into the ACME doc, however, *does* require IESG approval.

  *   I think you're confused here, Rich.  This error code relates to *account keys*, not keys that are certified by the CA.

Not really, which is why I chose the example I did.

---

From: Daniel McCarney <[email-masked]>
Date: Thu, 24 Jan 2019 11:25:31 -0500

> shopping" looking for a CA that will certify their stolen keypair.

I don't think this is a meaningful example. The server has to return some
kind of error message if it isn't going to accept the key. As an attacker I
probably know I've stolen a good key (it was in use, wasn't it?) so if I
get an error message of any kind I can shop it out to the next CA. This
thread is just addressing the question about whether we should make it a
standardized error instead of bucketed into "malformed".

On Thu, Jan 24, 2019 at 11:19 AM Salz, Rich <[email-masked]> wrote:

>
>    - Note that since the registration policy is "specification required",
>    doing this in an extension spec instead would not require the consent of
>    the IESG.
>
>
>
> Right, which is how I prefer to see this move forward.  Putting it into
> the ACME doc, however, **does** require IESG approval.
>
>
>
>    - I think you're confused here, Rich.  This error code relates to
>    *account keys*, not keys that are certified by the CA.
>
>
>