[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

[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

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

gt; 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: 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 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)

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

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

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] 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

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

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] 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,

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

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] [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: >

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

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

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

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.

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

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

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

[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] 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

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

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 > negotiation in ACME &

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

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 fun, I like that idea. > > Making i

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

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] 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

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

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.

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

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

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

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

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

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

[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

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

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

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

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

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

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!

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

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

, 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 been successfully

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. >

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

. 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 as &g

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

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

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

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] 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

[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

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

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"

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] 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

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: [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

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)

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

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: Where this field is defined In

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

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

[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