Hi， Q
Thanks very much for the comments. I see a lot of challenges ahead 😂. To simplify the discussion, we can focus on the domain name certificate first. Like today we have more than one hundred CAs around the world, we can also imagine that multiple smart contracts are deployed for domain name certificate issuing. If one chain becomes too expensive, we can always select other chains to deploy. Regarding the latency of revocation, if a domain name owner really requires a short revocation time, it can choose to use those centralized CA as today. The decentralized ACME can coexist with centralized CAs. It just provide a different choices for users to use. The same as today that we can either use the currency notes, or we can also use crypto coins for payment. For other issues such as workload, I am not sure yet as the technology has not been deployed yet. However, I believe the discussion here might further inspire the academic to explore the potential of ACME. Have nice day. Haiguang ________________________________ From: Q Misell <q=40as207960....@dmarc.ietf.org> Sent: Thursday, 9 November 2023 6:48:04 PM To: Wang Haiguang Cc: Aaron Gable; acme@ietf.org Subject: Re: [Acme] Decentralized the ACME > There are many different blockchains today and some of them quite cheap in > transaction fees. These blockchain with cheap transaction fees support smart > contract too. Beside that, we can also consider consortium blockchains, which > can have fewer nodes and the cost and transaction speed could be much faster > and cheaper. Blockchains are a speculative asset. As soon as one chain is used for more stuff it becomes more valuable, thus defeating the point of picking another chain. You can't simply hand wave away the mechanics of market capitalism. > Regarding the revocation, I think we can either issue a certificates with > short lives or we can implement a revocation scheme within the smart contract > through voting. Voting may involve some complexity, some design might be > necessary. To have any meaningful effect comparable to revocation certificates would have to be renewed on the order of days or hours (see ACME STAR RFC8739). This would put an impossibly high load on any blockchain. Revocation through voting also doesn't work. There are many cases where a certificate simply has to be revoked, regardless of what the people holding voting rights think. If we limit voting rights to a few authorities, well done you've just re-invented centralisation. > For the Oracle part, as its main functionality is to do the off-chain > verification. The work is much simpler than maintaining a CA. To be frankly > saying, I am not very sure about this point, maybe I have overlooked the > complexity on this. To be blunt: it is not simpler. As Aaron said the RA is one of the core parts of a CA, and what often takes the most time and resources in the CA. > Regarding the issue of browser verifying certificate over blockchain record, > it is similar to the OCSP or CT we used today. And also, for the same > website, the browser does not need to verify it for every https request. The > browser might need to visit the blockchain for certificate verification for > the first time it receives such certificate. Good luck, with that. There is no way on earth that every TLS client will be updated to use this new trust method. Additionally it requires a connection to the internet to download the chain and verify a certificate, something undesirable in many instances such as segregated corporate networks. > I think only one request should be forwarded to the Oracle. It can be done by > submitting the request to the smart contract deployed by the oracle. And > oracle will fetch the request from its smart contract and fetch the results > from the web server, and later on submit verification request to the > certificate issuing contract. That's just not how smart contracts work. They're executed at every node that is competing for the next block. If instead you mean to suggest that there will be one execution of the oracle on one machine, then you don't have a smart contract, you just have a really really inefficient delegated RA. > To simplify the problem, I think we can consider the http-01 challenge first. This actually makes things more complicated. Not only would you have to define all of the protocol first, you'd then have to figure out how it interoperates with the rules built into http-01, which are designed around how ACME operates and not how your new proposal protocol operates. Thanks, Q ________________________________ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574<https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Thu, 9 Nov 2023 at 09:12, Wang Haiguang <wang.haiguang.shieldlab=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: Hi, Aron Continue the discussion, For the question, "- 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." I think only one request should be forwarded to the Oracle. It can be done by submitting the request to the smart contract deployed by the oracle. And oracle will fetch the request from its smart contract and fetch the results from the web server, and later on submit verification request to the certificate issuing contract. To simplify the problem, I think we can consider the http-01 challenge first. Best regards. Haiguang ________________________________ From: Wang Haiguang Sent: Thursday, 9 November 2023 7:23:52 AM To: Aaron Gable Cc: acme@ietf.org<mailto:acme@ietf.org> Subject: Re: [Acme] Decentralized the ACME Hi, Aron Thanks very much for your comments. We have also considered the cost of issuing certificates. As we all know, one Ether coin is today around 1900 USDs. Definitely we do not want to deploy such a decentralized ACME contract on Ethereum blockchain. There are many different blockchains today and some of them quite cheap in transaction fees. These blockchain with cheap transaction fees support smart contract too. Beside that, we can also consider consortium blockchains, which can have fewer nodes and the cost and transaction speed could be much faster and cheaper. Regarding the revocation, I think we can either issue a certificates with short lives or we can implement a revocation scheme within the smart contract through voting. Voting may involve some complexity, some design might be necessary. For the Oracle part, as its main functionality is to do the off-chain verification. The work is much simpler than maintaining a CA. To be frankly saying, I am not very sure about this point, maybe I have overlooked the complexity on this. Regarding the issue of browser verifying certificate over blockchain record, it is similar to the OCSP or CT we used today. And also, for the same website, the browser does not need to verify it for every https request. The browser might need to visit the blockchain for certificate verification for the first time it receives such certificate. My intention here is to let the experts in this group to notice that there is some different thinkings on the design and implementation of ACME. Although it is from academic, it does make the CA operation and management more transparent and trustworthy. We may consider its merit and shortcomings together. Best regards. Haiguang ________________________________ From: Aaron Gable <aaron=40letsencrypt....@dmarc.ietf.org<mailto:40letsencrypt....@dmarc.ietf.org>> Sent: Thursday, 9 November 2023 1:39:05 AM To: Wang Haiguang Cc: acme@ietf.org<mailto:acme@ietf.org> Subject: Re: [Acme] Decentralized the ACME 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<http://myrestaurantname.com>" and "www.myrestaurantname.com<http://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=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> 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 Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
