Re: [Acme] draft-ietf-acme-subdomains and public suffixes

On Mon, May 16, 2022 at 7:47 AM Peter Thomassen wrote: > FWIW, the notion is already codified in RFC 7489 (Section 3.2) and RFC > 9091 (in the title, albeit experimental). Yes, doubly unfortunate, as the DBOUND WG can attest ;) Sure. However, if the relevant part of the DNS space is, at the ti

Re: [Acme] draft-ietf-acme-subdomains and public suffixes

On Thu, Apr 7, 2022 at 10:36 AM Peter Thomassen wrote: > Now, should it be possible for the DNS admin of eu.org to request a > certificate for example.de.eu.org (or subdomains thereof) through the > mechanism described in the draft, although there is a public suffix in > between? (I don't think s

Re: [Acme] Extending (A)RI to non-ACME use cases

On Fri, Feb 18, 2022 at 12:51 PM Rob Stradling wrote: > draft-aaron-acme-ari-01 describes an "extension to ACME", but ISTM that > the core, OCSP-inspired protocol is not specific to ACME at all. I > appreciate that the document author's employer and this WG are only > directly concerned with the

Re: [Acme] working group call for adoption

On Wed, Sep 1, 2021 at 8:28 PM Michael Richardson wrote: > > Ryan Sleevi wrote: > >> This seems to make the ACME server keep a bunch of state itself > (across > >> multiple HTTPS/TLS connections), while I suspect that most of us > would like > &g

Re: [Acme] working group call for adoption

On Wed, Sep 1, 2021 at 7:45 PM Michael Richardson wrote: > This seems to make the ACME server keep a bunch of state itself (across > multiple HTTPS/TLS connections), while I suspect that most of us would like > the client to be responsible for keeping that authorization around. > > Would you agre

Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04

On Sat, Aug 14, 2021 at 6:18 PM Brian Sipos wrote: > Does it seems like it's at all reasonable, from the perspective of the > security area and focus on PKIX (documents and tools), for an application > profile like this to say to conform to "... RFC 5280 with the exception of > the FQDN/IP-addres

Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04

On Fri, Aug 13, 2021 at 4:04 PM Roman Danyliw wrote: > I think the current options might be: > > (1) Roughly what you said above + Make it clear that this document is NOT > using the RFC5280 profile and simply reusing the data structures (but not > the validation logic). Related to this, and exc

Re: [Acme] WGLC for ACME DTN Node ID

With admittedly very little context for this specific use case, a few things stand out: Section 2 states "Any identifier of type "uri" in a newOrder request MUST NOT have a wildcard ("*") character in its value." This seems to unnecessarily constrain the character space. While I suspect the purpos

Re: [Acme] should acme-subdomains support http-01 challenges?

Responding to part of this. On Sun, Dec 13, 2020 at 3:47 PM Michael Richardson wrote: > > If a client is advertising multiple ADNs it can authorize, should the > > supported challenge type be per ADN? e.g. dns-01 and http-01 for > > foo1.foo2.bar.example.com but only dns-01 for examp

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

On Wed, Dec 9, 2020 at 12:00 PM Richard Barnes wrote: > Hi ACME folks, > > I'd like to bring this proposed extension to ACME to the attention of the > working group. This work builds on Alexei's document defining the "email" > identifier type, and defines > > (1) a mechanism for validating ema

Re: [Acme] acme subdomains open items

On Tue, Dec 8, 2020 at 8:14 PM Michael Richardson wrote: > > Alas, I'm equally at a loss to understand what you're asking here, > as I > > can't make much sense of your question? > > dns-01 challenges for bar.bar.foo.example do not have to show control over > foo.example. > Yet, you seem

Re: [Acme] acme subdomains open items

On Tue, Dec 8, 2020 at 4:33 PM Michael Richardson wrote: > > Ryan Sleevi wrote: > >> The client has control over lex.example, but and can prove it with > dns-01 > >> TXT > >> record placed at _acme-challenge.lex.example. Why does it matt

Re: [Acme] acme subdomains open items

On Mon, Dec 7, 2020 at 8:30 AM Michael Richardson wrote: > > Ryan, I'm not really following this conversation. > Probably my mental model of dns-01 challenges is lacking. > The word "window" does not appear in RFC8555 or acme-subdomains, so that's > your wo

Re: [Acme] acme subdomains open items

On Sun, Dec 6, 2020 at 9:32 PM Owen Friel (ofriel) wrote: > [ofriel] Are there any benefits or security advantages in #1 (client > giving server options) vs. #2 (server giving client options)? With #2, the > client does not have to explicitly divulge any information about its level > of domain co

Re: [Acme] acme subdomains open items

Thanks for bringing it to the list, Owen. This is something we're trying to lock down in the CA/B Forum, at least with respect to the 'http-01' method, by making it clear that, like tls-alpn-01, it cannot be used as an Authorization Domain Name (i.e. a domain and all of its descendents), only as a

Re: [Acme] CAA DNS RR IODEF e-mail spam && client side CAA verification

On Thu, Oct 22, 2020 at 11:59 AM Anton Luka Šijanec wrote: > Hello! > > I hope I am addressing this e-mail to the correct mailing list. After > glancing through the CAA DNS RR specifications for allowing only > specific CAs to issue certificates for a specific domain, I saw that > the iodef field

Re: [Acme] dns-01 challenge limitations

On Sun, Sep 13, 2020 at 5:25 AM Simon Ser wrote: > > The question would be whether or not it would get implemented. > > Yes, this is why I'm writing to this mailing list. Maybe I should've CC'ed > some > Let's Encrypt specific mailing list as well. It's certainly possible, but to be clear: any

Re: [Acme] dns-01 challenge limitations

s. that way any given acme client would > only need access to the inbox of that specific mail which probably is a > whole lot easier than DNS stuff. > > Am So., 13. Sept. 2020 um 11:13 Uhr schrieb Simon Ser >: > >> > On Friday, September 11, 2020 4:26 PM, Ryan Sleevi < &

Re: [Acme] dns-01 challenge limitations

On Fri, Sep 11, 2020 at 9:28 AM Philipp Junghannß wrote: > problem is obviously also the CA/Browser Forum has certain requirements, > and I guess having access to some kind of direct verification at the time > of issue might be probably one of these. > This is the correct answer. While the IETF

Re: [Acme] ACME subdomains

On Thu, Sep 3, 2020 at 9:47 AM Salz, Rich wrote: > >- I followed the patterns used in RFC8555 which consistently uses >example.com as the ACME server base domain and example.org as the >client certificate identifier base domain, but yes Ryan I did find this a >source of confusion

Re: [Acme] ACME subdomains

There’s a lot of mixing of example.org and example.com here, in ways I’m having trouble making sense of. I just wanted to confirm those were typos, since we have recently seen some confusion around this space. ___ Acme mailing list Acme@ietf.org https://w

Re: [Acme] CAA in draft-ietf-acme-client-01.txt

Ben: This text was intended towards auditors, and is indeed part of the ongoing logging requirements imposed on CA. While it’s easy to imagine a hypothetical world of CAA transparency and talk of it as if it was a thing, there are a number of real and practical operational challenges that make it m

Re: [Acme] Onion address validation extension

On Thu, Jul 9, 2020 at 8:30 AM Ilari Liusvaara wrote: > On Wed, Jul 08, 2020 at 08:03:40PM +0200, Sebastian Nielsen wrote: > > Couldn’t it be done in the way that the ACME server creates a nonce. > > I am not sure why the client nonce is there. And I can not quickly find > any discussion about cr

Re: [Acme] AD Review of draft-ietf-acme-email-smime-07

On Fri, May 29, 2020 at 1:08 PM Russ Housley wrote: > >> ** What was the thinking behind the document status being informational? > > I don't think there was much thought or discussion of this point. I am > > flexible. I think when I started it was not very clear how much > > support/interest th

Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

On Sat, May 2, 2020 at 2:11 PM Ben Schwartz wrote: > > > On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov > wrote: > >> Hi Ben, >> On 21/04/2020 01:12, Ben Schwartz wrote: >> >> >> On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov >> wrote: >> >>> Hi Ben, >>> >>> My apologies for missing your email

Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

On Tue, Mar 31, 2020 at 6:24 PM A. Schulze wrote: > > > Am 12.03.20 um 19:51 schrieb Salz, Rich: > > This mail begins a one-week working group last call on > https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/?include_text=1 > (hopefully not to late ...) > > Hello @all, > > I became awa

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

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 based proof of > >ownership. > > > > Can’t I have HTTP

Re: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

On Thu, Oct 10, 2019 at 5:22 AM Yaron Sheffer wrote: > I am wondering though about this sentence: A CA can "also offer additional > validation methods/issuance flows which also use the "dns-01" method." > Doesn't specifying "dns-01" restrict the CA to one particular > validation/authorization flo

Re: [Acme] Warren Kumari's Discuss on draft-ietf-acme-ip-07: (with DISCUSS and COMMENT)

On Tue, Oct 1, 2019 at 2:28 PM Warren Kumari wrote: > > The second scenario you suggest is also something covered by 8555, if > the attacker is able to fully control the network, then they can control > ACME. This is not just the case for IP validation, if an attacker is able > to hijack BGP rout

Re: [Acme] draft-ietf-acme-star

On Wed, Sep 11, 2019 at 12:09 PM Thomas Fossati wrote: > 2 The pre-dating that the ACME server MUST do on cert rotation to > prevent the client to fetch a not-yet-valid credential (i.e., the > overlap you mention). > > IIUC, you are suggesting to drop the former, i.e., removing the ability >

Re: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

On Tue, Aug 27, 2019 at 2:28 AM Yaron Sheffer wrote: > The new version contains some significant changes: > > - Addition of the STIR use case. > - Refinement of the CDNI use case. > - Addition of the CSR template (partial, more work required). > - Further security considerations (work in progress

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

On Thu, Apr 25, 2019 at 2:27 AM Ilari Liusvaara wrote: > On Wed, Apr 24, 2019 at 01:48:24PM -0400, Ryan Sleevi wrote: > > On Wed, Apr 24, 2019 at 1:34 PM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > > If that's roughly

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

On Wed, Apr 24, 2019 at 1:34 PM Ilari Liusvaara wrote: > > If that's roughly correct, would you agree a possible mitigation > > (notwithstanding complexity concerns) 'could' be the use of a client > hello > > extension, echo'd by the server (thus confirming it understands the > > protocol, and is

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

On Wed, Apr 24, 2019 at 10:23 AM Ilari Liusvaara wrote: > I am not sure ALPN extension prevents exploitation. > > > Consider TLS SNI NAT (yes, such things exist) with: > > - Connections without SNI are handled in some safe way. > - Loose registration practices (which made TLS-SNI-01/02 insecure)

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

Cs, HP iLO, IBM RSA..). As such, > there are > mcr> no cloud issues involved. > > Ryan Sleevi wrote: > > I’m a bit confused by understanding how this bit fits into the > > discussion. > > > Is the concern that the draft-acme-ip would not work for

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

On Tue, Apr 23, 2019 at 5:18 PM Michael Richardson wrote: > I ommited your great explanation of the situation. > *I* think that certificates bound to IP addresses are useful for things > like > server management systems (Dell DRACs, HP iLO, IBM RSA..). As such, there > are no cloud issues involv

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

On Tue, Apr 23, 2019 at 4:28 PM Michael Richardson wrote: > > In a world where IPs were possible to be validated using TLS-ALPN, > and > > the information omitted from the request, if evil.example/Customer B > > can serve a certificate that confirms the response for 10.0.0.2, then >

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

On Tue, Apr 23, 2019 at 2:28 PM Michael Richardson wrote: > > Ryan Sleevi wrote: > > The latter only becomes a consideration if multiple IPs are > terminated > > at the same TLS layer, and that TLS termination layer doesn't > consider > >

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

fusing to prohibit the use of SNI altogether for IP address validations. > However, I'd greatly appreciate any explanations as to why it is preferable > to include the SNI extension. > > Thanks, > Corey > > -- > *From:* Ryan Sleevi > *

Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

On Tue, Apr 16, 2019 at 9:55 PM Corey Bonnell wrote: > Hello, > > Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge, an > SNI value with the in-addr/ipv6.arpa domain name corresponding to the > iPAddress being validated MUST be specified. I have a concern that this > requirement

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-00.txt

On Tue, Jan 15, 2019 at 1:58 PM Rifaat Shekh-Yusef wrote: > The proposed mechanism does not suggest the CA perform a domain validation > based on > an attestation from the Device Authority. > Instead, the Client that already has an account with the ACME server and > proved that it has control > o

Re: [Acme] ACME DV Security Considerations Draft

On Sun, Oct 21, 2018 at 6:48 PM Benjamin Kaduk wrote: > On Sun, Oct 21, 2018 at 05:25:40PM +, Salz, Rich wrote: > > * It does not seem to be related to ACME - that is, what you’re > describing is more broadly a set of concerns with the methods that may be > used to validate a domain. > >

Re: [Acme] ACME DV Security Considerations Draft

Thanks for posting this. It does not seem to be related to ACME - that is, what you’re describing is more broadly a set of concerns with the methods that may be used to validate a domain. For example, ACME is a strict, well-defined subset of that which permitted by the CA/Browser Forum’s Baseline

Re: [Acme] HTTP redirects in validation [Was: Re: FW: Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)]

On Thu, Aug 30, 2018 at 2:28 PM Ilari Liusvaara wrote: > > The main reason to allow redirects within a domain is if there is a > > unilateral redirect from example.com to www.example.com > > , which is of course incredibly common. It > > seems one should be able to valid

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

On Thu, Jun 21, 2018 at 1:40 PM, Tim Hollebeek wrote: > So the disagreement is whether the it is sufficient to merely use the name > for the > > DNS lookup, and then accept whatever happens afterwards, or whether the > intent > > was that the web page should be retrieved in much the same way as i

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

On Thu, Jun 21, 2018 at 8:40 AM, Tim Hollebeek wrote: > > > TLS-ALPN addresses the latter problem by requiring the server_name to > match > > the validation target (which is AFACIT also required by the Baseline > > Requirements). This stops claiming arbitary names from allowing > > misvalidations

Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

On Thu, Jun 21, 2018 at 8:30 AM, Tim Hollebeek wrote: > The current ABNF in 6844 is basically broken, and doesn’t express what it > was intended to express. I remember staring at it with Corey and wondering > how it got approved … > > > So while I’m not particularly picky on the exact bureaucra

Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

On Wed, Jun 20, 2018 at 4:47 PM, Roland Shoemaker wrote: > As previously discussed on the list the two property names defined in > draft-ietf-acme-caa, "validation-methods” and "account-uri”, do not conform > to the ABNF syntax in RFC 6844 as they contain hyphens. 6844-bis fixes this > by expandi

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

On Wed, Jun 20, 2018 at 5:34 AM, Ilari Liusvaara wrote: > > My understanding was that catastrophic problem was not the default- > vhost behavior of Apache or Nginx, altough that could casue security > issues. But instead, the problem was that many hosting provoders let > one claim arbitrary hostn

Re: [Acme] AD Review: draft-ietf-acme-acme-12

On Fri, May 25, 2018 at 12:08 PM, Eric Rescorla wrote: > > > > IMPORTANT > > > S 6.2. > > > > algorithm in its "alg" field > > > > > > > > o The JWS Payload MUST NOT be detached > > > > o The JWS Protected Header MUST include the following fields: > > > > > > > > * "al

Re: [Acme] ALPN based TLS challenge

On Mon, Feb 26, 2018 at 3:33 PM, Doug Beattie wrote: > > > I would find it a bit surprising if the CABF adopted a domain validation > method that relied on the web hosting provider claiming to do the right > thing (to separate users on shared IP addresses so they cannot request > certs from the o