Skip to content
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

Implement draft-ietf-acme-ip #2706

Open
rolandshoemaker opened this issue Apr 25, 2017 · 15 comments
Open

Implement draft-ietf-acme-ip #2706

rolandshoemaker opened this issue Apr 25, 2017 · 15 comments

Comments

@rolandshoemaker
Copy link
Member

@rolandshoemaker rolandshoemaker commented Apr 25, 2017

Implementation before standardization, it's a thing we should probably do.

For LE would this require a CP/CPS update before it could be deployed?

@rolandshoemaker

This comment has been minimized.

Copy link
Member Author

@rolandshoemaker rolandshoemaker commented Apr 27, 2017

For LE would this require a CP/CPS update before it could be deployed?

Yes, CPS 7.1.5 restricts issuance of certs for IP addresses.

@rolandshoemaker

This comment has been minimized.

Copy link
Member Author

@rolandshoemaker rolandshoemaker commented Apr 28, 2017

Open questions:

  • Do we want to restrict any CIDRs (i.e. those held by ISPs)?
  • Do we want to reduce the lifetime of certs containing IP addresses?

cc @jsha @cpu for thoughts

@jsha

This comment has been minimized.

Copy link
Contributor

@jsha jsha commented Apr 28, 2017

Definitely yep to both.

@rolandshoemaker

This comment has been minimized.

Copy link
Member Author

@rolandshoemaker rolandshoemaker commented Apr 28, 2017

Definitely yep to both.

Any thoughts on determining the values of either? Not really sure how we'd go about figuring out which CIDRs to block, is there a public CIDR list?

@jsha

This comment has been minimized.

Copy link
Contributor

@jsha jsha commented Apr 28, 2017

Oh, I misread; was thinking of private CIDRs, which of course we want to block. Blocking CIDRs belonging to ISPs seems counterproductive; I expect home servers to be a popular use case for IP certs. You should also ping the Technical Advisory Board for thoughts.

@rolandshoemaker rolandshoemaker changed the title Implement draft-shoemaker-acme-ip Implement draft-ietf-acme-ip Jul 24, 2018
@orangepizza

This comment has been minimized.

Copy link

@orangepizza orangepizza commented Jun 11, 2019

copied from forum:

After my PR for add support for draft-acme-ip on pebble merged, I looked at boulder code to implement on it too and searched possible problems about it.(like what’s the point of pebble only support?), and this is what I found in first hour…
This list is most likely incomplete and need many more untested

all the things done in pebble patch
    creating a new identifier type constant in acme/common.go
    updating the WFE to allow IP type identifiers in newOrder requests
    updating the WFE to validate the IP identifiers
    updating the TLS-ALP-01 implementation to properly handle IP address identifiers
    updating the HTTP-01 implementation to properly handle IP address identifiers
    updating the DNS-01 implementation to forbid IP address identifiers
    updating the CA to issue certificates for orders with IP address identifiers using appropriate SAN entries with iPAddress type


WFE(1/2) NewOrder doesn’t send Identifier, but just names as [ ]string to wfe.ra.NewOrder()
update CAA lookup to see caa and upstream rdns address for ip. Or skip it as it doesn’t need to in ca/b baseline requirements
LE need to create new policy about rate limit for certs with ip (what would be “base domain” for ip addresses?
add PA test for IP address cert request about anything possible to send.
add checks to block request to private IPs. but challenges won’t able to succeed on such ip anyway.
some troublesome place about adding identifier type ip.
those places hard-coded to make identifiers from (domain) name with type “dns”
in most place it uses identifier.DNSIdentifier(), but in some places it doesn’t.
    a. at line 348 performRemoteValidation() it gets only domain string as input and send it to rva’s PerformVlidation()
    b. at va.go line 567, PerformVlidation()
    c. ra.go line 2057, NewOrder() (※this don’t use function identifier.DNSIdentifier)

and from discussion on top
We’d need to update our CP and CPS.
Unlike Pebble there would need to be robust unit and integration tests (this might translate into needing to do some acme python module work as well).
We would want to restrict IP subject certificate lifetime to <90days.

it looks like wfe check there is no identifier type other then DNS, then just send names to RA, and RA recreate identifiers with hard-corded identfiertype dns

I think update wfe1 and 2 to send full identifiers to RA, and update RA do deal with it.
it’s mostly the same problem that had on pebble, but things like CAA and ratelimit. is added on top of that.
and it’d be complex change that make many new joints on boulder. likely even more then wildcard support.

@cpu

This comment has been minimized.

Copy link
Contributor

@cpu cpu commented Jun 11, 2019

I think update wfe1 and 2 to send full identifiers to RA, and update RA do deal with it.

@orangepizza One thing I forgot to mention on the forum thread: We would only want to implement ACME-IP for the ACME v2 RFC 8555 API, not the legacy ACME v1 API.

@orangepizza

This comment has been minimized.

Copy link

@orangepizza orangepizza commented Jun 11, 2019

I think update wfe1 and 2 to send full identifiers to RA, and update RA do deal with it.

@orangepizza One thing I forgot to mention on the forum thread: We would only want to implement ACME-IP for the ACME v2 RFC 8555 API, not the legacy ACME v1 API.

it was more about as current WFE send order domains as []string and RA rebuild []Identifier with hard-corded dns type, but it need to change WFEs to send []Identifier and RA receive []Identifier as input if we want to handle anything other then DNS. by the way why it does this unpack-and-repack?

@HLFH

This comment has been minimized.

Copy link

@HLFH HLFH commented Sep 16, 2019

I expect home servers to be a popular use case for IP certs.

And KVM over IP switches.

@dumblob

This comment has been minimized.

Copy link

@dumblob dumblob commented Jan 11, 2020

I can see IANA review state: IANA OK - Actions Needed in https://datatracker.ietf.org/doc/draft-ietf-acme-ip/?include_text=1

Can we do something to speed things up a bit around implementing support for IPs in ACME?

@tdelmas

This comment has been minimized.

Copy link
Contributor

@tdelmas tdelmas commented Jan 11, 2020

Also, Let's Encrypt CP is updated in that direction: letsencrypt/cp-cps@b9e9a56...bc0499adiff-43f79d14d36303bbae3da9268d7a2238R361-R399

@dumblob

This comment has been minimized.

Copy link

@dumblob dumblob commented Jan 11, 2020

@tdelmas thanks for the pointer. So the certificate policy for IPs seems to be there. That's always good news. Do you happen to know whether there is any (preliminary/subject_to_change) schedule when this new policy could get implemented?

@rolandshoemaker

This comment has been minimized.

Copy link
Member Author

@rolandshoemaker rolandshoemaker commented Jan 13, 2020

The RFC is progressing through the IETF process, there is nothing we can do to speed that process up ourselves, we just have to wait.

We also don't have any specific timeline for implementing support for acme-ip, although it is likely it will happen sometime this year.

@dumblob

This comment has been minimized.

Copy link

@dumblob dumblob commented Jan 13, 2020

We also don't have any specific timeline for implementing support for acme-ip, although it is likely it will happen sometime this year.

Ok, didn't expect there is no plan currently. Anyway, thanks for the valuable info. If anything should change, keep us posted.

@bortzmeyer

This comment has been minimized.

Copy link

@bortzmeyer bortzmeyer commented Mar 1, 2020

The RFC is progressing through the IETF process, there is nothing we can do to speed that process up ourselves, we just have to wait.

We also don't have any specific timeline for implementing support for acme-ip, although it is likely it will happen sometime this year.

RFC 8738 is now published.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.