Is it necessary to patch ACME standard to differentiate new-order with replace-order?

[xiaohuilam]

Is it necessary to patch ACME standard to differentiate new-order with replace-order?

--

Your honor the Let's Encrypt Team and ACME standard board,

For commercial CA, traditional SSL certificate businesses, there are new-order, reissue (aka replace-order), and revoke operations to a SSL certificate,
Especially new-order, and replace-order, they are involving the issue to accurate billing.

1. If a customer placed an order including www.domain.com, the CA charges him cost 1 × domain (for www.domain.com).
2. And after the first certificate request issued, if he decides to reissue (replace order), to append www.domain2.com to it, the CA charges him cost 1 × domain (for www.domain2.com, and www.domain.com won't be charged twice).

If we try to implement ACME to that customer, the issue appears: When the customer is reissuing the certificate to append a second domain, CA doesn't know which old existing order he's trying to reissue, Even the CA can't tell if the customer is reissuing or making a new purchase, the only choice for ACME server is to charges customer full cost for all domains. (no id, voucher or resource key ACME request will carry to the server).

That's weird if commercial ACME user met.

I know this idea means nothing for letsencrypt free certificate community. But i think this will be helpful to commercial CAs to expand new businesses if ACME protocol can implement. Especially the google chrome team decided to force moving forward to the 90 days lifecycle for all tls certificates, commercial CA's willing to integrate ACME's first consider is it won't destroy their reseller networks and delivery model.

--

Sincere

Bruce

[petercooperjr]

@xiaohuilam

Let's Encrypt Team

To be clear, most people here are just random encryption nerds, not people who work for Let's Encrypt

@xiaohuilam

ACME standard board

And while some people here have been involved with ACME's standardization, it's really "run" by the IETF as I understand it.

@xiaohuilam

When the customer reissuing the certificate to append second domain, CA doesn't know which old existing order he's trying to reissue, Even the CA can't tell if the customer is reissuing or making a new purchase, the only choice for ACME server is to recharges customer full cost for all domains. (no id, voucher or resource key ACME will carry in request to the CA's ACME server).

Wouldn't the CA be able to tell which domains are previously-paid-for, and which domains are not-yet-seen and thus should be charged for? (Assuming a business model where one pays per domain name, which I think is what you're discussing.)

I think some of what you're looking for is in the ARI draft, where one can specify what certificate is being replaced. In particular, draft 02 adds a "replaces" to the order object, so the client can specify which certificate it's intending to update and replace with a new one.

[xiaohuilam]

Thank you peter @petercooperjr for answering me.

The ARI is focused to resolve certificate outage's renewal demand (for example certificate revoked by letsencypt due to CA incidents...), not to differentiate replace-order than new-order.

But thanks for you to remind me the ACME standard's maintenaner!

[petercooperjr]

@xiaohuilam

The ARI is focused to resolve certificate outage's renewal demand (for example certificate revoked by letsencypt due to CA incidents...), not to differentiate replace-order than new-order.

Yes, that's is its focus. I'm just saying that I think the thing you're looking for is something that other people (even free CAs like Let's Encrypt) are also looking for, of being able to specifically request an order as being for a replacement of an existing certificate. Even without payment being involved, or the incident-response scenario that inspired ARI, it could help a free CA handle rate limits better. And if you're looking to add something similar to the standard, it may make sense for it to be a part of the existing work in progress which is somewhat related.

[jvanasco]

You are free to diverge from the ACME RFC to implement new endpoints and try to gain acceptance these concepts but I strongly doubt there will ever be a "reissue" or "replace-order" endpoint adopted by the IETF working group into the ACME standard or as an new standard to extend 8555.

As many have stated before, RFCs are standards that represent what the industry has adopted, not what the industry should support:

@aarongable

That said, you don't have to write an RFC to do this. The IETF adopts RFCs that represent "rough consensus and running code", so even if you did write an RFC, you'd be implementing this solution before that document is finalized. So just go ahead and implement it! Then if you think it is useful enough to be standardized, put forward a draft RFC (and yes, this one is a good example of what it would look like) so that others can benefit from your work.

