Dear IETF ACME Working Group, I hope this message finds you well.
I recently reviewed the attack model discussed in Section 11.1 of RFC 8555, specifically regarding the consequences of compromising an ACME account's private key. In light of these concerns, I would like to propose ACME++, an enhancement to the ACME protocol designed to prevent attackers from issuing fraudulent certificates. Below, I provide an brief overview of the key components of ACME++ and its protocol design. 1. Client Authz Object ACME++ introduces enhanced client verification mechanisms, with a primary focus on the Client Authz object. This object serves as a unique verification token that binds an ACME client to a specific account. It combines the client's IP address and a client-generated ID, helping to distinguish legitimate clients from potential attackers, while making the system more resilient to brute-force and other types of attacks. Client Authz Object Fields: Field Name Description status Current verification status of the identifier. expires Current verification expiration time. identifier Unique identifier consisting of the client's IP address and client-generated ID. challenges A list of ACME Challenge objects for client verification. 2. newClientAuthz Directory Service ACME++ introduces a new endpoint, newClientAuthz, as part of the CA server Directory services. The client can send a POST-as-GET request to /acme/client-authz/<authz_id> to access the Client Authz object. The client can then complete the challenges in the object using HTTP-01 or DNS-01 challenge types. Upon successful completion of all challenges, the client is verified, and the CA updates the Client Authz object status to "valid," allowing the CA to proceed with certificate issuance. 3. ACME++ Protocol Workflow The ACME++ protocol workflow can be summarized as follows: 1. The ACME client initiates a newOrder request, including its IP address, self-generated client ID, ACME account key, and Account UID in the request to the CA server. 2. The CA performs two verification steps: * It checks whether the client's communication IP matches the submitted IP address. * It verifies the existence of a valid Client Authz record for the client. If both conditions are met, the CA proceeds with certificate issuance according to the standard ACME protocol. If the IP addresses do not match, the CA terminates the connection, as this may indicate a compromised ACME account. If no valid Client Authz record exists, the CA generates a new Client Authz object for the client, assigns it a "pending" status, and returns the object ID along with challenges to the client. The challenge generation follows a structured approach: the CA retrieves all valid Authz records associated with the account and randomly selects a few (in logarithmic scale) to create new challenges, which the client must complete to re-validate domain ownership. I hope that ACME++ can provide an additional layer of security for ACME-based certificate management, helping to mitigate potential attacks while streamlining the verification process for legitimate clients. I would greatly appreciate any feedback or suggestions the Working Group might have regarding this proposal. Thank you for your attention to this matter. I look forward to your thoughts. Best regards, Tianyu Zhang Tsinghua University
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
