[Acme] The ACME Renewal Information (ARI) extension

Hello all, In March of 2020, Roland Shoemaker started a conversation[1] on this list regarding a potential new ACME extension, the ACME Renewal Information (ARI) API. The goal of this extension is to allow ACME servers to provide hints to ACME clients about when they should renew the certificates

Re: [Acme] working group call for adoption

Substantive comments: Reading through the history of this document, I see that it started out as simply specifying server behavior to allow particular kinds of authorization re-use, and has now grown to an API extension that adds new fields to various request and response objects. My comments here

Re: [Acme] working group call for adoption

On Wed, Sep 1, 2021 at 5:28 PM Michael Richardson wrote: > Yes, but not necessarily across TLS connections. > > One connects, gets a challenge, sets it up (DNS or HTTP/S), waits for the > authorization check to complete, and sends an order. > > I don't know what letsencrypt does, but my understan

Re: [Acme] The ACME Renewal Information (ARI) extension

-+ 6.4 ACME Renewal Info Object Fields The “ACME Renewal Info Object Fields” registry lists field names that are defined for use in ACME renewal info objects. Template: o Field name: The string to be used as a field name in the JSON object o Field type: The type of value to be provided, e.g., string, boolean, array of string o Reference:

Re: [Acme] working group call for adoption

On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) wrote: > > > Consider an RA that wants to get device certs for thousands of devices > e.g. foo.type-a-sensors.example.org and bar.type-b-sensors.example.org, > The RA would likely do a preAuthz for the domains it owns (e.g. > example.org) rathe

Re: [Acme] ACME RFC - POST-as-GET to Challenge endpoint

RFC 8555 does not intend for Challenges to be able to be fetched individually; their contents are bundled into the Authorization object so that all of the relevant information can be fetched with a single request. The fact that Let's Encrypt allows challenges to be fetched individually is primarily

Re: [Acme] The ACME Renewal Information (ARI) extension

This draft has been officially submitted as https://www.ietf.org/archive/id/draft-aaron-acme-ari-00.html The repository where the source for the draft is managed is at https://github.com/aarongable/draft-acme-ari Thank you, and I look forward to your discussion and comments here, in the github re

Re: [Acme] The ACME Renewal Information (ARI) extension

That makes sense. Of course, the specified URL construction couldn't be as simple as using the serial number, because serial numbers are not (as per the Baseline Requirements, and RFC 6960) guaranteed to be unique except within the context of a single Issuer, and an ACME CA may have multiple Issue

Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-05.txt

A couple comments/questions from my recent read-through. - In Section 3, it says "the validation procedure is successful only if all responses are successful". This language is included because the draft explicitly accounts for multi-perspective validation, with each perspective using a different

Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-05.txt

Brian, Fantastic, thank you for the responses! One further comment inline. On Thu, Sep 30, 2021 at 3:28 PM Brian Sipos wrote: > BS1: This is to handle a basic property that BP bundles are necessarily > independent units, unidirectional, and (currently) have no "conversation" > or "flow" associa

Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-06.txt

Fantastic, this version looks great to me. Just one comment: - Section 3.1: "token-chal:... It MUST contain any characters outside the base64url alphabet..." This was changed from "MUST NOT" and now the meaning is unclear. Aaron On Thu, Oct 14, 2021 at 5:51 PM Brian Sipos wrote: > All, > This

[Acme] Discussion on draft-aaron-acme-ari-01

Hi acme@, As mentioned in today's meeting, there are a few aspects of the current ACME Renewal Info draft that I'd like feedback on. The current draft is at https://www.ietf.org/archive/id/draft-aaron-acme-ari-01.html, and the source is at https://github.com/aarongable/draft-acme-ari. Of course al

Re: [Acme] get-as-post draft

Oh fantastic, the web has needed something like this for a long time. The PKIX WG no longer exists as a standalone entity, but this would be very useful for OCSP as well, since that protocol mandates POST for any requests that are greater than 255 bytes in length. Aaron On Fri, Nov 12, 2021 at 5

Re: [Acme] tls-alpn-01 question