You can certainly develop your own extension to ACME to implement this and work with other commercial CAs to advocate it being adopted by IETF, but I do not believe the adoption effort will be fruitful.

The behavior you are requesting sounds very specific to your own needs, and will likely vary across commercial CAs. I also believe it would be "Dead On Arrival" with the IETF and many other commercial CAs, because the concept conflates the concepts of an ACME Order with a CA's customer order.

The RFC defines an ACME Order as an ephemeral request (a requested certificate, which may or may not be fulfilled), which is wholly different than a CA's own concept of an Order -- which typically means a fulfilled Certificate that may have taken two or more ACME Orders to fulfill.

(RFC 8555 - Automatic Certificate Management Environment (ACME)):

An ACME order object represents a client's request for a certificate
and is used to track the progress of that order through to issuance.
Thus, the object contains information about the requested
certificate, the authorizations that the server requires the client
to complete, and any certificates that have resulted from this order.

There is no need to support this flow. Commercial and Free CAs are successfully able to handle this sort of account management and bookkeeping through existing means. The features you suggest would complicate the operations of existing Certificate Authorities and provide no real benefits. These types of actions are general bookkeeping and accounting measures, and already successfully handled by commercial CAs within the spec with no divergences needed.

Supporting this in clients would also be incredibly complicated, as you are also trying to introduce what Certbot calls "certificate lineage" into the ACME process. IMHO, adopting such a standard would ultimately create many compatibility issues as many clients and CAs would have no need or desire to implement it.

I suggest you read the full topic from the quote I shared above about RFCs. This sort of custom behavior, and potential extensions to support it, is certain to be best handled within the existing endpoints and flows by submitting the additional information as part of the new-order request.

Edit: As others have noted, the ARI extension - which LetsEncrypt implements and other CAs are assured to follow - introduces a replaces field to new-order -- which is essentially what I suggested in my last paragraph.

[Osiris]

@jvanasco

There is no need to support this flow. Commercial and Free CAs are successfully able to handle this sort of account management and bookkeeping through existing means.

I fully agree.

Also, for ACME there is no such thing as "replace" and with good reasons. In the example number 2 of OP, why would that certificate be a replacement to begin with? It has a completely different set of hostnames, as the second domain was added. It wouldn't even count as a "renewal" by Let's Encrypt standards (note that ACME almost doesn't say anything about renewing, only that a new order is required).

No, this should all be perfectly be managable in the software of the CA itself, not using ACME.

The above are just my two cents..

@xiaohuilam

Your honor the Let's Encrypt Team and ACME standard board,

I don't think there's such a thing as an ACME standards board any longer. I believe when the ACME protocol was just a draft, IETF ACME Working Group · GitHub was used for drafting the protocol, but most of those repo's are, logically, archived, as the draft is an RFC nowadays.

By the way: "Very 1st player of ACME.sh's CVE 0day" << curious to see it seems you're proud to have abused the RCE in acme.sh..

[mcpherrinm]

The acme working group is still active.

https://datatracker.ietf.org/wg/acme/about/

There is a mailing list for discussion of ACME there, with participants from other CAs

[aarongable]

Hi!

This isn't a ridiculous idea, and your use-case makes sense. However, as others have said, it is unlikely that the ACME Working Group (which does still exist and is active) would adopt such a proposal, for two reasons:

1. Some amount of "renewal detection" can be done already, without any changes to the ACME protocol itself. Let's Encrypt already does this -- we examine new-order requests, compare them to existing certificates issued by the same account, and decide if we think they count as a renewal for the sake of bypassing various rate limits. A commercial CA could easily look at the set of names in a certificate, see which ones have already been paid for by the subscriber, and only accept the request if all names have been paid for.

2. The latest draft of the ACME Renewal Information specification includes a new replaces field within new-order requests, which I think would fully satisfy all use-cases that a new replace-order endpoint would.

[xiaohuilam]

@aarongable

2. The latest draft of the ACME Renewal Information specification includes a new replaces field within new-order requests, which I think would fully satisfy all use-cases that a new replace-order endpoint would.

Thank you @aarongable, and replaces parameter is the perfect answer, to append domains & billing by ACME.

And my topic was resolved, it's fine to close it.