[Acme] Open issues on GitHub

Hello, how are issues on GitHub handled? Should they always be brought to the list? Seems like there isn't that much activity there. I opened a few while implementing my PHP client with no answers during the last few days. https://github.com/ietf-wg-acme/acme/issues/31

Re: [Acme] Content-Type and file extensions for HTTP01 challenges

+1 for .txt, there are servers configured to serve only specific file extensions. Regards, Niklas ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Content-Type and file extensions for HTTP01 challenges

f.org> wrote: > >> Sounds like we have emerging consensus around this version of 3b. Does >> anyone know of anything it breaks? >> >> On Wed, Nov 18, 2015 at 05:51:55PM +0100, Niklas Keller wrote: >> > +1 for .txt, there are servers configured to serve only speci

[Acme] Authorizations and Certificates in Registrations

Hello, what's the reason why "authorizations" and "certificates" are optional in registration objects? They should both not be optional IMO, because they can be used nicely to lower the load on the CA, because clients can reuse prior authorizations and even download lost certificates easily. This

Re: [Acme] Authorizations and Certificates in Registrations

2015-12-05 20:38 GMT+01:00 Jacob Hoffman-Andrews : > > what's the reason why "authorizations" and "certificates" are optional > in registration objects? They should both not be optional IMO, because > they can be used nicely to lower the load on the CA, because clients can > reuse

Re: [Acme] Agreement integrity checksum

2015-12-15 17:27 GMT+01:00 Richard Barnes : > Thanks for the PR! I agree that having an integrity hash is overkill, > and we should focus on advising CAs. > > That said, the considerations for how CAs track agreements are very > much specific to each CA, so I'm hesitant to have

Re: [Acme] Issue: Allow ports other than 443

It's an issue with shared hosting where users have shell access but no root access. 2015-11-24 17:49 GMT+01:00 Eliot Lear : > Yes, thanks, Yoav. Apologies to Randy and Kathleen for my terseness. > > Eliot > > > On 11/24/15 5:46 PM, Yoav Nir wrote: > > I think Eliot meant RFC

Re: [Acme] Content-Type and file extensions for HTTP01 challenges

2015-11-19 20:23 GMT+01:00 Salz, Rich : > Ø I'd prefer that currently, way better than having a lot of different > specs with only minimal differences. > > We’re not going to have lots of different specs, we’re just bumping the > version number because there are already

Re: [Acme] Revert "Allow the client to give a preference for a specific IP in http-01"

2016-06-09 19:12 GMT+02:00 Jacob Hoffman-Andrews : > https://github.com/ietf-wg-acme/acme/pull/138 > > This reverts commit a5cb357 > > I think we did not reach consensus on the list about this feature. > What's the issue with it? I think it's fine. It saves setting up redirects to

Re: [Acme] Comments on draft-ietf-acme-acme-01

2016-02-03 20:55 GMT+01:00 Phillip Hallam-Baker : > I think Terminology and Dependencies should also have a mention of > HTTP / HTTPS, also RFC3339 (time format). > > What I would like to get to eventually is some external document > describing a particular style of JOSE

[Acme] Exposed rate limits

different clients. https://github.com/ietf-wg-acme/acme/pull/104 Best Regards, Niklas Keller ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Exposed rate limits

