> 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= [email protected]> 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:* [email protected] > *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 <[email protected]> > *Sent:* Thursday, 9 November 2023 1:39:05 AM > *To:* Wang Haiguang > *Cc:* [email protected] > *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" 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 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
