Subject: [Acme] PR for account key rollover

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Nov 2015 14:37:21 -0800

​This pull request is found here:
https://github.com/ietf-wg-acme/acme/pull/39/files?diff=unified.

If I am reading this correctly, the example doesn't quite match the text.
The text below shows a signature of the JWS with the original key, but does
not show the oldkey field noted in the text.

Am I missing something here?

regards,

Ted

The client signs this object with the new key pair and encodes the object
and
​ ​
signature as a JWS. The client then sends this JWS to the server in the
​ ​
"newKey" field of a request to update the registration.

~~~~~~~~~~
POST /acme/reg/asdf HTTP/1.1
Host: example.com

{
 "resource": "reg",
 "newKey": /* JSON object signed as JWS with new key */
}
/* Signed as JWS with original key */

---

From: Richard Barnes <[email-masked]>
Date: Tue, 17 Nov 2015 19:05:56 -0800

My intent was for that "JSON object signed as JWS" to be the JSON
object shown above.  Would it be clearer to frame the example as
follows?

~~~~~~~~~~

{
  "resource": "reg",
  "newKey": {
    "header": { "jwk": /* JWK form of the new key */, ... },
    "payload": base64({
      "resource": "reg",
      "oldKey": "D7J9RL1f-RWUl68JP-gW1KSl2TkIrJB7hK6rLFFeYMU"
    }),
    "signature": /* signature by new key */
  }
}
/* Signed as JWS with original key */
~~~~~~~~~~

On Tue, Nov 17, 2015 at 2:37 PM, Ted Hardie <[email-masked]> wrote:
> This pull request is found here:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Nov 2015 20:11:40 -0800

Personally, I find that much clearer.

Regards,

Ted

---

From: Thomas Lußnig <[email-masked]>
Date: Mon, 23 Nov 2015 18:24:02 +0100

Hi,

what about this idee for dns based authorization ?

1) Take the Publickey of the Account and build the SHA-1 of if. (Mable 
later SHA-256)
2) Create an Textrecord sha1-dns-02-acme-challenge for domain with the 
Base64 content of the hash.
sha1-dns-02-acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM"

Improvements above dns-01:
a) It allow Wildcard entries so that the user does not need to change 
the dns for each fqdn.
b) As long as the account key is the same the approval is the same.

This is analogue to placing an html page containing an authorization 
token into the webserver like google use is for webmaster info access. 
We do not need the random factor to prevent replay. As long as we bind 
the authorization to the account key.

With the system i described above the challenge that fulfil the random 
request is:

The certificate requester must prove that he own the private key for the 
public key that he announced in the DNS record.
To prove this the CA send an random 128bit token to the requester that 
is send back as jwk signed with the matching private key for the DNS 
record containing the token from the challenge.

Gruß Thomas Lußnig