From: Karthikeyan Bhargavan <[email protected]>
To: Ray Cheng <[email protected]>
Cc: "[email protected]" <[email protected]>, Jacob Hoffman-Andrews
<[email protected]>
Subject: Re: [Acme] Proposal for adding arbitrary CA-specific
name-value pairs to registration object
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
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
My understanding from the meeting was that some of these "secrets" will
be simple user passwords, making the solution even less appetizing.
Thanks,
Yaron
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
