Re: [Acme] acme subdomains open items

I wasn’t part of IETF 109 .. was it discussed simply to give CAs the ability to choose whether it tries authz against parent domains without the client’s requesting it? This is how our (non-ACME) Sectigo integration works currently, and it suits us well. -F > On Dec 4, 2020, at 02:23, Owen

Re: [Acme] dns-01 challenge limitations

> On Sep 11, 2020, at 9:08 AM, Simon Ser wrote: > > For instance, it would be possible to require users to add a short public key > in a DNS TXT record, then ask the ACME client to sign challenges with that > key. > Something like this would significantly ease the development of ACME clients.

Re: [Acme] Review of draft-friel-acme-subdomains-02

is the client to indicate that they want to authz the parent domain (example.com) rather than the literal identifier (sub0.example.com)? And for foo.bar.example.com, how shall the client indicate which parent domain is to be used for authz? Thank you! cheers, -Felipe Gasper > On Sep 2, 2020, at 5

[Acme] ACME subdomains

As regards https://tools.ietf.org/html/draft-friel-acme-subdomains-02 ... Is the idea that the client will, if requesting authz on sub.example.com, *only* be able to do authz against the parent domain (example.com)? It would seem advantageous—from the client’s perspective, anyway—to allow a

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

> On Jan 21, 2020, at 8:04 AM, Ryan Sleevi wrote: > > On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel) wrote: > > Also, the linked document states: > > > >The call flow illustrates the DNS-based proof of ownership mechanism, > >but the subdomain workflow is equally valid for HTTP

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

> On Jan 21, 2020, at 7:13 AM, Owen Friel (ofriel) wrote: > >> >> Will this document eventually also describe subdomain authz via the standard >> ACME workflow? >> >> > > [ofriel] That’s the exact workflow that the document is attempting to > describe, so maybe it needs to be clarified. >

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

iers to the > DNS-01 challenge is a policy decision by Let's Encrypt. You’re right; I was misreading it. Sorry for the confusion. -F > > On Mon, Jan 20, 2020 at 7:32 AM Felipe Gasper wrote: > Will this document eventually also describe subdomain authz via the standard > ACM

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

ving access to a subdomain’s, though? I thought that was the reason why ACME limits wildcard authz to DNS. cheers, -Felipe Gasper > On Jan 20, 2020, at 6:48 AM, Owen Friel (ofriel) wrote: > > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 documents the &

[Acme] Rate limits and ACME

document’s “detail”. It’s awfully brittle, but there’s apparently no other way. An ACME extension to solve this, then, seems worth proposing. Thoughts? Thank you! -Felipe Gasper Mississauga, Ontario ___ Acme mailing list Acme@ietf.org

Re: [Acme] orders, authorizations, and identifiers (oh my)

te. > > The server policy is exercised by the choice of authorizations/challenges in > the pending order, not by the client deciding which authorizations in an > order to satisfy. > > On Tue, Jul 16, 2019 at 10:11 AM Felipe Gasper > wrote: > > > On Jul 16, 2019,

[Acme] orders, authorizations, and identifiers (oh my)

would not reference “www”, even though it is that domain’s corresponding authz object? Or would a client be accountable for implementing a “best-match authz” lookup to determine which authz corresponds to a given domain? Thank you! -Felipe Gasper Mississauga, Ontario

Re: [Acme] DNS challenge server steps missing detail?

> On Nov 27, 2018, at 3:32 PM, Danek Duvall wrote: > > Section 8.4 of the ACME spec says: > >To validate a DNS challenge, the server performs the following steps: > 1. Compute the SHA-256 digest of the stored key authorization > 2. Query for TXT records for the validation domain

[Acme] vestige of certificate GET

Hi all, Draft 16 has this: - An ACME client MAY attempt to fetch the certificate with a GET request. If the server does not allow GET requests for certificate resources, then it will return an error as described in Section 6.3 . On receiving such an error, the client

Re: [Acme] example.com is used all over the draft

Are “acmeserver.com” or “caserver.com” reserved domains? What about: acme-client.example.com acme-server.example.com ? -FG > On Sep 20, 2018, at 8:58 AM, Kas wrote: > > From section 2 : > "The CA verifies that the client controls the requested domain name(s) by > having the ACME client

[Acme] nomenclature: “POST-as-GET”

FWIW, it seems to me like, if the HTTP verb being used is, in fact, “POST”, then a more appropriate term for the proposed fix for the identity correlation problem identified last week would be “GET-as-POST” rather than “POST-as-GET”. “POST-as-GET” sounds to me like the actual HTTP verb is a

