Re: [Acme] New ACME Challenge Proposal

Hi, We've just submitted this document to the IETF datatracker. Thanks all! On Mon, Sep 12, 2022 at 5:00 PM Peter Thomassen wrote: > Hi Antonios, > > On 9/9/22 10:57, Antonios Chariton wrote: > > Although ACME is a protocol that can be used by any CA, and is not > necessarily tied to WebPKI, o

[Acme] Submitting a draft RFC to the ACME WG

Hi! I've submitted a draft but I think I made a mistake in the process and it didn't come to the ACME WG queue. Is there something you can do on your end to make the target of this the ACME WG? https://datatracker.ietf.org/doc/draft-todo-chariton-dns-account-01/ Cheers! Amir

Re: [Acme] Submitting a draft RFC to the ACME WG

Ilari, agreed on registering it to the Underscored and Globally Scoped DNS Node Names registry. I've updated the draft to include that. As for why _ and not -, I'll leave that to Antonis to explain the historical reason of. Note, we had submitted an informational post earlier as well: https://mai

Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest

I've read the draft and think it's a valuable addition for the ACME ecosystem. On Wed, Nov 16, 2022 at 9:11 AM Richard Barnes wrote: > I have read the draft, and it seems well thought through. Especially if > there is implementor interest, this seems like a sane thing for the WG to > adopt. > >

Re: [Acme] ARI: Indication if certificate will be revoked

My concern with this is that it creates a bit of a requirement to revoke by/on that time, which doesn't seem to be the intent of ARI I think? Also what should the precision of this time field be? day/hour/etc? On Wed, Mar 22, 2023 at 10:35 AM Andrew Ayer wrote: > I'm working on adding an ARI cl

Re: [Acme] note takers

advance, > > Deb (and Yoav) > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > -- Amir Omidi (he/them) ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Port for HTTP and ALPN Challenge

The certificates are not required to be generated exclusively on the host that supports the website. Can you elaborate if there are any concerns regarding the implementation of issuance delegation? An alternative approach might involve creating another internal system to manage certificate lifetime

Re: [Acme] DNS-ACCOUNT-01 Updates

I think what decision happens here will probably end up setting the precedent on either these digits are "version numbers" of the "base challenge types" (Not sure what to call them), and they act as a replacement of them. Or that they are another flavor of the technologies/protocols used in those c

Re: [Acme] Call for adoption of draft-misell-acme-onion-02

; Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > -- Amir Omidi Software & Security Engineer aaom...@google.com ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Call for adoption of draft-misell-acme-onion-02

Wrong URL, apologies: https://www1.hi.cn/hica-vs-letsencrypt/ On Thu, Jun 8, 2023 at 15:08 Amir Omidi wrote: > I support the draft as it is for adoption. I’m also curious if > https://www.hi.cn/hica-vs-letsencrypt/ is potentially using the draft as > well for their onion support? &

Re: [Acme] DNS-ACCOUNT-01 Updates

account is being referred to. They would likely >> assume it would be the account on their DNS provider.I think 'DNS-02' >> as a newer version of the DNS challenge type would be less confusing. >> -- >> *From:* Acme on behalf of A

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

at > > > > > > Any email and files/attachments transmitted with it are intended solely > for the use of the individual or entity to whom they are addressed. If this > message has been sent to you in error, you must not copy, distribute or > disclose of the information it

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

ing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!cZZsOZ0v5-kwi0u2XFbPWT2ddKQUeoKDOKjmTA0uStA0dZuwoAFoA5bphSBDyICkcF08SK8ddsv-a3_g8yXgZATe$> > > *Any email and files/att

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

I have a couple of concerns with this draft so far: 1. As far as I understand from the BRs, the subscriber is effectively the entity that controls the private key of the certificate that was issued. The subscriber is not the owner of the domain. The subscriber is the cloud provider. Th

Re: [Acme] DNS-ACCOUNT-01 Updates

more difficult without many tangible benefits. Are there any benefits that I'm missing or other alternatives? Does the working group have a strong feeling on either the current format or the proposed format? On Fri, Jun 23, 2023 at 4:27 PM Michael Richardson wrote: > > Amir

Re: [Acme] Fwd: New Version Notification for draft-sweet-iot-acme-04.txt

This seems very interesting! I would love a good mechanism for local certificates, even just in basic development. A couple of points of feedback: 1) Name constraints on the root: https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#name-root-ca-certificate I'd recommend specifying that t

Re: [Acme] Fwd: New Version Notification for draft-sweet-iot-acme-04.txt

> If the certificate is restricted to local domain names only, I suggest allowing validity up to 10 years. Then why use ACME to begin with? 10 years means you never actually get to make sure the certificate issuance automation works. At least from my understanding, the point of this draft is to m

Re: [Acme] Decentralized the ACME

I agree. Reading this I’m not entirely sure what problems it’s trying to solve. On Fri, Nov 10, 2023 at 08:44 Tim Hollebeek wrote: > I would suggest that before discussing block chains and smart contracts > for revocation, it would be best to start with a use case and a problem to > solve. Othe

Re: [Acme] Indicating scope in DNS validation label

Hi! Thank you for suggesting these improvements. I'm not sure if it makes sense to add this complexity to the level of domain validation that happens for ACME. Main reasons I see for this: - A lot of DNS ACL systems have per-zone ACLing, rather than per-label. It's not going to immediatel

Re: [Acme] [Errata Held for Document Update] RFC8555 (6843)

There is nothing blocking .dev domains responding over http. To be specific, a TLD can not block a protocol like that. Amir Omidi (he/them) On Thu, Jan 11, 2024 at 22:13 Rob Sayre wrote: > It sounds like that's a bug or at least a discrepancy. > > .dev domains should never res

