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 most obviously, the transactions to issue a certificate with a single short DNS Name cost about $5 USD in gas. These costs go up both with the length of the DNS name and the number of DNS Names in the certificate; a median certificate with "myrestaurantname.com" and " www.myrestaurantname.com" appears to cost $15. Worse, it costs money (about $1) to revoke a certificate: this is unacceptable, as revocation is critical for the security model of the Web PKI. Second, the proposal raises many implementation concerns for me. In no particular order: - Only the original issuer (wallet) can revoke a certificate. There's no mechanism for a security researcher who discovers a compromised private key to revoke all certificates with that key. - The description of the Oracle, which mediates between the smart contract running on the Ethereum Virtual Machine and the open internet, seems identical to that of a "Delegated Registration Authority" in the CA/BF Baseline Requirements: i.e. it is the entity which actually performs domain control validation procedures on behalf of the Certification Authority. Those BRs place significant requirements on the operation of an RA, and for good reason: it's the most critical part of CA operations, second only to protecting their private keys. The paper gives no description of how the Oracle's behavior will be monitored, only that "a group of non-cooperating entities can all attest to it". - The number of entities attesting to the Oracle's good behavior also increases the gas cost of issuance, so there are bad incentives here -- less trustworthy certificates cost less to issue. - When an issuance request is processed, all 7.5k Ethereum nodes will execute the smart contract. The paper is unclear on whether the Oracle will forward all of those requests to the origin domain, or will make only a single request and then cache the result. If the former, that's a nice DDoS attack. If the latter, that's significantly more complex behavior for the attesting entities to audit. - What happens when I issue a certificate right before the Ethereum blockchain hard-forks again in a desperate attempt to recover from another gaping security bug? Third, the paper proposes not just a new issuance mechanism, but a new validation mechanism: the browser gets the public key from the blockchain and trusts the server certificate directly, rather than having a list of trusted roots and performing chain-building for validation. This is outside the scope of this working group, and my personal opinion is that this sinks the entire proposal as mainstream browsers will never implement this. Fourth and perhaps most damning, the paper seems to completely misunderstand the ACME protocol. It states repeatedly that it "imitates" the ACME protocol, but as far as I can tell that imitation exists solely in the fact that a) it is automated, and b) it uses a method similar to (but not identical to!) ACME's HTTP-01 for domain control validation. The domain owner does not use any of the ACME protocol's defined request or response methods to communicate with the smart contract; the oracle does not actually use HTTP-01 to perform DCV; and there is no mention made of other aspects of ACME such as DNS-01, wildcard validation, CAA account and method binding, ACME STAR, or others. This paper resembles ACME in name only. Finally, the authors state that the problem they're trying to solve is that people have to trust CAs. But instead they transfer all of this trust simply to the Oracle, and hand-wave the trust problem there. One of their proposed solutions even involves a number of corporations using their own inherently-trusted keys to sign attestations on behalf of the Oracle. That sure sounds like trusting authorities to me! So I do not believe this paper even comes close to solving the problem it sets out to solve, and is not worth pursuing further. Aaron On Wed, Nov 8, 2023 at 5:41 AM Wang Haiguang <wang.haiguang.shieldlab= [email protected]> wrote: > Hello, everyone > > > My name is Haiguang Wang from Huawei. > > > I am interested in the networking and security protocols research. I have > attended IETF meeting since year 2017 and have followed the work in ACME > group for sometime. > > > Last year we have come across a research paper "A Blockchain-based Method > for Decentralizing the ACME Protocol to Enhance Trust in PKI". Following > is the information of the paper: > > E. F. Kfoury, D. Khoury, A. AlSabeh, J. Gomez, J. Crichigno and E. > Bou-Harb, "A Blockchain-based Method for Decentralizing the ACME Protocol > to Enhance Trust in PKI," *2020 43rd International Conference on > Telecommunications and Signal Processing (TSP)*, Milan, Italy, 2020, pp. > 461-465, doi: 10.1109/TSP49548.2020.9163555. > > > We have studied the scheme for sometime but not sure whether it is a good > direction for ACME or not. The scheme implements the ACME in smart > contract and make the whole procedure of certificate more transparent, not > only in CT log, but also in the certificate issuing and management. > > > We would like to hear comments from the experts in this group. > > > Best regards. > > > Haiguang Wang > > Huawei International Pte. Ltd. > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