Re: [Acme] ACME breaking change: Most GETs become POSTs

nts in Github a little later > today, and will incorporate the above unless people think it's awful. > > --Richard > > On Thu, Aug 30, 2018 at 8:46 PM Felipe Gasper wrote: > > > > On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews wrote: > > > > (R

Re: [Acme] ACME breaking change: Most GETs become POSTs

> On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews wrote: > > (Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's > Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)") > > On 08/30/2018 11:17 AM, Felipe Gasper wrote: > >

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

available within seconds, theoretically the delay between request and issuance could be much longer (e.g., for OV/EV), such that it might be prudent for that privileged process to give the order ID to the user and have the user poll for the certificate, e.g., via cron. -Felipe Gasper Mississauga

Re: [Acme] tls-alpn-01 spec: TLS-SNI history

> On Jun 21, 2018, at 10:53 AM, Ilari Liusvaara > wrote: > > On Thu, Jun 21, 2018 at 09:53:07AM -0400, Felipe Gasper wrote: > >> I would guess that the reason why Apache didn’t get much grief over >> TLS-SNI is that many--most?--hosting services require a certific

[Acme] tls-alpn-01 spec: TLS-SNI history

a significant part of why TLS-SNI did not work. -Felipe Gasper Mississauga, ON ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] TLS-ALPN implementation

Update: I got it working. Seems to have been a server implementation bug on my end. Sorry for the noise! -F > On Jun 17, 2018, at 8:01 PM, Felipe Gasper wrote: > > I’ve been playing with this. As far as I can tell I have it set up correctly, > but it’s not working. >

Re: [Acme] TLS-ALPN implementation

I’ve been playing with this. As far as I can tell I have it set up correctly, but it’s not working. In response to this challenge: https://acme-staging-v02.api.letsencrypt.org/acme/challenge/leSSBO7cbljpzjZqGhzqSRm8lphqe1RX_jI3Mx8eEeU/136484133 … I set up this certificate: -BEGIN

[Acme] missing comma

e one here as well. -Felipe Gasper ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

[Acme] ACME and Authz domain name

The latest CAB forum guidelines stipulate that: 1) Demonstration of control of a CNAME for the given FQDN can suffice for authorization. 2) “The CA may prune zero or more labels from left to right until encountering a Base Domain Name and may use any one of the intermediate values for the

Re: [Acme] Concerning alternative formats …

> On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman wrote: > > Especially with CT logging being a pragmatic requirement, time-to-delivery > for certificates is likely to increase (slightly) rather than decrease. Quick point: the alleviation of polling would go for authz

Re: [Acme] Concerning alternative formats …

> On Mar 5, 2018, at 9:35 AM, Jörn Heissler <acme-sp...@joern.heissler.de> > wrote: > > On Mon, Mar 05, 2018 at 09:11:02 -0500, Felipe Gasper wrote: >> Regarding alternative formats, I think ACME over WebSocket would be a great >> thing. Replay-nonce would go a

[Acme] Concerning alternative formats …

For what it’s worth: Regarding alternative formats, I think ACME over WebSocket would be a great thing. Replay-nonce would go away, and clients wouldn’t need to poll for the certificate unless the connection dropped. The server could send the certificate as soon as it’s ready. A simple

Re: [Acme] Optional "Wildcard" authorization field

One (fairly) obvious use of the “wildcard” flag is for status reporting without the context of the original newOrder. The client can thus more easily say: Authorization for “*.example.com”: $message … without having to correlate the authz object with the order. -FG > On Mar 2, 2018, at 12:32

Re: [Acme] Specify which JWS serialization is used

Could there be some way of using a header like “Accept” for a server to indicate whether it supports jose, jose+json, or both? -F > On Mar 2, 2018, at 9:50 AM, Richard Barnes wrote: > > Hey all, > > I merged #395 last night (thanks, Logan!). While I was reviewing that, I >

Re: [Acme] -09 draft: Challenge objects?

lipe, > > Does this PR from Richard Barnes address your feedback? > https://github.com/ietf-wg-acme/acme/pull/399 > > Thanks! > > On Sat, Jan 13, 2018 at 8:50 AM, Felipe Gasper <fel...@felipegasper.com> > wrote: > Hello, > > I’ve been looking over

[Acme] -09 draft: Challenge objects?

as objects per se in section 7.1 of the draft. Thank you! -Felipe Gasper Mississauga, ON ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme