-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
acme: external account binding support #2392
acme: external account binding support #2392
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JoshVanL The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
0cbad88
to
6d9473c
Compare
f522658
to
78cbe36
Compare
|
||
// Key is a base64 encoded symmetric key that authenticates the account with | ||
// an external account. | ||
Key string `json:"key,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like a sensitive value, given it is used to authenticate/bind a registration to some external system?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, how come this is a base64 encoded string? Does this really mean it is a []byte
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, makes sense to move to a secret
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory you can should be able to use raw []byte data for your symmetric MAC key. base64 encoding makes then becomes a requirement
|
||
provisionerDNS01 := &acmeIssuerProvisioner{ | ||
eab: eab, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean we only test with EAB enabled now? I'd be happy to just see the suite run using e.g. HTTP01 with EAB enabled (I don't think we really need to run the full DNS01 && HTTP01 suite with EAB enabled), but I'd also like to see this run without EAB enabled too (as before).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should run the acme tests with and without EAB. the passed in eab struct can be nil
third_party/crypto/acme/acme.go
Outdated
if err != nil { | ||
return nil, err | ||
} | ||
func (c *Client) postJWS(ctx context.Context, key crypto.Signer, accountURL, url, nonce string, body interface{}) (*http.Response, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you update the comments on every function/method you've changed the signature on to explain what the new parameter is, what it can be set to, and its behaviour if not set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, how come you've changed this to accept a nonce instead of just retrieving one as before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All in all, we should attempt to keep the diff in third_party as minimal as possible IMO 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this signature shouldn't need to change I think. Some things moved around in dev but was moved back. Forgot about reverting this change
326d360
to
7ef9782
Compare
013fee8
to
5d9391e
Compare
bad13ae
to
3b33bd3
Compare
Not sure why Pebble is returning this:
in some of the ACME test cases where nginx is configured to redirect to a Retesting to see if this is a flake, and will audit changes to Pebble since the old vs new commit as I've not seen this before! /retest |
After some digging in pebble, I think I have identified the cause and I've opened this issue to track it: letsencrypt/pebble#293 |
3b33bd3
to
3bb71e5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple comments.
We also need to add to the checks for secrets that are referenced by a possible EAB account and have been updated
/unassign
/assign @munnerz
// server. | ||
type ACMEExternalAccountBinding struct { | ||
// keyID is the ID of the CA key that the External Account is bound to. | ||
KeyID string `json:"keyID"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
KeyID can be potentially sensitive information. We should er on the side of caution and make this a secret reference
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think at this point we can keep it as keyID
- it's effectively the 'username' parameter here, and the 'secret' value should be sufficient to protect user accounts. It's not really explored in the RFC, and if needed in future, we can add an additional field for a secret ref variant of this, for those who are more sensitive about key IDs.
Signed-off-by: James Munnelly <james@munnelly.eu>
Signed-off-by: James Munnelly <james@munnelly.eu>
Signed-off-by: James Munnelly <james@munnelly.eu>
Signed-off-by: James Munnelly <james@munnelly.eu>
Signed-off-by: James Munnelly <james@munnelly.eu>
Signed-off-by: James Munnelly <james@munnelly.eu>
Signed-off-by: James Munnelly <james@munnelly.eu>
Signed-off-by: James Munnelly <james@munnelly.eu>
6d6219a
to
ff8c683
Compare
Looks good to me :) |
/lgtm |
fixes #1676
/assign
/hold