It is worth noting that “external_secret”, “ca-account-secret”, and “token” are
all secret bearer tokens
and, as such, offer *significantly* less security than the default ACME
mechanisms, and in some cases
may defeat the purpose of having account keys.
I can see that different vendors may have need for symmetric secrets like these
for their own use,
but if we were to extend ACME to allow such “external” secrets, we should
standardize their secure use.
For example, a much safer way to embed “external_secret”, “ca-account-secret”,
and “token” would be
to have an “external-key-id” field, that indicates a MAC key that has been
exchanged out-of-band;
we would then use MAC-based authentication to bind the MAC key to the relevant
JWS request,
using the standard nested authentication mechanism we are using in roll-over,
something like:
Sign (account-key, (request, external-key-id, MAC (external_key,
Hash(account_key))))
This would ensure that the external secret is never sent on the wire and is not
a bearer token,
and the compound authentication guarantees of the resulting protocol are quite
strong.
More generally, ACME is not a browser-based protocol and there is no need for
us to rely
on obsolete cookie-like mechanisms; ACME clients and servers are already doing
crypto,
so why not use MACs instead of passing bearer tokens in URLs or in the request?
Best,
Karthik
> On 31 Oct 2016, at 16:43, Ray Cheng <[email protected]> wrote:
>
> Hi Jacob,
>
> From: Jacob Hoffman-Andrews, Thursday, October 27, 2016 5:28 PM:
>>
>> On 10/04/2016 06:11 AM, Ray Cheng wrote:
>>> 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:
>> I think this makes a lot of sense, and is in the spirit of the other
>> places we've intentional left hooks for CA-specific customization, like
>> OOB challenges. I'm inclined to accept it.
>>
>> Additionally, your experience as a commercial implementer of ACME may be
>> valuable to spot places where the current protocol is lacking. For
>> instance, you need an "account" field, and StartCom needs
>> (https://github.com/ietf-wg-acme/acme/pull/172) a "token" field. Can we
>> support those use cases natively in ACME so they don't need to be
>> extensions? What do you put in the "account" field, and how do you
>> authenticate the link between the ACME account and the Entrust account.
>>
>
> We are effectively using "ca-account-id" and "ca-account-secret" fields to
> authenticate the link to the Entrust account. Since these fields do not
> currently exist in draft-03 and certbot, we are embedding them in the URL
> that a particular customer uses to access our ACME server.
>
> The "external_secret"/"token" is slightly different but is also useful as an
> "API key" type of authentication.
>
> Although we see value in a "ca-extension" object, we also support adding
> explicit fields in ACME. There are some advantages to explicit fields - one
> in particular is the special handling of designated secret fields by clients.
>
> Thanks for your feedback.
>
>
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
