Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL

My recollection from various CA/Browser discussions is that CAs are *not* actually required to keep around CSRs. Am I wrong? Most CAs do, because it is the easiest way to log proof of possession of the private key, and because it is useful for a variety of other auditing activities, but other met

Re: [Acme] Hyphens in parameter names of ACME CAA extensions

I agree with Corey about the readability of hyphens. Also, I fully support his fix to the RFC 6844 grammar. The current grammar is a mess. The implementation of CAA by major CAs has revealed a large number of serious defects with the current text of RFC 6844, and I think it's time for a RFC 68

Re: [Acme] Hyphens in parameter names of ACME CAA extensions

Okay, then it needs to accelerate 😊 I'm on that WG and I haven't seen any related traffic recently. Maybe I'll poke Phil. -Tim > -Original Message- > From: Salz, Rich [mailto:rs...@akamai.com] > Sent: Friday, January 19, 2018 8:18 AM > To: Tim Hollebee

Re: [Acme] Fixing the TLS-SNI challenge type

> Basically, for security, one needs to put the domain to be validated to the SNI > field. Not doing that was the reason for the TLS-SNI-01/02 vulernability. I agree. Not only for security, but for compliance, both with the Baseline Requirements [1] and the intended use of SNI. Abusing SNI as a

Re: [Acme] Fixing the TLS-SNI challenge type

> > I'm less worried about this constraint. If there's consensus for a > > change, changes can be made to the BRs much more quickly than an RFC can > be issued. > > Oh yeah, the minimum process latency for changing BRs is ~7 weeks. > > However, that would take well-fleshed proposal to do it eve

Re: [Acme] Fixing the TLS-SNI challenge type

2018 11:34 AM > To: Ilari Liusvaara ; Tim Hollebeek > > Cc: IETF ACME > Subject: Re: [Acme] Fixing the TLS-SNI challenge type > > ➢ challenge: Random string of at least 128 bits of entropy. > > > What does that mean? How can you measure if you’ve got 125 or 67 or 2

Re: [Acme] Assisted-DNS challenge type

> This challenge has the big advantage that subscribers only need to do a one- > time CNAME setup, and renewals can be reliably automated without requiring > that renewing systems have permission to update DNS. In effect, the CNAME > record would act like a long-term delegation permitting the CA to

Re: [Acme] Assisted-DNS challenge type [invalid signature!]

> I think that it could be acceptable to "reuse" an old validation provided > WHOIS > is checked right? > Eg, if a hash is made of all the WHOIS data, and all the WHOIS data stays > identical from last validation, then theres proof that control of domain has > not > shifted in the meantime, which

Re: [Acme] Assisted-DNS challenge type [invalid signature!] [invalid signature!]

sebast...@sebbe.eu] > Sent: Tuesday, January 23, 2018 10:00 AM > To: Tim Hollebeek ; 'Jacob Hoffman-Andrews' > ; acme@ietf.org > Subject: SV: Re: [Acme] Assisted-DNS challenge type [invalid signature!] > [invalid signature!] > > I have seen the BR, and what I understand

Re: [Acme] Assisted-DNS challenge type [invalid signature!] [invalid signature!]

> Oh, and the method very similar to the propose one (involving static CNAME > as > persistent authentication) is being used in the wild. And due to > fundamential > nature of DNS, even static zone can result variable results for names under > the > zone. By who? I don't think it's possible f

Re: [Acme] Assisted-DNS challenge type [invalid signature!] [invalid signature!]

mpure function is not going to successfully guess a secure random number. -Tim > -Original Message- > From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] > Sent: Tuesday, January 23, 2018 1:48 PM > To: Tim Hollebeek > Cc: acme@ietf.org; 'Jacob Hoffman-Andre

Re: [Acme] Assisted DNS, freshness tokens, and BR validation methods

nal Message- > From: Matthew D. Hardeman [mailto:mharde...@ipifony.com] > Sent: Wednesday, January 24, 2018 12:21 AM > To: Jacob Hoffman-Andrews > Cc: acme@ietf.org; Tim Hollebeek > Subject: Re: [Acme] Assisted DNS, freshness tokens, and BR validation methods > > Note as

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt

I'm generally supportive of this, but one concern I do have, and I admit I'm mostly just thinking aloud here, is that we are slowly accumulating a larger and larger number of things that look like certificates, but aren't due to people playing games with critical extensions. I think we may come to

Re: [Acme] ALPN based TLS challenge

The concerns in this email, many of which I share, are the reason why I’d really like to get around to doing a full security analysis of all of the BR validation methods at some point. They’ve mostly been considered in isolation, when in reality there are many overlapping themes. Maybe we’l

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt

-Tim > -Original Message- > From: Jacob Hoffman-Andrews [mailto:j...@eff.org] > Sent: Monday, March 5, 2018 5:42 PM > To: Tim Hollebeek ; acme@ietf.org > Subject: Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt > > On 03/05/2018 04:37 PM, Tim Hollebeek wrote: &g

[Acme] Comments on ACME draft