Just to clear up any potential confusion: the ACME Server and the TLS Server are not the same entity when conducting TLS-ALPN-01 Validation. The ACME Server is, during a TLS-ALPN-01 validation, acting as a TLS Client. According to RFC 8737 Section 3, it must, in its `clientHello` message, include

Re: [Acme] renewal extension

Yes, we still intend to move forward with this. Let's Encrypt already has a rudimentary implementation of the current draft deployed in the Staging environment. I am working on both a more realistic implementation in Let's Encrypt[1] as well as a client implementation in Certbot[2], although that w

Re: [Acme] Renewal Information extension: Proposal to add an Explanation URL

In fact, what BCP 18 has to say on the matter is: > ...protocols are not subject to internationalization; text strings are. So yes, the appropriate place for internationalization here would be at the level of the site pointed at by the URI, not at the level of the URI itself. Regardless, I like th

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

Like Ryan, I'm pretty strongly opposed to including ARI URLs in certificates. The information is not intended for the relying party / user agent, so it amounts to extra bytes on the wire for every handshake that will just be ignored. I'm also opposed to the protocol using HTTP headers or some form

Re: [Acme] confirming the certificate renewal in draft-aaron-acme-ari-01

week. Aaron On Thu, Nov 18, 2021 at 10:43 AM Michael Richardson wrote: > > {Splitting up replies to make threads easier to deal} > > Aaron Gable wrote: > > 2) Considering inclusion of a "this has been renewed" callback > endpoint > > > This is tracked

Re: [Acme] note takers

I've gone through and cleaned things up and I believe the notes are complete: https://notes.ietf.org/s/notes-ietf-113-acme Aaron On Mon, Mar 21, 2022 at 4:14 AM Deb Cooley wrote: > Don't wait until the last minute volunteer now to take notes. > > the acme chairs. > _

[Acme] Fwd: New Version Notification for draft-aaron-acme-ari-02.txt

at meeting, I'd also like to request a call for adoption. Thanks! Aaron -- Forwarded message - From: Date: Mon, Apr 4, 2022 at 10:34 AM Subject: New Version Notification for draft-aaron-acme-ari-02.txt To: Aaron Gable A new version of I-D, draft-aaron-acme-ari-02.txt has be

Re: [Acme] Call for adoption of draft-aaron-acme-ari-02

Apologies for the delay, vacation and then a work conference distracted me. Replies inline: On Mon, May 30, 2022 at 8:54 AM Peter Thomassen wrote: > Hello, > > I have a hard time deciding whether the proposal is a good idea or not, > because the document does not contain sufficient information f

Re: [Acme] meeting notes for IETF 114

The notes I took are available here: https://notes.ietf.org/s/notes-ietf-114-acme Unfortunately I was not able to get the names of many of the speakers due to the live at-the-mic conversations, so if other folks know the names of some of the questioners that would be helpful to fill in. Thanks! A

Re: [Acme] draft-aaron-acme-ari call for adoption

Ah, thanks for the feedback! The certificates in Appendix A aren't showing anything particularly unique to the new protocol, they exist solely to be referenced by Section 4.1 so that a reader can confirm that the request pat

Re: [Acme] Potential race condition attack via account pending order lists

The ACME domain validation protocol is only capable of asserting a single statement: "the entity which controls this account private key also controls this domain name". If someone other than the original applicant also controls the same account private key, the ACME protocol has no way to determi

Re: [Acme] I-D Action: draft-ietf-acme-ari-01.txt

This latest version includes a few small fixes and typo corrections (thank you so much to the folks who pointed them out!) as well as an update to the Current Implementations section. Thanks, Aaron On Wed, Feb 8, 2023 at 3:12 PM wrote: > > A New Internet-Draft is available from the on-line Inte

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

I'm not totally sold on the utility of including extra information in the ARI response, if that extra information will not modify client behavior. If the purpose is to modify human behavior, then I believe the current explanationURL is sufficient. Adding a machine-readable problem document that wou

Re: [Acme] note takers

