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 <wang.haiguang.shieldlab=40huawei....@dmarc.ietf.org>: > 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> 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 >> *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> >> *Sent:* Thursday, 9 November 2023 1:39:05 AM >> *To:* Wang Haiguang >> *Cc:* 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" 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= >> 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 >>> https://www.ietf.org/mailman/listinfo/acme >>> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