2016-03-21 9:53 GMT+01:00 Philipp Junghannß : > adding to this some parts of rate limits should be maybe made a bit > clearer if not already (e.g. if you have multiple different domains in a > SAN which will get the count, just the CN? or all of them? > also it would be

Re: [Acme] Exposed rate limits

I updated the PR to be compatible with sliding rate limit windows. The current draft doesn't allow clients to warn before the rate limit is hit, but at least they can show more useful information once the rate limit is hit.

Re: [Acme] Pre-authorization approach

2016-07-26 23:03 GMT+02:00 Richard Barnes : > Hey folks, > > At the IETF meeting, EKR pointed out the need to have a > "pre-authorization" function in ACME, where the client can get > authorization to issue for certain names without causing a certificate to > be issued. Having

Re: [Acme] Short term certificates - two options

2016-07-20 11:51 GMT+02:00 Yaron Sheffer : > Hi, > > At the LURK BoF this week there was some interest in having a solution > where a domain owner can delegate to some other entity (which we will > call "the TLS server") the authority to terminate TLS connections on its >

Re: [Acme] Economize on nonces

2016-07-09 18:57 GMT+02:00 Ron : > On Fri, Jul 08, 2016 at 04:02:36PM -0700, James Kasten wrote: > > I agree that there are a large number of wasted nonce values which > creates > > a burden for the ACME server. This PR would certainly reduce the number > of > > unused nonces. >

Re: [Acme] Terms of service agreement changes

2016-08-08 4:07 GMT+02:00 Richard Barnes : > > > On Sun, Aug 7, 2016 at 8:34 AM, Hugo Landau wrote: > >> On Sat, Aug 06, 2016 at 11:30:25AM -0700, Jacob Hoffman-Andrews wrote: >> > Let's Encrypt recently did its first update of its Subscriber Agreement, >> > and

[Acme] Inconsistent abbreviations for resource names

Morning, the current draft contains a few inconsistencies in the resource naming. 1) https://ietf-wg-acme.github.io/acme/#rfc.section.6.1 mentions "revoke-certificate", while it's called "revoke-cert" in the rest of the document. 2) There's "new-account", but the account resource is called

Re: [Acme] Simplifying ToS agreement

> > I would argue that we don't need to support it explicitly, because > returning an error with a link to an out-of-band URL for re-agreeing is > sufficient, and matches the most likely flow. This is an interesting idea. Maybe that's also something we could to for the initial registration?

Re: [Acme] PRs for unparallelization and new-nonce

The following PR has been merged: 2016-09-09 0:15 GMT+02:00 Jacob Hoffman-Andrews : > > #163 - Make duplicate new-reg return 200 > It should return a status code 200 now and the URI in a content-location header. I have two questions: 1. Should we reallly use

Re: [Acme] Simplifying ToS agreement

2016-09-08 23:56 GMT+02:00 Jacob Hoffman-Andrews : > On 09/08/2016 02:32 PM, Richard Barnes wrote: > > So what, we should just delete it? Are you arguing that this > functionality is unnecessary? > > I'm arguing for the changes in https://github.com/ietf-wg-acm > e/acme/pull/167,

Re: [Acme] Fwd: New Version Notification for draft-shoemaker-acme-ip-00.txt

>From RFC 2616: A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. I guess an IP address is not considered an

Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2

One potential issue I can see with embedding certificates with the currently proposed format directly into orders are alternative chains. Chains usually do not change between orders, so they could be kept with separate URIs for cachability and less bloat in the order response. e.g.

Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2

> > Sean, > > The working group felt pretty clearly that the BEGIN/END base64 encoding > was the format used by "all" web servers and that anything else would > require the client to translate into that format. > That's true, but using a format that can just be dumped without inspection makes

[Acme] Fwd: Inconsistent abbreviations for resource names

I'm resending this message as there were no responses and nothing changed. -- Forwarded message -- Morning, the current draft contains a few inconsistencies in the resource naming. 1) https://ietf-wg-acme.github.io/acme/#rfc.section.6.1 mentions "revoke-certificate", while it's

Re: [Acme] Returning multiple errors

2017-11-21 19:55 GMT+01:00 Jacob Hoffman-Andrews : > On 11/20/2017 08:24 PM, Martin Thomson wrote: > > Is this better cast as "sub" problems, or just "additional" problems? > > I think "additional" is the wrong semantic, because it implies that the > first error is hoisted to the

Re: [Acme] Assisted-DNS challenge type

2018-01-23 8:09 GMT+01:00 Ilari Liusvaara : > On Mon, Jan 22, 2018 at 05:09:53PM -0800, Jacob Hoffman-Andrews wrote: > > > > To fix that, the CA could assist the user by providing narrowly-scoped > > DNS hosting: It would serve only TXT records used in validating DNS > >

Re: [Acme] Guessable URLs and unprotected orders lists

2018-01-11 20:36 GMT+01:00 Ilari Liusvaara : > On Thu, Jan 11, 2018 at 08:23:26PM +0100, Sophie Herold wrote: > > Hi, > > > > challenge tokens "MUST have at least 128 bits of entropy", at the same > > time it seems trivial to guess order and authorization URLs like the >