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

Ilari, you've posted some useful extrapolations on how domain scopes could work. I'm proposing to get rid of domain scopes. :D To get us on the same page, would you mind posting some of the specific use cases you're envisioning where domain scopes would be used in an ACME environment? My existing

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

On Wed, Mar 20, 2024 at 5:57 PM Amir Omidi wrote: > I feel like splitting this challenge into three (and potentially more, as > extra scopes may or may not be added into the future) might be a little too > noisy. > Combined with my other proposals, we only wind up with two total challenge

[Acme] expiry in dns-account-01

The latest dns-account-01 draft ( https://datatracker.ietf.org/doc/html/draft-ietf-acme-scoped-dns-challenges-00) incorporates recommendations from the dnsop domain control verification draft ( https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-03 ). The dnsop

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

Seo Suchan said: > Would it be illegal to server probe both scope and pass if there is intended token? This is a possibility, but it's inefficient and I think it's likely to lead to implementation bugs. Better to be clear and explicit on both sides. Amir Omidi said: > My intention that I should

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

Thanks, authors, for the updates in https://datatracker.ietf.org/doc/html/draft-ietf-acme-scoped-dns-challenges-00 . Adding a "scope" (host, wildcard, or subdomain) to the DNS record name is great. Reading the draft, I think it doesn't specify how the scope for a given challenge is decided and

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

Deb, I agree with your analysis: I find the existing text sufficient. Conversely, I worry that specifying entropy in terms of "generating X characters from the base64url alphabet" is likely to go wrong, with people handcrafting random selection algorithms. The spec does try to allow for

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

Yep, still accurate. Thanks! ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

Agreed. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

> That’s fair. The text should probably state something along the lines of > > “If the server has an existing authorization for the identifier, depending on > server policy, the server may return a 200 (OK) response with the existing > authorization URL in the Location header field and the

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

Yeah, editorial seems right to me. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

I think this is "hold for update." It would specify a change to how servers operate in practice today. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

This is about indenting and I suspect email display clients are eating the leading spaces. Here's what it looks like with underscores: Old: ​___submit another order containing only the eight identifiers not listed ​___in the problem document. HTTP/1.1 403 Forbidden Content-Type:

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

This overspecifies things. When someone requests to create a new authorization object (or requests to create a new order object that would necessitate creation of new authorization objects), it is up to server policy whether to reuse an existing authorization or not. For instance a server might

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

nt: Wednesday, February 9, 2022 7:25 AM To: Benjamin Kaduk Cc: Richard Barnes ; Jacob Hoffman-Andrews ; Daniel McCarney ; Roman Danyliw ; deco...@nsa.gov ; debcool...@gmail.com ; Yoav Nir ; IETF ACME ; RFC Errata System Subject: Re: [Technical Errata Reported] RFC8555 (6843) Hi

Re: [Acme] Long-lived certificates, but frequently renewed certificates

Roland Shoemaker sent a proposal a while back for ACME Renewal Info (ARI) with the goal of solving both "impending revocation" and "expressing suggested renewal times." https://mailarchive.ietf.org/arch/msg/acme/b-RddSX8TdGYvO3f9c7Lzg6I2I4/. We at Let's Encrypt hope to develop this idea further

Re: [Acme] Conflicting requirements for retrieving an ACME account that is already bound to an external account

I think this is the key bit: > - Since the server has not verified the binding, its response 'MUST NOT reflect the "externalAccountBinding" field in the resulting account object'. I understand "reflect" to mean "echo what the client sent." So I think it's acceptable for the server to ignore

Re: [Acme] dns-01 challenge limitations

Here are a couple of other useful resources on addressing this problem on the client side. Essentially, you can run your own nameserver dedicated to answering challenges, and delegate to it with CNAMEs. https://github.com/joohoi/acme-dns

Re: [Acme] ACME subdomains

I haven't followed the "ACME for subdomains" conversation closely, but the base semantics of ACME are designed such that they can express "all of" semantics AND "one of" semantics. For a given Order, a client has to fulfil *all* the Authorizations; for a given Authorization, a client has to fulfil

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

On 8/23/19 2:02 PM, erica wrote: Hi, Erica from Certbot here. I'd love to see this get verified -- it seems impossible to implement the "retrying challenges" section as the spec currently stands. As an author, I think this erratum should be approved.

Re: [Acme] Benjamin Kaduk's Yes on draft-ietf-acme-tls-alpn-06: (with COMMENT)

On 9/30/19 6:07 PM, Benjamin Kaduk via Datatracker wrote: the provider. When the TLS SNI challenge was designed it was assumed that a user would only be able to respond to TLS traffic via SNI for domain names they controlled (i.e. if User A registered Host A and User B

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

It's important to note that automated validation of IP addresses for certificates is already a part of the Web PKI, but is not standardized. This protocol will standardize it, which I believe will make  overall validation of IP addresses more secure, within the threat model that Roland

Re: [Acme] .well-known for dns challenges

This seems like a clever idea! As Ted said, .well-known probably isn't the right directory for it. If you put something in .well-known, that suggests you plan to standardize it and register it with IANA. I'll also note that you may have a bootstrapping problem: Assuming that you verify

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

I'm in favor of this change in spirit, but it's pretty substantive and will actually do the wrong thing with some existing deployments. For instance, https://acme-v02.api.letsencrypt.org/directory currently has: Cache-Control: max-age=0, no-cache, no-store Which under this language would

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

I believe this should be verified. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

I believe this should be verified. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

I believe this should be verified. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

I believe this should be verified. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] RFC 8555 on Automatic Certificate Management Environment (ACME)

Yes, big thanks! This was a huge group effort over many years, and I'm very grateful to everyone who has contributed to it. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

Pushed some more changes. On 10/10/2018 02:06 PM, Jacob Hoffman-Andrews wrote: Updated to include Orders and Authorizations in the example as you requested. https://github.com/ietf-wg-acme/acme/pull/463/files On 10/09/2018 04:49 PM, Jacob Hoffman-Andrews wrote: I'll revise this to include

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

Updated to include Orders and Authorizations in the example as you requested. https://github.com/ietf-wg-acme/acme/pull/463/files On 10/09/2018 04:49 PM, Jacob Hoffman-Andrews wrote: I'll revise this to include examples from the other URLs. One of my goals is to switch away from

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

On 10/09/2018 03:28 PM, Diego R. Lopez wrote: If I understood this compromise proposal, that implies to put STAR out of play… Or am I missing something? Not at all, it just means that STAR needs to define a new field on the Order resource that specifies a polling URL for frequently-updating

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

On 10/09/2018 07:45 AM, Richard Barnes wrote: 1. Remove GET for certificates.  I think this is a mistake, but I can grant that it's clunky as-is, and it will be straightforward to re-add it later if it's needed. Great. 2. Keep the security considerations about capability URLs and the

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

> https://github.com/ietf-wg-acme/acme/pull/462 I'm

Re: [Acme] Allow get for certificates?

The POST-as-GET mess started because Adam Roach pointed out that the "orders" URL (listing all of an accounts orders), in some non-WebPKI contexts, could expose information that shouldn't be exposed. There are two possible fixes for this: The narrow fix -- Remove "orders." No one implements

Re: [Acme] Backing-out capability URLs from the spec (added in #445)

. At the point, we need to be locking things down and removing unused features, not introducing new fiddly bits for the sake of drafts that can easily be implemented as an extension to the main draft. On 10/05/2018 03:55 PM, Jacob Hoffman-Andrews wrote: >The removed language is a non-normat

Re: [Acme] Backing-out capability URLs from the spec (added in #445)

>The removed language is a non-normative statement of fact You can't introduce a new authentication method in post-Last Call revisions, and claim they are non-significant simply because they are not formally normative. > It seems like you're trying to get rid of a better option to maintain

[Acme] Backing-out capability URLs from the spec (added in #445)

In the rounds of reviews on https://github.com/ietf-wg-acme/acme/pull/445, I missed an addition: the suggestion to use capability URLs for access control on certificate URLs. We should definitely not introduce this into the spec: ACME has one authentication model, based on JWS signing. We

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

On 09/05/2018 12:39 PM, Richard Barnes wrote: Using the same notation, I'm: 1) "" 2) "urn:ietf:params:acme:get" 99) "{}" Given that, I'm willing to compromise on "". I think the experience we had of almost implementing bugs with that approach was informative, but isn't decisive.

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

On 09/05/2018 08:33 AM, Richard Barnes wrote: 1. A field in the protected header ("urn:ietf:params:acme:get": true) with a requirement that the payload be "{}" 2. A field in the payload ({"get": true}) a requirement that if that field be there, then there are no other fields present I dislike

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

On 08/31/2018 03:08 PM, Richard Barnes wrote: ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the privacy analysis? Agreed we're solved on this. ISSUE 2: How should we signal that POST-as-GET request is different from other POST requests? Started a separate thread on this.

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

On 08/31/2018 12:30 PM, Jacob Hoffman-Andrews wrote: /account/100/certificate/3438 /account/201/certificate/3439 /account/100/certificate/3440* Here's an issue that came up during code review: When you POST-as-GET to a resource you don't own, should you get Not Found or Unauthorized

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

On 08/31/2018 07:25 AM, Richard Barnes wrote: The problem with using POST-as-GET for certificate resources, as Felipe I think pointed out, is that the thing that downloads the certificate URL is often not an ACME player, doesn't have an account, etc.  It's a web server or something. (cf. the

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

(Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)") On 08/30/2018 11:17 AM, Felipe Gasper wrote: > Would it work to keep certificate fetches as plain GET? > > In shared hosting environments it’s common for a

[Acme] ACME breaking change: Most GETs become POSTs

ACME currently has unauthenticated GETs for some resources. This was originally discussed in January 2015[1]. We decided to put all sensitive data in the account resource and consider all GET resources public, with a slant towards transparency. Adam Roach recently pointed out in his Area

Re: [Acme] ACME Operational best practices

On 07/14/2018 04:38 PM, Tobias Fiebig wrote: Back when we submitted Cloud Strife [0] to NDSS, we reached out to the list on pushing our mitigations toward a recommendation/best practices RFC. Given that with the Birge-Lee paper, there is now a second attack vector, we (Kevin Borgolte and I,

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

There's a similar issue for parameters: RFC 6844 section 3 says each name-value pair is separated by a semicolon: https://tools.ietf.org/html/rfc6844#section-3 >    issue [; = ]* :  The issue property RFC 6844 section 5.2 says each name-value pair is separated by a space:

Re: [Acme] Draft authors -- please send a status

acme-acme: Pretty much done. On 06/27/2018 12:16 PM, Daniel McCarney wrote: I can volunteer for being the ACME-CAA document shepherd but would appreciate some off-list guidance on the requirements. On Wed, Jun 27, 2018 at 2:31 PM, Salz, Rich >

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

Thanks for the update, Hugo! Let's Encrypt's Boulder has merged a change updating to match this behavior, which should go out to our staging environment on Tuesday. https://github.com/letsencrypt/boulder/pull/3772 ___ Acme mailing list Acme@ietf.org

Re: [Acme] Let's Encrypt ACME-CAA validation-methods support

Apologies for the delay on publishing the latest draft. I'll work on getting that out today. Thanks for the reminder! On 05/30/2018 12:17 PM, Corey Bonnell wrote: Hello, This development is exciting work in regard to allowing domain owners to limit which validation methods they want to

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

On 05/21/2018 11:55 AM, Roland Shoemaker wrote: Ah, yup, good catch. I totally spaced we’d pulled that out. Likely we’ll want to reference TLS-ALPN here but it kind of ends up being a chicken and egg scenario. If draft-ietf-acme-tls-alpn gets standardized first we’ll want to mention that in

Re: [Acme] Question about listing authorization objects

On 04/11/2018 03:07 PM, Zhang, Ning wrote: > > Excuse me if it has been discussed before. > >   > > It looks like that there is no URL defined to fetch the list of > existing authorization objects associated with an account, especially > for ACME servers supporting pre-authorization > >   > > Does

Re: [Acme] Comments on ACME draft

I agree, these seem worth merging. On 04/11/2018 01:56 PM, Richard Barnes wrote: > Here's a quick PR implementing Tim's proposed changes. > > https://github.com/ietf-wg-acme/acme/pull/420 > > Personally, these seem fine to me.  I would be in favor of merging the PR. > > > On Wed, Apr 11, 2018 at

Re: [Acme] Challenge retry ambiguities

On 03/15/2018 10:03 AM, Hugo Landau wrote: > It suggests that a challenge should be retried automatically by the server, > and > that the challenge should remain in the "processing" state for this time. It > also states that the "invalid" state should be used after the server has given > up. It

Re: [Acme] Certificate chains including roots

On 03/12/2018 05:25 AM, Hugo Landau wrote: > 3. Clarify the specification to state that the root certificate must > not appear in the chain, and that roots must be retrieved using the > AIA URL inside the final certificate in the chain if it is needed. > This minimises the chance

Re: [Acme] Specify which JWS serialization is used

> If you have suggestions here, a PR would be welcome.  TBH, this issue > kind of makes me want to reverse course and say "all flattened JSON", > but I get the sense that other folks disagree? I'd be very much in favor of "all flattened JSON." When we started ACME, I think there was some concern

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

[Starting a new thread for this particular fork of the conversation] Thanks for the input, Tim! As a member of the CA/Browser Forum Validation Working Group, and a big contributor to the BR validation methods, your perspective on this is particularly helpful. On 01/23/2018 08:37 AM, Tim

[Acme] Assisted-DNS challenge type

Inspired by a thread on Let's Encrypt's community forum (https://community.letsencrypt.org/t/suggestion-lets-encrypt-operated-txt-only-dns-hosting-for-dns-challenges/50399/1), I'd like to propose a new challenge type, "assisted-dns-01". The existing DNS challenge is good for a number of reasons,

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

I don't think that's been discussed before. I think it's reasonable to adjust "account-uri" to "accounturi" and "validation-methods" to "validationmethods" to stick with RFC6844's definitions. On 01/18/2018 06:56 AM, Ivan Vyshnevskyi wrote: > Hi, > > According to the grammar for value of the CAA

Re: [Acme] Undoing challenge fulfilling actions

> On Sun, Jan 07, 2018 at 18:40:51 +0100, Sophie Herold wrote: >> I wonder if this paragraph has some special background: >> >> If the client’s response is invalid for any reason or does not >> provide the server with appropriate information to validate the >> challenge, then the server MUST

Re: [Acme] Challenge objects are provoking implementation mistakes

On 12/19/2017 03:10 AM, Sophie Herold wrote: > If the client follows the schema > > 1. fulfill challenge > 2. POST challenge URL > > it is unlikely that the keyAuthorization returned by the server would be > used to fulfill the challenge (again). > > However, it should be possible to obtain a

Re: [Acme] Discussion of draft-ietf-acme-ip

On 12/20/2017 01:50 PM, Richard Barnes wrote: > Do you mean draft-ietf-acme-ip?  It's already adopted; that's what the > "draft-ietf" signifies. Whoops, I missed that. Thanks! ___ Acme mailing list Acme@ietf.org

Re: [Acme] Discussion of draft-ietf-acme-ip

On 11/16/2017 02:28 PM, Roland Bracewell Shoemaker wrote: > The point of the draft is to provide a method for validating the control > of IP addresses in the same way that the ACME draft does for DNS names. > This allows ACME implementing CAs to be on an equal footing with > existing

Re: [Acme] [ACME][QUESTION] JWS Signature Verification Using JWK

I think the answers to both of your questions will be found in the JWK and JWS RFCs: https://tools.ietf.org/html/rfc7517 https://tools.ietf.org/html/rfc7515 If you're looking for additional examples, you can look at the Boulder source code: https://github.com/letsencrypt/boulder/, or a variety

Re: [Acme] new-authz, new-order and examples

On 12/05/2017 03:07 PM, Sophie Herold wrote: > Having mentioned new-authz: The definition of new-authz is now a subset > of new-order. Is there any reason to keep the new-authz resource at all? > Would there be any difference in using new new-order with the exact same > query without finalizing

Re: [Acme] Camel vs. kebab-case

Thanks for pointing this out! On 12/01/2017 04:06 AM, Sophie Herold wrote: > camelCase > > - newKey > - keyAuthorization > - notBefore > - notAfter > > kebab-case > > - (all directory fields) > - terms-of-service-agreed > - only-return-existing > - external-account-binding You forgot to

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

On 11/30/2017 02:34 PM, Richard Barnes wrote: > As Jacob points out, CAs are already required to keep around CSRs in > audit logs. You missed an important nuance: CAs are not required to keep around CSRs in an online database for live querying on the web. It is much more expensive to store a CSR

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

On 11/30/2017 12:58 PM, Logan Widick wrote: > In the new finalizeURL approach to orders, do order objects need to > contain a CSR after a user attempted to finalize the order, or after > the order is finalized? Would the CA have to store the CSR after it's > posted, or after the certificate is

Re: [Acme] Removing OOB Challenge Type

I agree with this change. It's a good plan to not try and pre-specify things like OOB that aren't on anyone's roadmap, because that leaves the space open for a better specification once someone wants to implement it. On 11/30/2017 09:39 AM, Clint Wilson wrote: > > I agree with the reasoning and

[Acme] Landing PR#342 (proactive issuance with identifier-first)

Hi all, Daniel McCarney's been working on PR#342, which changes the new-order flow to take a list of identifiers instead of a CSR, and to be finalized with a CSR: https://github.com/ietf-wg-acme/acme/pull/342. We've had some back-and-forth on the list about this, versus CSR-first, versus

Re: [Acme] Returning multiple errors

On 11/21/2017 04:06 PM, Martin Thomson wrote: > I ask because your example highlighted two types of problems. That > they could be aggregated doesn't seem an necessary or innate property. > > The difficulty with the sort of aggregation design you propose is that > you need to aggregate and I

Re: [Acme] Returning multiple errors

On 11/21/2017 11:48 AM, Niklas Keller wrote: > How about "causes"? I think this also implies more meaning than there really is. It also has the unfortunate property of being both a plural noun and a transitive verb, which could be confusing. Is there a problem with sub-problems?

Re: [Acme] Returning multiple errors

nly show the first error. Instead, there's a top-level generic error ("some identifiers were rejected"), and then there are potentially multiple errors that are part of it (_example.com, example.net). > On Tue, Nov 21, 2017 at 10:19 AM, Jacob Hoffman-Andrews <j...@eff.org> w

Re: [Acme] Returning multiple errors

On 11/16/2017 12:45 AM, Martin Thomson wrote: > I don't know what a random JSON parser would do with your stacked error codes. I don't understand. What I'm proposing is an array of JSON objects under the sub-problems field, which should be supported by any JSON parser.

Re: [Acme] Returning multiple errors

On 11/15/2017 07:07 PM, Richard Barnes wrote: > Following Daniel's lead on looking for implementation: Is this > something LE would be implementing? Yep, we would definitely implement this. I'll send a PR. ___ Acme mailing list Acme@ietf.org

[Acme] Returning multiple errors

In previous versions of ACME, there was sometimes a need to return multiple errors, broken out by domain name. For instance, when issuing a certificate by making a new-cert request, the CA has to check CAA, which may fail for multiple domains. Ideally, the client should not have to guess which

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On 11/09/2017 02:18 PM, Richard Barnes wrote: > Since people don't seem happy about either of these alternatives > (identifiers+CSR because of legacy issues; CSR+CSR because of > fragility), here's one last attempt at a different approach: > Draft PR: https://github.com/ietf-wg-acme/acme/pull/350

Re: [Acme] Agenda topic - nonces

I'd like to talk about making nonces optional for the server. Specifically, we introduced nonces because the main implementer (Let's Encrypt) was using a third party to terminate TLS. However, we've found that in practice nonces make load balancing between clusters more difficult, and we're

Re: [Acme] Allowable mailto contacts

On 10/19/2017 10:59 AM, Logan Widick wrote: > What portions of the "mailto" URI scheme (RFC 6068) must an ACME server > be able to accept as contacts? Good question. I think we'd like to specify the narrowest subset possible, i.e. "mailto:us...@example.com;. What would that look like in the

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On 09/19/2017 01:34 PM, Logan Widick wrote: > Would it be possible to extract the key and identifiers from the CSR, > add the key to the database if it doesn't already exist, find or > create the authorizations for the identifiers, not store the CSR, and > then assemble the certificate from the

Re: [Acme] Rolling keys and pending validations

Any further thoughts on whether keyAuthorizations should be bound at challenge creation time vs challenge submission time? On 07/07/2017 03:09 PM, Jacob Hoffman-Andrews wrote: > On 07/07/2017 12:35 PM, Richard Barnes wrote: >> Whether clients will notice depends on how we change t

Re: [Acme] Stale DNS and high-risk issuance

On 07/20/2017 12:18 AM, Kevin Borgolte wrote: > we are currently conducting a measurement study about DNS staleness > issues with a focus on IP address churning. Excellent, I look forward to reading it! > We encountered the issue that Let's Encrypt (and ACME in general) can > be (ab)used to

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

On 07/19/2017 07:39 AM, Martin Thomson wrote: > In this case, I disagree. With names, there is an expectation that > certificates can be issued for them. This is not the default case for > IP addresses Why do you say that issuance is disallowed by default for most IP addresses? The CA/Browser

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

On 07/17/2017 10:48 PM, Martin Thomson wrote: > The biggest concern I have is the text regarding certificate lifetime > and the handling of the possibility that IP addresses are dynamically > allocated. This seems a little weak and it leaves a lot to the CA to > manage. Is there anything that

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

On 07/18/2017 10:13 AM, Rifaat Shekh-Yusef wrote: > Hi Richard, > > Take a look at the following exchange with Jacob: > https://www.ietf.org/mail-archive/web/acme/current/msg02085.html > > > > I think the draft should be clear on

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

This looks good! Nice work. On 07/16/2017 04:29 PM, Roland Bracewell Shoemaker wrote: > There was some previous discussion about possibly using a slightly > simpler DNS based verification method on the list last time I posted > this as an individual submission. After reading through the CABF BRs

Re: [Acme] Rolling keys and pending validations

On 07/07/2017 12:35 PM, Richard Barnes wrote: > Whether clients will notice depends on how we change the syntax to > express the "binding". You seem to be assuming that we'll keep the > syntax the same. That would mean that the server would note the > keyAuthorization to be used with the

Re: [Acme] Rolling keys and pending validations

On 06/30/2017 09:54 AM, Dunning, John wrote: > Based on your description below, I think door A makes more sense to > me. My paraphrase of it is that key authorizations get bound at > creation time, and thus get “grandfathered” in after a credential > rotation. This is a good paraphrase. What do

Re: [Acme] ACME v06 - Pre-Authorization

On 06/27/2017 05:15 AM, Rifaat Shekh-Yusef wrote: > > > The server would create an order object with one or more > authorizations objects that need to be fulfilled. > > > My point is that the pre-authorization request (i.e. new-authz) would > have already created > a pending

Re: [Acme] ACME -06: HTTPS authorization

On 05/30/2017 08:32 AM, Yaron Sheffer wrote: > - The server only supports HTTPS, and perhaps port 80 is blocked by a > firewall. This situation applies to many REST endpoints. This is in general a bad configuration. Leaving port 80 open for the purposes of redirects is safe, and provides a better

Re: [Acme] ACME v06 - Pre-Authorization

On 06/07/2017 05:50 AM, Rifaat Shekh-Yusef wrote: > What is the expected behavior of the server if the client sends the > certificate issuance request after it sends the pre-authorization > request but > before it completes the pre-authorization process? By "certificate issuance request," I

Re: [Acme] fields to include in challenge response

On 06/26/2017 07:15 AM, Ilari Liusvaara wrote: > I was trying to write some code, and noticed a potential inconsistency: > > Section 7.5.1 has in example (responding to HTTP-01 challenge): > > "payload": base64url({ > "type": "http-01", > "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE" >

Re: [Acme] Rolling keys and pending validations

On 06/20/2017 03:07 PM, Dunning, John wrote: > I would advocate for the new one. IOW, I would (expect to) interpret the > semantics as being > > 1. The challenge token was created with respect to an account > 2. An attribute of the account is the credential (whichever credential is > current) >

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

On 03/30/2017 09:04 AM, Sean Leonard wrote: > IN PARTICULAR: both Apache and Ngnix may be subject to a private key > substitution attack with naive passing of the ACME response to the web > server! See: > http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate >

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

> Therefore the “receiver” is the ACME client, which also is the web/TLS server that incorporates the chain into its operations. Note that in common deployment today, the ACME client is separate from the web server. On 03/30/2017 08:27 AM, Sean Leonard wrote: > Contents: DER-encoded

Re: [Acme] Retrying failed authorizations

On 03/29/2017 08:31 PM, Hugo Landau wrote: >> What is the rest of the group's thoughts on whether we'd have to restart >> WGLC for this? > I'd hope that if the 'can retry individual challenges' option is chosen > this is considered a minor enough change to avoid restarting WGLC. > > However, it

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

On 03/29/2017 01:48 PM, Sean Leonard wrote: > If you are saying that the receiver is only expected to handle TLS > 1.2-ordered certificates: “Each following certificate MUST directly > certify the one preceding it” (MUST, not SHOULD) then we have a > different situation and PKCS #7/CMS certs-only

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

On 03/27/2017 05:30 PM, Roland Bracewell Shoemaker wrote: > The original reason for this was that I held the belief that there was > an RFC that set restrictions on the record types that should exist in > the reverse zones (i.e. PTR/CNAME/NS/SOA) only. After looking through > relevant documents

[Acme] Generating nonces probabilistically in 6.4.1. Replay-Nonce

Forwarding on behalf of Erica Portnoy. I agree, the uniqueness should be a MUST, but I think "high probability" should stay so random generation of nonces is acceptable. PR: https://github.com/ietf-wg-acme/acme/pull/289 Forwarded Message Subject:Generating nonces

Re: [Acme] Possible IETF meeting agenda item: reducing effects of key-compromise

I think Zach raises a really interesting point, and I think Niklas' response is spot on. To rephrase it a bit: If ACME allowed "any" hostname on a cert to revoke it, a multi-SAN certificate could be revoked by the owner of any domain name on that certificate. That would effectively prevent

Re: [Acme] Entropy requirement for challenge token

Yep, I think there are two ways of thinking about this, though it's effectively a single problem: 1. Prevent attackers from tricking a validation endpoint into serving a valid challenge response. 2. Prevent ACME clients from implementing a "naive" validation method that would make (1) trivial.

  1   2   3   >