Hello all, Background ==========
I would like to begin with a bit of background to put some context around how this ACME change proposal originated. Entrust has released a beta ACME server to our customers that works with the current certbot client. We have also began developing some knowledge of the certbot code base and we intend to contribute to the certbot project in the future. One of the implementation challenges we had was that we wanted to pass additional information from the certbot client to our ACME server that would be associated with the registration object. Examples of this may include: a. account number b. name of operator running certbot This proposal has some similarities to ACME pull request #172 (https://github.com/ietf-wg-acme/acme/pull/172) but is intended to be generic. The hope is that these arbitrary name-value pairs would work with any CA in general without introducing very CA-specific tokens into the protocol. What it may look like ===================== One way to accomplish this in the protocol is to simply add a "ca-extension" object to the registration object, where the "ca-extension" object is an array of name-value pairs of strings. For example: { "protected": base64url({ "alg": "ES256", "jwk": {...}, "nonce": "6S8IqOGY7eL2lsGoTZYifg", "url": "https://example.com/acme/new-reg"; }) "payload": base64url({ "contact": [ "mailto:cert-ad...@example.com";, "tel:+12025551212" ], "ca-extension": [ "<ca-ext-name-1>": "<ca-ext-value-1>", "<ca-ext-name-2>": "<ca-ext-value-2>" ] }), "signature": "RZPOnYoPs1PhjszF...-nh6X1qtOFPB519I" } CA's should ignore any <ca-ext-name> in the ca-extension that it does not understand. Regards, Ray Cheng Entrust Datacard _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