I've done it before; I'm happy to fill in during Amir's talk. On Tue, Mar 28, 2023 at 4:30 PM Deb Cooley wrote: > Thank you for volunteering. Usually we can get a second person to fill in > during your talk (hint, we need another volunteer). > > Deb > > On Tue, Mar 28, 2023 at 5:00 PM Amir Omid

[Acme] IETF 116: Update on draft-ietf-acme-ari-01

Hi all, My apologies to the whole ACME WG, I'm sorry that I wasn't able to attend the IETF 116 working group meeting as I had planned. My planned slides are available at https://datatracker.ietf.org/meeting/116/materials/slides-116-acme-ari-extension; below is a text summary of my intended presen

Re: [Acme] DNS-ACCOUNT-01 Updates

For what it's worth, I'm in favor of calling it DNS-02. Despite your totally correct descriptions of the disadvantages of this new method, I *do* still view it as a generally-improved version of DNS-01. It's obviously backwards-incompatible, hence the new major version number, but it is generally a

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

Hi all, I support the draft for adoption. Specifically, I think it's a good thing to standardize the onion-csr-01 challenge type. I have two classes of comments that I look forward to discussing in-depth after adoption: 1) Obviously it's valuable for this draft to standardize a method that is alre

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

Yeah, both of these clarifications (the existing one about additional prepended zero octets, and the new one about leading zeros) are explicitly laid out in RFC 7518: > Section 3.4 Digital Signature with ECDSA > ... > The octet sequence representations MUST NOT be shortened to omit any leading zer

Re: [Acme] Practical concerns of draft-ietf-acme-ari

Hi Matt, Agreed with Tim, receiving practical feedback from implementers of the draft standard is very useful. I'll put my thoughts, comments, and questions in-line. On Fri, Jun 23, 2023 at 9:21 AM Matthew Holt wrote: > > With respect to ARI, ACME servers and clients have conflicts of interest.

Re: [Acme] Practical concerns of draft-ietf-acme-ari

On Wed, Jul 19, 2023 at 11:16 PM Ilari Liusvaara wrote: > E.g., the client might be deterministically generating renewal time > from window (the client I wrote does this). This works nicely if the > renewal window does not shift around. However, it becomes heavily > biased toward beginning of the

Re: [Acme] Practical concerns of draft-ietf-acme-ari

On Fri, Jul 21, 2023 at 2:00 PM Matthew Holt wrote: > I simply do not think there is a way to offer a wider renewal window than > the full lifetime of the certificate by offering a narrower renewal window. > I know that sounds silly, but since "backoff and retry" is the One Way to > reliably gett

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

