Subject: Re: [Acme] Proposal for adding arbitrary CA-specific, name-value pairs to registration object

From: Yaron Sheffer <[email-masked]>
Date: Sun, 20 Nov 2016 10:22:12 +0900

> From: Karthikeyan Bhargavan <[email-masked]>
> To: Ray Cheng <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Jacob Hoffman-Andrews
> 	<[email-masked]>
> Subject: Re: [Acme] Proposal for adding arbitrary CA-specific
> 	name-value pairs to registration object
> Message-ID: <[email-masked]>
> 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