I think the draft is in very good shape. Unfortunately I didn't have as much time to go through it as I would have liked, but I did find two things that are probably worth fixing: 1. "ACME clients SHOULD send a User-Agent header" I think there's no value in omitting it, so it should be changed

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

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 bureaucratic details of how a fix gets made, it would be nice to get th

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

> 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. This was certainly the intent. Never in over two years of some

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

the intent of the validation method, and doesn’t introduce security risks. -Tim On Thu, Jun 21, 2018 at 8:40 AM, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote: > TLS-ALPN addresses the latter problem by requiring the server_name to match > the validation targ

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

I agree with Ryan that that’s probably the best way forward, if changing the names to remove the hyphens doesn’t cause undue hardship. -Tim From: Salz, Rich [mailto:rs...@akamai.com] Sent: Thursday, June 21, 2018 9:07 AM To: Tim Hollebeek ; Ivan Ristic ; Ryan Sleevi Cc: IETF ACME

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

I prefer the RFC 6844-bis interpretation, but I note that this is not compliant with the Baseline Requirements, which mandate RFC 6844. It's not clear what that means though since as you correctly note, RFC 6844 contradicts itself on this point. I would support fixing the baseline requirements a

Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for ACME-CAA discussion at 102)

Yes, the RFC 6844 grammar is a mess, and it has significantly impeded efforts to improve CAA. It's one of the things I think is most important to fix in 6844bis. It is particularly troubling because CABF rules point to 6844, and some people have been sticklers about requiring very strict complian

Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for ACME-CAA discussion at 102)

My personal opinion is that the WG should try to come up with something that makes sense and complies with the intent of 6844 and its examples, instead of trying to be overly strict about complying with the current grammar as written. We can then file an errata and work with LAMPS to fix up the gr

Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for ACME-CAA discussion at 102)

Yeah, I'm not particularly picky on the solution as long as we agree on a solution that works. I believe that parameter usage is pretty rare in the wild right now, so I think we have time to come to a consensus about what the right behavior is, and document it via fixing examples or errata or what

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

For what it’s worth, there’s a discussion going on in the validation working group right now about how redirects should be handled. The most likely outcome is either pretty severe restrictions around redirects, or completely disallowing them. In the interest of openness, CAs were asked to

[Acme] FW: Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

Trimming recipients due to moderation. -Tim From: Tim Hollebeek Sent: Thursday, August 30, 2018 8:12 AM To: 'Richard Barnes' ; Salz, Rich Cc: Alexey Melnikov ; draft-ietf-acme-a...@ietf.org; IETF ACME ; Daniel McCarney ; Yoav Nir ; The IESG ; ; Alexey Melnikov Subject:

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

The capability URL stuff introduces a level of complexity that I'd rather not try to analyze at this point. I'm afraid people will rush to implement it and get it wrong in hard to anticipate ways, or that there are consequences we haven't foreseen at this late hour. POSTs seem to be the right

Re: [Acme] POST-as-GET payload contents

I agree “” is better than “{}”. -Tim From: Acme On Behalf Of Richard Barnes Sent: Wednesday, September 5, 2018 4:11 PM To: Jacob Hoffman-Andrews Cc: Logan Widick ; IETF ACME Subject: Re: [Acme] POST-as-GET payload contents On Wed, Sep 5, 2018 at 3:43 PM Jacob Hoffman-Andrews mailt

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