(Apologies if you're receiving this twice; I originally sent it only to the CABForum list, instead of this IETF list.) Hi Paul, I'm sorry that I wasn't able to be at the ACME session last week; I've enjoyed reading the presentation slides and the draft notes that were taken during the session. I

Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME

I concur with what the others have said here. My overarching concern is that this draft seems *too* PQC-specific: the general capabilities it describes are useful outside the context of PQC, and the general ideas herein should be standardized in a more flexible manner. The issue of confirmation of

Re: [Acme] I-D Action: draft-ietf-acme-ari-02.txt

Hi all, This latest version of the ARI draft contains four material changes, based on feedback received in the lead-up to IETF 117: - The "Current Implementations" section is now up-to-date and lists multiple server and client implementations. - The "IANA Considerations" section has been updated

Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME

On Fri, Aug 11, 2023 at 9:00 AM Ilari Liusvaara wrote: > On Tue, Aug 08, 2023 at 09:44:20AM -0700, Aaron Gable wrote: > > > > I think it's a good idea for the ACME protocol to have a mechanism to > > prove control of the cert private key, probably by having the CSR >

Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME

Oh that's fun, I like that idea. Making it explicit: Introduce a new identifier type "keypair-KEM". When included in a newOrder request, an identifier of that type would have a value that is the full KEM public key. The Server would then create an Authorization for that identifier, and the Challen

Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME

n be valid and > cached for 30 days like other auths? for kem keys perspective it doesn't > know what it's agree for, so it's in effect authorizing ACME account for > post that key onto certificate. > 2023-08-12 오전 2:47에 Aaron Gable 이(가) 쓴 글: > > Oh that's f

Re: [Acme] [EXTERNAL] Re: Internet-Draft: PQC Algorithm negotiation in ACME

gt; > > *From:* Seo Suchan > *Sent:* Wednesday, August 16, 2023 9:06 AM > *To:* Mike Ounsworth ; Tim Hollebeek < > tim.holleb...@digicert.com>; Aaron Gable > *Cc:* Russ Housley ; IETF ACME > *Subject:* RE: [EXTERNAL] Re: [Acme] Internet-Draft: PQC Algorithm > negotiati

Re: [Acme] ACME PoP on revocation requests

> I guess revocation tickets / nonces / commitment values are meant to > address that problem. > > > > --- > > *Mike* Ounsworth > > > > *From:* Tim Hollebeek > *Sent:* Wednesday, August 16, 2023 12:59 PM > *To:* Mike Ounsworth ; Aaron Gable < > aa

[Acme] Proposal: ACME Profiles

Hi ACME community, I believe it is time for us to seriously consider the topic of “profiles”. For the purposes of this discussion, a profile is a collection of characteristics which affect the contents of the final certificate issued by an ACME CA. For example, two different profiles might cause

Re: [Acme] Proposal: ACME Profiles

On Thu, Aug 31, 2023 at 2:09 AM Ilari Liusvaara wrote: > 1) There may be a number of orthogonal properties, causing the total >number of possible profiles be very large (the CA-side code is >NOT complex). > I'm not super concerned with combinatorial explosions of profiles. A CA could off

Re: [Acme] Proposal: ACME Profiles

Thanks for the continued discussion, all! Replies to multiple emails inline. On Tue, Sep 19, 2023 at 4:17 PM Ben Burkert wrote: > The way we solve this is at the intermediate CA level, which we refer to > as a SubCA. Each SubCA is an intermediate CA that issues end entity > certs, and a template

Re: [Acme] Decentralized the ACME

Hi Wang, Thanks for your interest in ACME, and for sharing this paper with us. Unfortunately, I think the ideas presented in the paper are undesirable for most website operators, concerning from an implementation perspective, and significantly exceed the scope of this working group. First and mo

Re: [Acme] [Editorial Errata Reported] RFC8555 (6104)

It appears to me (and `git diff -w`) that the only difference between these blocks is whitespace: the original has the code block outdented to the leftmost column of each line, while the new version has the code block starting in the same vertical column as the "in the problem document" text. This

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

Agreed on all counts. It is a sensible addition, and is likely the approach that would be taken by ACME servers that implement pre-authorization. To address Seo's good point, I would suggest inserting the text *just before* the last paragraph of Section 7.4.1, and phrasing it as: "If the construct

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

I believe this erratum should be rejected, for a few reasons: 1) It is not a clarification or fixing an obvious mistake, it is a change to the protocol. Today, many ACME servers (Let's Encrypt included) immediately move an Authorization to the "invalid" state as soon as any Challenge for that Auth

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

Agreed. Especially because the "newAuthz" resource is optional, this omission seems minor. I would accept as an editorial erratum. Aaron On Wed, Jan 3, 2024 at 4:03 AM Deb Cooley wrote: > This errata also had no responses. In this case, I'd suggest rejecting > it, or making it editorial. I do

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

Adding "or false" to the existing sentence seems correct to me, as a technical erratum. Adding the sentence regarding pre-authorizations is purely editorial; there is already text elsewhere in the document which makes that clear. Aaron On Thu, Jan 4, 2024 at 3:32 AM Deb Cooley wrote: > Today's

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

This erratum changed "completed" to "initiated", so the document now correctly allows redirects from HTTP to HTTPS. If you believe that challenges should be able to be initiated over HTTPS as well, this erratum is not the right place for that discussion. But perhaps more importantly, ACME Servers

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

On Sun, Jan 14, 2024, 10:12 Rob Sayre wrote: > On Sun, Jan 14, 2024 at 3:01 AM Deb Cooley wrote: > >> I had this marked as 'hold for update' (vs. 'verified'). I can't tell >> from the discussion how you think we should be handling it. >> > > The erratum says "the challenge must be initiated ove

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

And I think the implication here is that, if an ACME server responds on multiple URIs and reflects those multiple URIs back to the client in the Location header, then that server must also support hashes of those multiple URIs when conducting DNS-ACCOUNT-01. Does that make sense? Aaron On Sat, Fe

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

Looks good to me. Aaron On Fri, Feb 9, 2024 at 3:39 AM Deb Cooley wrote: > The ADs can edit the language of an errata. If we can agree on the > language, they can modify the errata and then mark it as Verified. Below > is what I have for this: > > -- >

Re: [Acme] Internet-Draft acme-pqcnegotiation-03

I have two main pieces of feedback on this draft, which unfortunately are rather large / sweeping and would require rethinking the whole document to address. 1) The algorithm negotiation mechanism is too specific. Why should ACME add new API endpoints dedicated solely to listing the public key alg