Re: [Acme] Mail regarding craft of hash for draft-ietf-acme-dns-account-challenge

>From my understanding, under ACME we treat that entire accountURL as the userID. So I think that URL will need to be stable. On Fri, Feb 2, 2024 at 2:36 AM Seo Suchan wrote: > for some ACME servers they have multiple allowed acme endpoint domains, > and server doesn't know what domain name clie

Re: [Acme] Mail regarding craft of hash for draft-ietf-acme-dns-account-challenge

iple valid path (ex: acme-v1.ca.com and > acme-v2.ca.com) , would server need try for both subdomain and lookup > every possible valid path? > 2024-02-03 오전 1:35에 Amir Omidi 이(가) 쓴 글: > > From my understanding, under ACME we treat that entire accountURL as the > userID. So I think that

Re: [Acme] Mail regarding craft of hash for draft-ietf-acme-dns-account-challenge

1. Does that make sense? > > Aaron > > On Sat, Feb 3, 2024 at 1:18 PM Amir Omidi 40aaomidi@dmarc.ietf.org> wrote: > >> No, the accountURL/URI that new-account returns is the only authoritative >> path. I'll make sure that it is spelled out in the RFC. If an acme

Re: [Acme] Mail regarding craft of hash for draft-ietf-acme-dns-account-challenge

s. This way, the account KIDs no longer have to be unique, and I think it's a more general solution to this problem. On Tue, Feb 6, 2024 at 5:35 PM Amir Omidi wrote: > We are using the `kid` value. And from my understanding in the ACME spec, > when a client is responding with a POST r

Re: [Acme] I-D Action: draft-ietf-acme-scoped-dns-challenges-00.txt

Hi all! We've worked on incorporating the changes in https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ into our draft introducing DNS-ACCOUNT-01. This draft now introduces both DNS-ACCOUNT-01, and DNS-02. The main difference from before is the introduction of a `sc

Re: [Acme] [Technical Errata Reported] RFC8555 (5732)

Yes please. This is something I noticed while doing a reading of this draft a while back. Amir Omidi (he/them) On Wed, Feb 21, 2024 at 16:57 Rob Stradling wrote: > Given the recent interest in processing the backlog of RFC8555 errata > reports, could I please ask again for > https:

Re: [Acme] IETF 119 Agenda

I am not going to be able to present or attend this time around. (It's Nowruz, and to anyone else who celebrates it, happy Nowruz!) I will probably be presenting in person in Vancouver for the next session. For folks who haven't seen it yet, please take a look at the updated draft for dns-account

Re: [Acme] acme-scoped-dns-challenges: account hash

Thank you! I've made this PR to be consistent between the KIDs: https://github.com/aaomidi/draft-ietf-acme-scoped-dns-challenges/pull/41 On Sat, Mar 16, 2024 at 8:31 AM Richard Körber wrote: > Thank you! Yes, that fixed the problem. > > Looking at the specs again, I should have figured it out my

Re: [Acme] Can we say dns-account-01 challenge's account label isn't for security?

Hmm, so to understand properly this would require a malicious DNS server that the CNAME has been delegated to, actively trying to cause a hash collision? That's fair. Although I do think this problem can be mitigated by using CAA with account binding? https://www.rfc-editor.org/rfc/rfc8657 I woul

Re: [Acme] scope in dns-account-01 and dns-02 challenge

> I think it doesn't specify how the scope for a given challenge is decided and communicated. Great point. My intention that I should probably clarify in the draft is that the server picks based on the Authorization object: - If wildcard: true on the authorization object associated with the

Re: [Acme] scope in dns-account-01 and dns-02 challenge

], "scope": "host" // Or "wildcard", or "host" } This wouldn't remove the existing wildcard or subdomainAuthAllowed fields. On Tue, Mar 19, 2024 at 7:36 PM Jacob Hoffman-Andrews wrote: > Seo Suchan said: > > Would it be

Re: [Acme] scope in dns-account-01 and dns-02 challenge

icate to work and be able to answer questions when their manager asks them "so what is the deal with these certificate challenges? Which one are we going to use and why?" On Thu, Mar 21, 2024 at 2:42 PM Jacob Hoffman-Andrews wrote: > On Wed, Mar 20, 2024 at 5:57 PM Amir Omidi 40aaomi

[Acme] Re: WGLC for draft-ietf-acme-ari

I also support sending this through! On Fri, Oct 11, 2024 at 7:21 AM Q Misell wrote: > I have read the draft and am happy with it in its current state. I support > sending this draft to the IESG. > > Good work Aaron! > -- > > Any statements contained in this email are

[Acme] Re: 回复: [EXTERNAL] Re: Introducting a new draft about adding a new ACME challenge type: public key challgenge

It is supposed to be. However there are clients that create a new account for each certificate issuance attempt but they’re not following the spec. The account is how things like rate limit increases, or binding an account to an external service takes place. On Thu, Nov 28, 2024 at 22:33 Michael

[Acme] DNS-ACCOUNT Challenge Update

ients - Better explanation of use cases like multi-region deployments We welcome your feedback on these changes. Best regards, Amir Omidi ___ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org

[Acme] Re: DNS-ACCOUNT Challenge Update

the ACME client and managing > certificates? You would need to specify what a valid construction of the > domain label would be, and the CA would need to validate that when they > validate a challenge if they are no longer fully in control of the label, > but that seems to me to be

[Acme] dns-account-challenge: Updates and next steps

Hey folks, I wanted to give you an update that the current version of the draft has been approved as a validation method b

[Acme] Re: DNS-ACCOUNT Challenge Update

;> Hi everyone, >>> >>> Based on the feedback received, we've published a new version of the >>> DNS-ACCOUNT-01 draft >>> (https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/). This >>&g