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, 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, 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
