I agree. Reading this I’m not entirely sure what problems it’s trying to solve.
On Fri, Nov 10, 2023 at 08:44 Tim Hollebeek <tim.hollebeek= [email protected]> wrote: > I would suggest that before discussing block chains and smart contracts > for revocation, it would be best to start with a use case and a problem to > solve. Otherwise this discussion will just go in circles. > > > > -Tim > > > > *From:* Acme <[email protected]> *On Behalf Of *Wang Haiguang > *Sent:* Friday, November 10, 2023 2:42 PM > *To:* Q Misell <[email protected]> > *Cc:* My1 <[email protected]>; Aaron Gable <[email protected]>; > [email protected] > *Subject:* Re: [Acme] Decentralized the ACME > > > > Hi, Q > > > > Very sorry that I have no experience in CA operation. Could you please > give us an example that one person saying something and result in > certificate revocation? > > > > Based on my understanding, most of time, the domain name controller can > revoke the certificate instantly through smart contract and voting is > not required in this case. Unless the controller has lost its private keys > completely and then we need find a way to help in the revocation, voting is > one of the potential way for revocation. > ------------------------------ > > *From:* Q Misell <[email protected]> > *Sent:* Friday, 10 November 2023 8:39 PM > *To:* Wang Haiguang > *Cc:* My1; Aaron Gable; [email protected] > *Subject:* Re: [Acme] Decentralized the ACME > > > > You've missed the point entirely. Under no circumstances should agreement > be required to revoke a certificate, there are numerous cases where one > person and one person alone saying something must result in revocation. > ------------------------------ > > 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 > <https://www.google.com/maps/search/13+Pen-y-lan+Terrace,+Caerdydd,+Cymru,+CF23+9EU?entry=gmail&source=g>, > 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 Fri, 10 Nov 2023 at 12:19, Wang Haiguang < > [email protected]> wrote: > > For the voting mechanism, it can be defined in the smart contract. > > > > The smart contract can enroll a group of members for management. These > members can vote through the APIs provided by the smart contract. For > revocation, maybe a simple majority, such as 51%, is enough to revoke a > certificate. > > > ------------------------------ > > *From:* My1 <[email protected]> > *Sent:* Friday, 10 November 2023 7:02 PM > *To:* Wang Haiguang > *Cc:* Q Misell; Aaron Gable; [email protected] > *Subject:* Re: [Acme] Decentralized the ACME > > > > revocation time SERIOUSLY isnt something that should be up to the > certificate owner, it needs to just work, be fast and not need some > "consensus voting". just a proof that it's compromised or mis-issued and be > done. > > > > especially if an entity can maliciously obtain a cert they are not getting > anything with a fast revocation. > > > > Am Do., 9. Nov. 2023 um 19:38 Uhr schrieb Wang Haiguang > <[email protected]>: > > 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 <[email protected]> > *Sent:* Thursday, 9 November 2023 6:48:04 PM > *To:* Wang Haiguang > *Cc:* Aaron Gable; [email protected] > *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 > <https://www.google.com/maps/search/13+Pen-y-lan+Terrace,+Caerdydd,+Cymru,+CF23+9EU?entry=gmail&source=g>, > 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 > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
