x/crypto/acme: allow setting client KID directly

[Stanwise]

What version of Go are you using (go version)?

$ go version
go version go1.13.4 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

N/A

What did you do?

I have a service that uses acme.Client for communication with an RFC8555 CA. For technical reasons I need to reconstruct the acme.Client multiple times during the full flow.

Current implementation works overall, but I'd like to be able to specify account KID (equal to Account.URI) explicitly, instead of having the library always call the CA's account registration endpoint to obtain kid to cache: https://github.com/golang/crypto/blob/c07d793c2f9aacf728fe68cbd7acd73adbd04159/acme/acme.go#L152

What did you expect to see?

I'd like to be able to create the client like this:

&acme.Client{
    Key:          signer,
    KID:          accountURI,
    DirectoryURL: directoryUrl,
    HTTPClient:   &http.Client{...}
},

And have the kid field populated from it , e.g.:

• KID field could be a string, only used in the first request to pre-populate the private mutex-protected kid value.
• The following snippet could be added to accountKID function between lines 151 and 152

if c.KID != "" {	
  c.kid = c.KID
  return c.kid
}

What did you see instead?

I have to specify the client like this:

&acme.Client{
    Key:          signer,
    DirectoryURL: directoryUrl,
    HTTPClient: &http.Client{...}
},

And then the library calls the CA's account registration endpoint to obtain kid to cache. This results in a lot of unnecessary calls to the CA.

[gopherbot]

Change https://golang.org/cl/354697 mentions this issue: acme: expose Client KID field

[rolandshoemaker]

(sent a CL for this, but just to articulate my thoughts here) This seems reasonable to me. I don't think adding a duplicate public field is worth the extra complexity, seems fine to just expose the existing kid field.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group