This is a good point. ACME clients are not limited to dumb pass-through;
they can do intelligent things with the things users give them. If this is
something CAs can live with, I can update the PR to implement it.
It seems like there are a few implications of this in practice:
1. The CA has to generate / store two random values instead of one
2. The client has to convert a user-input value to a MAC key
3. Both sides have to implement a MAC construction
Of these, the one that worries me most is (2). The user interface is going
to be string-oriented, so the server and the client have to agree on the
mapping between MAC keys and strings. So while configuration formats are
usually out of the scope of protocol specs, we should probably specify a
format here. Among the obvious options (1) hex, (2) base64url, and (3)
UTF-8, my preference order would probably be 1 = 2 > 3.
As far as the MAC, I would probably just have an inner, MAC-based JWS, as
for key roll-over, using the "kid" field for the key ID:
{
"protected": base64url({
"alg": "ES256",
"jwk": /* account key */,
"nonce": "K60BWPrMQG9SDxBDS_xtSw",
"url": "https://example.com/acme/new-acct";
}),
"payload": base64url({
"contact": ["mailto:example@anonymous.invalid";],
"terms-of-service-agreed": true,
"external-account-binding": {
"protected": base64url({
"alg": "HS256",
"kid": /* key identifier */,
}),
"payload": base64url({
"accountKey": /* same as in "jwk" above */
}),
"signature": "Xe8B94RD30Azj2ea...8BmZIRtcSKPSd8gU"
}
}),
"signature": "5TWiqIYQfIDfALQv...x9C2mg8JGPxl5bI4"
}
This will be a fair bit more spec text, and a little more code, but it
seems worth it.
--Richard
On Sat, Nov 19, 2016 at 2:22 AM, Karthikeyan Bhargavan <
karthik.bharga...@gmail.com> wrote:
> 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 <ray.ch...@entrustdatacard.com>
> 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
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