Re: [Acme] I-D Action: draft-ietf-acme-ari-03.txt

On Mon, Feb 26, 2024 at 4:36 AM Carl Wallace wrote: > Two comments on the third paragraph of section 4.1: > > - The addition of section identifiers for the references makes the > sentences harder to read. Maybe wrapping the section identifiers and > reference in parentheses. > Thanks, this feedb

Re: [Acme] I-D Action: draft-ietf-acme-ari-03.txt

Apologies for the late reply, I've been on vacation. On Tue, Feb 27, 2024 at 3:05 AM Rob Stradling wrote: > Carl wrote: > > If this mechanism only applies to certs that conform to a profile that > requires presence of key identifier in the AKID extension, state that up > front. > > I think this

Re: [Acme] ACME leadership changes

Congratulations, Deb, and welcome to the WG, Tomofumi! Aaron On Thu, Mar 7, 2024 at 1:50 PM Yoav Nir wrote: > Hi, Tomofumi. > > Welcome to the working group. > > Looking forward to working with you. > > Yoav > > > On 7 Mar 2024, at 23:48, Roman Danyliw wrote: > > > > Hi WG! > > > > As Deb (Coo

Re: [Acme] Happy Birthday ACME!

Happy birthday, RFC8555! I've thought frequently about the idea of an ACME-bis over the last few years. I have a note going since at least 2022 which I occasionally add new ideas to, and I've had a few offline conversations with others about their wishlists. At the end of the day, I think only two

[Acme] Re: I-D Action: draft-ietf-acme-ari-04.txt

Hi all, This update is entirely improvements to the phrasing of various prose, no changes to the wire protocol. It does address the one remaining open question we discussed at IETF 119, namely what to do if a client identifies an already-replaced (or already-in-the-process-of-being-replaced) certi

[Acme] Re: I-D Action: draft-ietf-acme-ari-04.txt

Hi everyone, I have not received any feedback on this -04 version of the draft, so just like to re-request your review prior to IETF 120, in just a week and a half, where I plan to present these very minor changes and ask for WG last call. Thanks, Aaron On Fri, May 31, 2024 at 6:40 PM Aaron

[Acme] Re: I-D Action: draft-ietf-acme-ari-04.txt

> Hi Aaron. What are you planning to do with the 4 open Issues and 1 open > PR at https://github.com/aarongable/draft-acme-ari ? > > ------ > *From:* Aaron Gable > *Sent:* 16 July 2024 20:04 > *To:* acme@ietf.org > *Subject:* [Acme] Re: I-D Action:

[Acme] Re: Presentations for the ACME session at IETF 120

Thanks! I'd also like to give a separate (very quick) preview of my proposal for ACME Profiles, which I hope to have written up as a draft document before IETF 121. I've uploaded slides for both. Aaron On Sun, Jul 21, 2024 at 9:26 AM Yoav Nir wrote: > Hi, all > > I see now that we have neglecte

[Acme] Re: [EXTERNAL] Re: [Rats] Explaining the "PKIX Evidence" draft,

I'll note that I'm generally strongly in favor of introducing new ACME identifier types. I'm not very familiar with the exact proposal being discussed here, but I think that more reliance on identifiers presented at newOrder time, and less reliance on attributes of the finalize-time CSR, is the way

[Acme] Re: I-D Action: draft-ietf-acme-ari-05.txt

Hi all, The consensus at IETF 120 was that this document was ready for WG Last Call, with just two outstanding open questions. Those two questions have now been addressed in this lates

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

Thank you Corey, all three of these make sense to me. I have filed a bug to track these (https://github.com/aarongable/draft-acme-ari/issues/76) and will address them in the GitHub working copy as soon as I'm back from OOO next week. Aaron On Fri, Oct 11, 2024, 07:43 Corey Bonnell wrote: > Hell

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

, Oct 11, 2024 at 12:55 PM Aaron Gable wrote: > Thank you Corey, all three of these make sense to me. I have filed a bug > to track these (https://github.com/aarongable/draft-acme-ari/issues/76) > and will address them in the GitHub working copy as soon as I'm back from > OOO next

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

Thank you! I've fixed the typo[1] in the GitHub working copy and will bundle this fix along with any other comments from the WGLC period. Thanks again, Aaron [1] https://github.com/aarongable/draft-acme-ari/pull/75 On Thu, Oct 10, 2024, 06:55 Prachi Jain wrote: > Hi all, > > It's great to see

[Acme] Re: More detailed checking interval in ARI

Thanks Yoav! I've already spoken with Jacob about this change offline, and plan to bring it up as part of my timeslot this week. You're absolutely right that it doesn't affect any of the bits on the wire; it's just instructions on client behavior. I'm in favor of incorporating this language (or a

[Acme] Re: More detailed checking interval in ARI

of the draft, even as it sits in my queue. > I'd prefer you do that before I start my review. > > Deb > > On Mon, Nov 4, 2024 at 11:18 PM Aaron Gable 40letsencrypt@dmarc.ietf.org> wrote: > >> Thanks Yoav! >> >> I've already spoken with Jacob abo

[Acme] Re: IETF 121 update on ACME Profiles

Hi Q, Thanks for reading through the draft! On Thu, Nov 7, 2024 at 7:32 AM Q Misell wrote: > One thing I would like to see addressed is CAs deprecating a profile. > Obviously, when a client requests a certificate with a deprecated profile > it will receive an invalidProfile error, however it wo

[Acme] IETF 121 update on ACME Renewal Info (ARI)

My apologies to the ACME WG for not making it to the IETF 121 session. Below is the material that I intended to present; my slides are also attached. Since IETF 120, two new versions of draft-ietf-acme-ari have been published. Draft -05 in

[Acme] IETF 121 update on ACME Profiles

Hi ACME WG, Here's the material I intended to present regarding my ACME Profiles draft at IETF 121. My slides are attached. I have published draft-aaron-acme-profiles-00 , the first draft of my proposal for incorporating "profile select

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

On Wed, Nov 27, 2024, 08:22 吴攀雨 wrote: > The main focus is on proxy scenarios where the adversary is on the ACME > client and has access to the CSR file of another person's public key, but > does not possess the private key corresponding to the public key of the > certificate. Due to these risks,

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

Hi Michael, On Wed, Nov 27, 2024, 15:59 Michael Richardson wrote: > I'm unclear from reading 8555 if this key is retained across orders > (like a renewal 60 days later), or if a new key is generated each time. > Is the newAccount key always the same key as the CSR key? > The account key is almo

[Acme] Re: RFC 8555 challenge response proposal

The text of the RFC itself is not updated; you can consider verified erratum to be authoritative. Verified erratum will be incorporated into ACME-bis (a.k.a. ACME v2) if such a document is deemed necessary in the future. Aaron On Mon, Nov 18, 2024 at 8:03 AM Jeremy Hahn wrote: > Hello, > > Apol

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

On Tue, Nov 26, 2024, 07:09 Richard Barnes wrote: > > Goal (2) is might not an unreasonable idea, but I would be concerned about > (a) compatibility impacts with subjects, (b) compatibility impacts with CA > back-end APIs, and (c) new cross-protocol risks usage of the certificate > subject key pa

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

Hi all, I agree that it would be beneficial for the ACME protocol to have a pubKey identifier type, and to have challenges which can be used to prove control over the corresponding private key. However, it seems that I believe this would be useful for entirely different reasons than the authors he

[Acme] Re: Secdir last call review of draft-ietf-acme-ari-06

Hi Shawn, Thank you for these comments! I'm out for the rest of this week for American Thanksgiving, but will address them first thing next week. Thanks again, Aaron On Tue, Nov 26, 2024, 00:45 Shawn Emery via Datatracker wrote: > Reviewer: Shawn Emery > Review result: Has Issues > > I have re

[Acme] Re: Dnsdir last call review of draft-ietf-acme-ari-06

Hi Geoff, Thank you for the comments! Specific notes in-line below. On Sat, Nov 23, 2024 at 6:16 PM Geoff Huston via Datatracker < nore...@ietf.org> wrote: > Reviewer: Geoff Huston > Review result: Ready with Nits > > Overall the specification is quite reasonable. I have some nots that I feel >

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

Hi Deb, You're absolutely right that I should be referencing the 9110 instead of the obsoleted 7231. Thanks for catching that! I've fixed it in the latest commit in the github repo and will publish it along with updates for other comments. Aaron On Fri, Nov 22, 2024 at 10:33 AM Deb Cooley wrote

[Acme] Re: I-D Action: draft-ietf-acme-ari-07.txt

/aarongable/draft-acme-ari/pull/87. > ------ > *From:* Aaron Gable > *Sent:* 07 December 2024 01:05 > *To:* acme@ietf.org > *Subject:* [Acme] Re: I-D Action: draft-ietf-acme-ari-07.txt > > Hi all, This version incorporates: - The feedback from Jacob

[Acme] Re: Genart last call review of draft-ietf-acme-ari-07

Hi Susan, Thank you for the feedback. I've addressed these changes in the github working copy in https://github.com/aarongable/draft-acme-ari/pull/89, which will be included in the next version of the document. Individual comments inline below. Thanks again, Aaron On Sun, Dec 8, 2024 at 1:06 PM

[Acme] Re: Dnsdir last call review of draft-ietf-acme-ari-06

Hi Geoff, Thank you for the continued review! You've probably seen that I've published draft -07 incorporating most of your suggestions. Responses to your additional comments below. On Mon, Nov 25, 2024 at 4:12 PM Geoff Huston wrote: > A simpler sentence would be > > 'Allowing issuing CAs to su

[Acme] Re: Secdir telechat review of draft-ietf-acme-ari-07

Thank you, I have addressed these nits in https://github.com/aarongable/draft-acme-ari/pull/91, which will be included in draft -08. Aaron On Sat, Dec 14, 2024 at 8:40 AM Shawn Emery via Datatracker < nore...@ietf.org> wrote: > Reviewer: Shawn Emery > Review result: Has Nits > > This is a re-rev

[Acme] Re: I-D Action: draft-ietf-acme-ari-07.txt

Hi all, This version incorporates: - The feedback from Jacob Hoffman-Andrews regarding the Retry-After header - All feedback from Geoff Huston (DNSDIR) - All feedback from Michael Tüxen (TSVART) - Almost all feedback from Shawn Emery (SECDIR) It does not yet incorporate: - Feedback from Susan Har

[Acme] Re: Secdir last call review of draft-ietf-acme-ari-06

Hi Shawn, The comments below are addressed in https://github.com/aarongable/draft-acme-ari/pull/85 in the github working copy, and will be incorporated into the next published version shortly. Thank you for the review! Aaron On Tue, Nov 26, 2024 at 12:45 AM Shawn Emery via Datatracker < nore...@

[Acme] Re: Tsvart last call review of draft-ietf-acme-ari-06

Hi Michael, The comments have been addressed in https://github.com/aarongable/draft-acme-ari/pull/86 in the github working copy, and will be published in the next draft version shortly. Thank you for the feedback! Aaron On Fri, Dec 6, 2024 at 3:00 AM Michael Tüxen via Datatracker < nore...@ietf.

[Acme] Re: Proposal for Extension: Delegated HTTP-01 Validation in ACME Protocol

I'm confused by the claim that MPIC will make DNS validation slower: dns-01 validation reaches out directly to the authoritative nameservers. Once the authoritative nameserver has updated its TXT records, all perspectives should be able to see it at the same time. And even prior to MPIC, no ACME cl

[Acme] Re: Proposal for Extension: Delegated HTTP-01 Validation in ACME Protocol

ted zone specifically >>>>> for validation purposes or by using a special DNS server designed to serve >>>>> challenges. In either case, we’re working around most DNS servers’ focus >>>>> on >>>>> resiliency/replication rather than change propaga

[Acme] Re: Proposal for Extension: Delegated HTTP-01 Validation in ACME Protocol

Can't this be achieved today by having the webserver reached by the first validation request configured to serve an HTTP 301 redirect for all requests to paths under /.well-known/acme-challenge/? For example, a request for `example.com/.well-known/acme-challenge/LoqXcYV8...jxAjEuX0` could be automa

[Acme] Re: Agenda and scribes for Thursday

My slides will be uploaded shortly, and I'm happy to be a scribe for everything except my own slot. Aaron On Wed, Mar 19, 2025 at 2:01 AM Yoav Nir wrote: > Added. > > And I also got slides from Frank. > > Still waiting for slides from Aaron > > And we still need scribes. We can’t hold the meeti

[Acme] Fwd: New Version Notification for draft-aaron-acme-profiles-01.txt

aaron-acme-profiles-01.txt To: Aaron Gable A new version of Internet-Draft draft-aaron-acme-profiles-01.txt has been successfully submitted by Aaron Gable and posted to the IETF repository. Name: draft-aaron-acme-profiles Revision: 01 Title:Automated Certificate Management Environment

[Acme] Re: [EXT] Re: Two-week confirmation of the DTN Node ID draft

Hi all, Apologies, I was out for the past two weeks. I agree that this draft still represents the group consensus, and think it should proceed. Aaron On Wed, Apr 16, 2025 at 10:11 AM Sipos, Brian J. wrote: > Chairs, as document author I also support its continued progress. I > believe it still

[Acme] Re: Paul Wouters' Discuss on draft-ietf-acme-ari-07: (with DISCUSS and COMMENT)

On Thu, Feb 27, 2025 at 9:44 AM Paul Wouters wrote: > > paul@thinkpad:/tmp$ echo aYhba4dGQEHhs3uEe6CuLN4ByNQ= | base64 -d | > hexdump > 000 8869 6b5b 4687 4140 b3e1 847b a07b 2cae > 010 01de d4c8 > 014 > > Note my output has 88:69:6B:5B[] and you have [69:88:5B:6B][...] > > I assu

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

Hi all, At the request of this draft's authors, I'm using this thread to provide additional feedback on the updated version of the document ( draft-geng-acme-public-key-01 ) which will be presented at IETF 122. While I appreciate th

[Acme] Re: I-D Action: draft-ietf-acme-ari-08.txt

Hi all, This version addresses all known outstanding comments, including Shawn Emery's last remaining nits from the SECDIR Telechat [1], as well as Paul Wouters' [2], Murray Kucherawy's [3], and Éric Vyncke's [4] comments from the IEST Telechat. Thanks, Aar

[Acme] Re: Éric Vyncke's Discuss on draft-ietf-acme-ari-07: (with DISCUSS and COMMENT)

Hi Éric, Thank you for the comments and discussion! I have updated the working copy with a number of these changes, and will publish a new version of the draft soon. My comments and responses are inline below. On Thu, Jan 2, 2025 at 5:49 AM É

[Acme] Re: Paul Wouters' Discuss on draft-ietf-acme-ari-07: (with DISCUSS and COMMENT)

Hi Paul, Apologies for the delay, I had a very busy beginning of the year. I'm now getting to these in preparation for IETF 122. I have incorporated these comments into the working copy (from which I will publish a new version soon), and have

  1   2   >