I strongly agree with those who do not want to open this can of worms at this time, but my preference for examples in future documents would be something like "example.com" for a generic domain name being validated (because the .com tends to evoke a generic end-user DNS name, for better or worse

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

I suspect that the guessable account numbers is something the LE folks will eventually regret for one reason or another. It’s poor security design to make something public and/or guessable if it doesn’t need to be. -Tim From: Acme On Behalf Of Richard Barnes Sent: Tuesday, October 9,

Re: [Acme] ACME DV Security Considerations Draft

It is worth noting that the need for an invitation only apples to Face to Face meetings. There is no restriction on who can be an Interested Party and participate in working groups and subcommittees, as long as you are able to sign the Intellectual Property Rights agreement. I’d encourage anyo

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-caa-07: (with DISCUSS and COMMENT)

> CAs MUST select and process account URIs under the assumption that > untrusted third parties may learn of them. That's not really an actionable requirement, is it? -Tim smime.p7s Description: S/MIME cryptographic signature ___ Acme mailing

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

Thanks for this. I found this feedback interesting and useful, and these considerations are definitely something we need to keep in mind as we try to get ACME adopted more widely. These sorts of real-world considerations often get lost in the discussion of technical standards, which is unfortu

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

Anyone who argues that zero is a positive integer should be referred to the standard math textbook of positive. Zero is a non-negative integer, but I’m not aware of any definition of “positive” that makes it a positive integer. Also, ignoring failures in CAA records is probably not the right an

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

That’s a fair point and one we’re going to have to work through. I suspect failure handling will need some subtle analysis. It did for some of the other CAA record types. -Tim From: Paul van Brouwershaven Sent: Wednesday, July 12, 2023 12:59 PM To: Tim Hollebeek ; Q Misell Cc: acme

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

Brouwershaven Sent: Wednesday, July 12, 2023 1:01 PM To: Tim Hollebeek ; Q Misell Cc: acme@ietf.org Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt > Anyone who argues that zero is a positive integer should be referred to

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

he entry will be considered to have a lower priority than all entries which > specify any priority. So, setting "0" would invalidate the parameter, causing the ACME client to ignore the CAA record all together. Does this also make sense to you Q? _______

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

Some REALLY quick comments from a brief read: First, I think this is pretty clearly standards track, especially since I expect the authors are willing to work together with the IETF community and respond to feedback, and it includes normative requirements that are intended to be used with a major

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

can be used in conjunction with the issuance of wildcard certificates, and this draft probably needs to specify how things work for that, too. -Tim > -Original Message- > From: Acme On Behalf Of Tim Hollebeek > Sent: Wednesday, July 12, 2023 4:32 PM > To: Mike Ounsworth ; &g

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

tinue discussing it at ACME instead, because that’s the motivating use case, I’m fine with that too. -Tim From: Acme On Behalf Of Paul van Brouwershaven Sent: Thursday, July 13, 2023 5:07 AM To: Seo Suchan ; Tim Hollebeek ; Mike Ounsworth ; acme@ietf.org Subject: Re: [Acme] [EXTERNAL] New Ve

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

hat this could be made more explicit, I added an example to describe this scenario in more detail. Do you think that is sufficient or should we add in introduction to section 5 or update item 2 with a normative requirement that the ACME MUST follow RFC8659 when selecting the valid CAA records for the do

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

> > This is an interesting point. ARI was first conceived > > as a way to > > improve business continuity across mass revocation events, and grew from > > there. The idea that 10-day certs might be a reality, and that revocation > > would

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

I agree that generic support for profile selection and migration between protocols is superior. PQC isn’t actually particularly special or relevant to ACME, and we should avoid putting PQC-specific stuff into protocols that don’t need it, because we’ll be maintaining some of these protocols far

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

Returning it as part of the protocol makes more sense to me than trying to stuff it into DNS. One could imagine including it as part of some sort of extension in the CSR that optionally proves possession (if desired), for example. One of the challenges we often have with issuance protocols is

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

is might be one of those times. -Tim > -Original Message- > From: Russ Housley > Sent: Friday, August 11, 2023 1:20 PM > To: Tim Hollebeek > Cc: IETF ACME > Subject: Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME > > Tim: > > I understand

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

Right, that’s exactly what I was thinking. Thanks for fleshing it out. -Tim From: Aaron Gable Sent: Friday, August 11, 2023 1:47 PM To: Tim Hollebeek Cc: Russ Housley ; IETF ACME Subject: Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME Oh that's fun, I like that idea. M

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

> -Original Message- > From: Acme On Behalf Of Ilari Liusvaara > > And it seems like that can be extended that to cases where ACME does not > require POP by just having the ACME server immediately accept the pseudo- > authorization. I think if the server doesn't want PoP, they should jus

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

n the past (this is part of the reason why I don’t think CSR-based PoPs provide much value in most situations. The replay risk is just too high). -Tim From: Aaron Gable Sent: Tuesday, August 15, 2023 2:16 PM To: Seo Suchan Cc: Tim Hollebeek ; Russ Housley ; IETF ACME Subject: Re: [Acme] Inte

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

Yes, this is why CAs are allowed to require PoP before revoking a certificate for key compromise. To avoid this exact scenario. -Tim From: Mike Ounsworth Sent: Wednesday, August 16, 2023 12:31 PM To: Seo Suchan ; Tim Hollebeek ; Aaron Gable Cc: Russ Housley ; IETF ACME Subject: RE

Re: [Acme] ACME PoP on revocation requests

find yourself in that situation, please archive the compromised keys. You might need them. -Tim From: Mike Ounsworth Sent: Wednesday, August 16, 2023 1:01 PM To: Aaron Gable Cc: Seo Suchan ; Tim Hollebeek ; Russ Housley ; IETF ACME Subject: RE: ACME PoP on revocation requests (changing the

Re: [Acme] Decentralized the ACME

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. Otherwise this discussion will just go in circles. -Tim From: Acme On Behalf Of Wang Haiguang Sent: Friday, November 10, 2023 2:42 PM

Re: [Acme] Starting a design team for draft-vanbrouwershaven-acme-auto-discovery

As I commented in the mic line, add me! And Corey too. -Tim From: Acme On Behalf Of Mike Ounsworth Sent: Monday, November 27, 2023 4:50 PM To: acme@ietf.org; Paul van Brouwershaven Subject: [Acme] Starting a design team for draft-vanbrouwershaven-acme-auto-discovery Hey ACME! We

[Acme] Re: ACME for Onions

Here’s the review I promised during the session. Apologies for the brevity, but I did want to get some comments out for Q. In general, I like it. Lots of new and cool stuff in there. I wish I had more time to learn about it and think about it. I’m unclear on the motivation for wildcard on