DigiCert पर Bugzilla चर्चा दबाने के लिए कानूनी कार्रवाई की धमकी देने का आरोप

 (bugzilla.mozilla.org)
1 पॉइंट द्वारा GN⁺ 2025-02-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Sectigo के Chief Legal Officer Brian Holland ने DigiCert के कानूनी प्रतिनिधि Wilson Sonsini से मिला कानूनी पत्र सार्वजनिक किया, जिससे WebPKI की खुली चर्चा पर ठंडा प्रभाव पड़ने की आशंका को लेकर विवाद बढ़ गया
  • DigiCert ने शुरुआत में कहा कि यह कदम प्रतिस्पर्धी के भ्रामक बयानों और फ़ोरम के दुरुपयोग की आशंका के कारण उठाया गया था, लेकिन बाद में स्वीकार किया कि C&D भेजना अनुचित था
  • इस विवाद की पृष्ठभूमि में DigiCert के बड़े पैमाने पर certificate revocation मामले से जुड़ा TRO था, और DigiCert ने कहा कि TRO का असर केवल 1 certificate पर था और वह सार्वजनिक रिकॉर्ड में मौजूद था
  • समुदाय और Chrome Root Program का मानना था कि WebPKI भागीदारी को ठंडा करने वाला व्यवहार ecosystem के मूल्यों से मेल नहीं खाता, और अंततः DigiCert ने incident report तथा पुनरावृत्ति-रोधी उपाय जमा किए
  • DigiCert ने आगे से सक्रिय Bugzilla incidents के तकनीकी और policy मुद्दों को कानूनी चैनल की बजाय Bugzilla में ही उठाने, और कानूनी कार्रवाई की ज़रूरत पड़ने पर executive review व सार्वजनिक सूचना लागू करने, साथ ही ombudsperson program चलाने की बात कही

Sectigo द्वारा सार्वजनिक किया गया DigiCert का C&D पत्र

  • Brian Holland ने कहा कि DigiCert ने पहले Bugzilla टिप्पणी में यह कहा था कि उसने “legal team को जवाबदेही से बचने की ढाल की तरह इस्तेमाल नहीं किया”, लेकिन वास्तव में Sectigo को DigiCert के कानूनी प्रतिनिधि Wilson Sonsini से Sectigo की टिप्पणियों पर एक पत्र मिला था
  • उस पत्र में Sectigo के Chief Compliance Officer Tim Callan द्वारा Bugzilla में की गई टिप्पणियों पर आपत्ति जताई गई थी, और मांग की गई थी कि Sectigo “यह सुनिश्चित करे कि Mr. Callan की टिप्पणियाँ जारी न रहें और Sectigo संगठन के अन्य सदस्य उन्हें दोहराएँ नहीं”
  • पत्र में Lanham Act, deceptive trade practices, corporate disparagement, tortious interference का उल्लेख था, और इसमें DigiCert द्वारा कानूनी कार्रवाई की संभावना भी शामिल थी
  • Holland ने 10 दिसंबर 2024 के उत्तर में कहा कि जिन बयानों पर आपत्ति की गई वे प्रश्न या राय थे, और WebPKI की महत्वपूर्ण चर्चा को आगे बढ़ाने के लिए थे, इसलिए वे कानूनी दावे का आधार नहीं बन सकते
  • Sectigo का कहना था कि सार्वजनिक CA practices पर निगरानी और चर्चा को ठंडा करने वाली कानूनी धमकियाँ CCADB incident reporting guidelines में अपेक्षित पारदर्शी post-mortem culture के अनुरूप नहीं हैं

DigiCert की शुरुआती प्रतिक्रिया और समुदाय की प्रतिक्रिया

  • DigiCert ने जवाब दिया कि वह Bugzilla और CA community के आदर्शों का समर्थन करता है, और उक्त पत्र का उद्देश्य खुली और ईमानदार बातचीत को सुरक्षित रखना था
  • Entrust distrust के बाद कुछ प्रतिभागियों द्वारा Bugzilla में भ्रामक जानकारी या अधूरे तथ्य डालकर जनमत को नकारात्मक रूप से मोड़ने और bugs को आवश्यकता से अधिक समय तक खुला रखने की कोशिश को लेकर भी चिंता जताई गई
  • Sectigo के उत्तर के बाद DigiCert ने कोई अतिरिक्त कदम या प्रतिक्रिया नहीं की, और उसका कहना था कि उसे लगा मामला समाप्त हो गया है, जब तक Sectigo ने इसे फिर से सार्वजनिक नहीं किया
  • कई community participants ने आलोचना की कि पूरे पत्र को कानूनी धमकी के रूप में ही पढ़ा जाएगा, और DigiCert से कुछ गलती स्वीकार कर internal communication सुधारने की मांग की
  • Mozilla की ओर से कहा गया कि पारदर्शी community-based process एक मूल सिद्धांत है, और चर्चा में भागीदारी को ठंडा करने वाला व्यवहार, चाहे सार्वजनिक हो या निजी, समुदाय को गहरी क्षति पहुँचाता है

क्या यह incident था, और Chrome Root Program की दखल

  • DigiCert ने शुरू में अनुरोध किया कि चूँकि यह मामला compliance requirement के उल्लंघन का आरोप नहीं है, इसलिए bug बंद कर दिया जाए
  • community participants ने Chrome Root Program Policy का हवाला देते हुए कहा कि Chrome Root Program Participant की integrity, reliability, compatibility को प्रभावित करने वाली स्थिति भी incident मानी जा सकती है
  • Chrome Root Program का कहना था कि community feedback से यह स्पष्ट है कि लोग जानना चाहते हैं कि DigiCert भरोसा और goodwill बहाल करने के लिए क्या प्रयास करेगा
  • अलग CCADB incident report के बजाय इसी Bugzilla discussion में DigiCert द्वारा समुदाय की चिंताओं का सीधे जवाब देना अधिक प्रभावी माना गया
  • बाद में DigiCert ने भी सहमति जताई कि यह चर्चा community concerns को संबोधित करने का प्रभावी तरीका है, और उसने अतिरिक्त सवालों के जवाब देने की बात कही

DigiCert की स्वीकारोक्ति और incident report

  • DigiCert ने माना कि उसने शुरुआत में प्रतिस्पर्धी के भ्रामक बयानों का जवाब देने के लिए पत्र भेजना उचित समझा था, लेकिन बाद में उसने स्वीकार किया कि यह पत्र पारदर्शिता और समुदाय के सर्वोत्तम हित के अनुरूप नहीं था
  • उसका कहना था कि Bugzilla forum के code of conduct और community participation guidelines का उपयोग बेहतर रास्ता होता, और यदि वह नवंबर 2024 में लौट सकता तो वही पत्र नहीं भेजता
  • इसके बाद DigiCert ने Full Incident Report जमा की, जिसमें 11 नवंबर 2024 को उसके कानूनी प्रतिनिधि द्वारा Sectigo को भेजे गए C&D को incident के रूप में दर्ज किया गया
  • रिपोर्ट में माना गया कि C&D Bugzilla चर्चा से बहुत निकटता से जुड़ा था, इसलिए इससे खुली चर्चा पर ठंडा प्रभाव पड़ सकता था, और perceived misinformation को सार्वजनिक Bugzilla संदर्भ में ही सुधारना अधिक उचित होता
  • DigiCert ने स्पष्ट रूप से कहा कि मूल पत्र “Tim Callan के बयानों के आधार पर कानूनी कार्रवाई पर विचार करने की धमकी” था, लेकिन यह भी माना कि उस स्थिति में C&D उचित प्रतिक्रिया नहीं थी

कारण के रूप में गिनाए गए तत्व

  • DigiCert ने पहला contributing factor TRO की नवीनता को बताया
    • उसका कहना था कि Bugzilla 1910805 का mass revocation मामला DigiCert के लिए एक महत्वपूर्ण घटना थी, और उद्योग में फिर से पुष्टि हुई कि revocation deadline के लिए कोई exception basis नहीं है
    • DigiCert ने कहा कि revocation प्रक्रिया के दौरान उसे TRO सहित कई exception claims मिले, और TRO ने revocation में केवल सीमित भूमिका निभाई, लेकिन transparency के लिए उसका खुलासा किया गया
  • दूसरा contributing factor प्रतिस्पर्धी संबंध था
    • DigiCert और Sectigo प्रत्यक्ष प्रतिस्पर्धी हैं, और सार्वजनिक रूप से भरोसेमंद CA से जुड़े व्यक्तियों की Bugzilla भागीदारी प्रतिस्पर्धी तनाव पैदा कर सकती है
    • DigiCert ने कहा कि Tim Callan की 24 Bugzilla टिप्पणियों में से 18 DigiCert bugs पर थीं, और उसने इसे competitive sensitivity के संदर्भ में देखा
  • mass revocation incident के बाद compliance और standards संभालने वाले एक executive ने इस्तीफ़ा दे दिया, जिससे सामान्य compliance workflow और approval process प्रभावित हुए
  • बाद की प्रतिक्रिया में DigiCert ने कहा कि Legal team ने C&D भेजने से पहले Standards/Compliance team से चर्चा की थी, और उस team के सदस्यों ने चिंता जताई थी, लेकिन Legal team ने internal opposition के बावजूद भेजने का निर्णय लिया

पुनरावृत्ति रोकने के उपाय

  • DigiCert ने incident report और closure summary में कहा कि उसने चार उपाय पूरे कर लिए हैं

  • Technical-First Dispute Resolution

    • incident reporting के दौरान तकनीकी मुद्दे, भ्रामक अभिव्यक्ति, और compliance policy violation की चिंताओं को कानूनी चैनल की बजाय संबंधित Bugzilla में उठाया जाएगा
    • यदि सक्रिय incident से जुड़े मामले में कानूनी कार्रवाई की ज़रूरत पड़े, तो उस निर्णय और कार्रवाई को संबंधित Bugzilla में सार्वजनिक किया जाएगा

  • Community Transparency Pledge

    • incident-संबंधित communication को MDSP, CCADB, CA/B Forum, Bugzilla जैसे community forums में सार्वजनिक रूप से संभाला जाएगा ताकि traceability बनी रहे
    • टिप्पणी करने वालों से संपर्क को भी incident के संदर्भ में document और publish किया जाएगा ताकि वह retaliation या ambush जैसा न लगे

  • Legal Review Gate

    • incident से intersect करने वाली कानूनी कार्रवाई executive-level review और approval से गुज़रेगी, और इसमें यह विश्लेषण शामिल होगा कि ऐसी कानूनी कार्रवाई उचित है या नहीं
    • यदि तत्काल सार्वजनिक सूचना संभव न हो, तो root program को पहले private notification दी जाएगी और बाद में public follow-up दिया जाएगा

  • Ombudsperson Role for WebPKI Concerns

    • DigiCert ने WebPKI में fairness, openness, और chilling effect जैसी चिंताओं को निजी रूप से उठाने के लिए एक आंतरिक ombudsperson process बनाने का फैसला किया
    • बाद में बाहरी स्वतंत्र व्यक्ति Don Sheehy ज़रूरत पड़ने पर सहयोग देने वाले रूप में ombudsperson team से जुड़े

ombudsperson program और बाद का विवाद

  • DigiCert ने पहले घोषणा की कि ombudsperson team में Program Management, Compliance, और Legal विभागों के प्रतिनिधि होंगे, और उनसे transparency@digicert.com पर संपर्क किया जा सकता है
  • community participants ने सवाल उठाया कि केवल आंतरिक लोगों से बना ombudsperson पर्याप्त स्वतंत्र होगा या नहीं, और DigiCert ने कहा कि वह बाहरी community members या स्वतंत्र व्यक्तियों को शामिल करने पर विचार करेगा
  • DigiCert ने ombudsperson process के संचालन का तरीका भी सार्वजनिक किया
    • submission transparency@digicert.com या digicert.com/transparencyform के माध्यम से किया जा सकता है
    • इसमें receipt acknowledgment, case number assignment, classification और routing, investigation, 7 दिन के अंतराल पर updates, और report creation process शामिल है
    • anonymous submission संभव है, लेकिन यदि अतिरिक्त सत्यापन की ज़रूरत पड़े और संपर्क जानकारी न हो, तो मामला तुरंत बंद किया जा सकता है
  • DigiCert ने ICANN Ombudsman से संबंधित Frank Fowlie की PhD thesis को संदर्भ सामग्री के रूप में उद्धृत किया, और कहा कि program को सतत सुधार के तरीके से चलाया जाएगा
  • कुछ community participants ने DigiCert के इस दृष्टिकोण का विरोध किया कि हर CA को ombudsperson की ज़रूरत है, और तर्क दिया कि कानूनी धमकी का उपयोग करने वाले CA पर अधिक कड़ी कार्रवाई WebPKI भरोसे के लिए बेहतर होगी

समापन सार और स्थिति

  • DigiCert के अंतिम closure summary में कहा गया कि 11 नवंबर 2024 को DigiCert द्वारा नियुक्त law firm ने Sectigo को C&D भेजा था, और DigiCert ने C&D के Bugzilla तथा अन्य forums की communication पर पड़ने वाले प्रभाव पर पर्याप्त विचार नहीं किया
  • incident के कारणों को TRO से जुड़ी perceived misinformation, प्रतिस्पर्धी संबंध, और overreaction के रूप में संक्षेपित किया गया
  • remediation के रूप में DigiCert ने Sectigo और व्यापक WebPKI community से औपचारिक माफ़ी, ombudsperson program, स्वतंत्र सदस्य जोड़ने, और legal communication review protocol पेश किया
  • उसने वादा किया कि भविष्य में सक्रिय incidents के दौरान तकनीकी, भ्रामक, और policy मुद्दों को संबंधित Bugzilla में ही संभाला जाएगा, और यदि सक्रिय incident से जुड़े मामले में कानूनी चैनल का उपयोग आवश्यक लगे तो उस निर्णय और कार्रवाई को संबंधित Bugzilla में सार्वजनिक किया जाएगा
  • अंत में समुदाय से अतिरिक्त टिप्पणियाँ या सवाल माँगने वाला final call पोस्ट किया गया, और बताया गया कि मामला लगभग 17 सितंबर 2025 को बंद होने वाला है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-02-26
Hacker News की रायें

  • संक्षेप में, DigiCert ने Baseline Requirements द्वारा अनुमति दी गई सीमा से आगे जाकर कुछ बार certificate revocation में देरी की, और हाल के मामले https://bugzilla.mozilla.org/show_bug.cgi?id=1896053 और https://bugzilla.mozilla.org/show_bug.cgi?id=1910805 हैं
    पहले मामले में ऐसा लगता है कि किसी खास ग्राहक को शांत रखने के लिए revocation टाली गई, और दूसरे में temporary restraining order (TRO) की वजह से समय पर revocation नहीं हो पाई
    Sectigo के Tim Callan ने सार्वजनिक रूप से आलोचना की कि दोनों मामलों में DigiCert ने ग्राहकों के सामने पर्याप्त मजबूती से रुख नहीं लिया, और खासकर यह चिंता है कि TRO जैसे उपाय revocation में देरी कराने के लिए ज्यादा बार इस्तेमाल हो सकते हैं
    Sectigo और WebPKI ecosystem के दूसरे पक्ष चाहते दिखते हैं कि DigiCert ग्राहकों को revocation policy बहुत स्पष्ट रूप से बताए, और यह सुनिश्चित करे कि ग्राहक सच में समय पर certificates बदल सकें
    Sectigo सबसे ज्यादा मुखर जरूर है, लेकिन DigiCert की delayed revocations पर नियंत्रण की मांग करने वाला अकेला पक्ष Sectigo ही नहीं लगता; इसलिए legal threats तक escalate करना वाकई अनुचित है और DigiCert को इस tactic की वजह से काफी बड़ा backlash झेलना पड़ सकता है

    • DigiCert ऐसा लगता है जैसे जिन procedures का उसे पालन करना था, उनका पालन करते हुए नाराज ग्राहकों से खुद को बचाने के लिए TRO के पीछे छिप रहा हो
      ऐसा नहीं लगता कि वह अपने legal documents में बदलाव करना चाहता है ताकि ग्राहक certificate revocation पर legal action न कर सकें, और अब तक legal action DigiCert के पक्ष में काम करता रहा है
      जिस कंपनी का पूरा business company-name validation और CA procedures को process करना है, वही उन procedures का पालन करने में काफी निष्क्रिय दिखती है
      Alegeus Technologies LLC जैसे तकनीकी रूप से अक्षम ग्राहक को TRO file करने से तो शायद रोका नहीं जा सकता, लेकिन उचित procedure का पालन न करना इस बार पहली बार नहीं है
      नकारात्मक चर्चा को अदालत के जरिए रोकने की कोशिश करना किसी CA के लिए काफी घटिया दिखता है, और पहले से ही संदेह और अविश्वास का निशाना बन चुकी DigiCert का ऐसा करना कोने में फंसकर आलोचना से बचने की आखिरी कोशिश जैसा लगता है
      ग्राहक खुश होंगे कि DigiCert तय समय पर certificate replacement enforce नहीं करता, लेकिन अगर मामला बिगड़कर DigiCert को trust list से हटा दिया गया, तो वे अचानक किसी दूसरे certificate provider को खोजने की चौंकाने वाली स्थिति में होंगे
    • Callan का आखिरी जवाब यहां है: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c73
      देखने में यह काफी reasonable है
    • जब TRO किसी कंपनी को certificates revoke न करने का आदेश देता है, तो सही कदम क्या होना चाहिए? क्या कंपनी को revocation delay करनी चाहिए, लेकिन judicial system पर जोर डालना चाहिए कि मामला जितनी जल्दी हो सके सुलझे?
    • Sectigo क्या Comodo नहीं है? उस तरफ से ऐसा होना और भी ironic है

  • Web PKI drama हमेशा हैरान इसलिए करता है क्योंकि यह दुनिया के उन बेहद कम क्षेत्रों में से एक है जहां कंपनियां “हद पार” करती हैं और अक्सर तुरंत ही ठंडे दिमाग से “कीमत चुकाने” का सामना करती हैं
    कौन से CA पर trust करना है यह तय करने वाली कई संस्थाएं असल में दुनिया के किसी भी CA business को लगभग तुरंत खत्म कर सकती हैं
    अगर DigiCert यह खेल खेलकर हार गया, तो वह अब तक का सबसे बड़ा हारने वाला होगा, और जहां तक मुझे पता है DigiCert internet का सबसे बड़ा CA है
    अगर internet का सबसे बड़ा CA trust stores से हटाया जाता है, तो यह मजबूत message भेजेगा और बड़ा disruption भी पैदा करेगा, लेकिन ऐसा असंभव होने की कोई खास वजह नहीं है
    बेशक मुझे इसकी संभावना कम लगती है, लेकिन सिर्फ यह कल्पना करना भी संतोष देता है कि DigiCert में जिसने भी legal team को यहां शामिल करना अच्छा विचार समझा, उसे जिंदगी भर की डांट सुननी पड़ेगी
    मैंने वह thread पढ़ा है और यह DigiCert के लिए अच्छा नहीं दिखा; फिर भी मुझे लगता है कि यह कदम DigiCert के लिए Collan द्वारा कही गई किसी भी बात से कहीं ज्यादा नुकसानदेह है

    • तब तो ग्राहकों को अपना business Honest Achmed[1] को देना पड़ेगा
      [1] https://bugzilla.mozilla.org/show_bug.cgi?id=647959
    • trust stores और खासकर browsers के पास CA को सीधे हटाने के अलावा भी विकल्प हैं
      इस scale के CA के लिए trust withdrawal process में किसी खास तारीख के बाद जारी किए गए नए certificates को अब accept न करना ज्यादा तार्किक होगा
      तब मौजूदा ग्राहकों को पहले से पता चल जाएगा, और responsible person के छुट्टी पर होने के दौरान अचानक मामला फटने के बजाय regular renewal के समय बुरी खबर पता चलेगी
    • जो लोग बकवास के बादल के पीछे छिपने के आदी लगते हैं, उन्हें उन लोगों द्वारा बारीकी से घेरा जाता देखना ताजगी भरा है जो उसे भेदकर देखने के लिए काफी जानते हैं और सभी threads को अंत तक follow करने का समय और ऊर्जा रखते हैं
      हालिया DigiCert threads से Entrust incident तक पहुंची प्रक्रिया जैसी संदिग्ध रूप से मिलती-जुलती गंध आती है
    • क्या किसी खास तारीख के बाद बनाए गए सभी certificates पर trust बंद करने का option है? Ideally, existing certificates चलते रहें और सिर्फ नए certificates पर trust न किया जाए, तो अच्छा होगा
    • अगर internet का सबसे बड़ा CA trust stores से हटाया जाता है, तो यह मजबूत message भेजेगा और बड़ा disruption भी पैदा करेगा, लेकिन कितने पक्ष उस removal से सहमत होंगे?
      कितने लोग, किसी ऐसे अज्ञात, बेचेहरा actor द्वारा चीजें बिगाड़ने का एक और तरीका देखकर, automatic updates हमेशा के लिए बंद कर देंगे और खुद तय करेंगे कि किस पर trust करना है?
      मजबूत message तो जरूर जाएगा, लेकिन हो सकता है कि वह intended message न हो
      आखिर में इससे centralized PKI के प्रति कुल मिलाकर अविश्वास ही और बढ़ेगा

  • Bugzilla के मुताबिक, underscore की असली वजह यह है कि जिन services में users subdomain पर DNS record बना सकते हैं—जैसे dynamic DNS service—वे underscore से शुरू होने वाले subdomain registration को रोककर अनचाहे certificate issuance से बच सकें।
    यह उसी तरह है जैसे agreed website change method में /.well-known की भूमिका होती है, या domain contact configuration email में admin/administrator/webmaster/hostmaster/postmaster की भूमिका होती है।
    DigiCert ने बिना underscore वाले DNS record का इस्तेमाल करके उन services की security-critical assumption को तोड़ दिया, जिस पर वे निर्भर थीं।
    इसलिए यह वाकई security के लिहाज से गंभीर incident है, और बहुत बड़े scale की घातक गलती है।
    इस स्तर पर समझ नहीं आता कि DigiCert certificates पर भरोसा किया भी जा सकता है या नहीं।

    • संबंधित comment का direct link: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c10
      उस comment के लेखक Andrew Ayer हैं, और वे CA incidents और procedures पर बेहतरीन पोस्ट भी अपने blog पर लिखते हैं: https://www.agwa.name/blog/index
    • बड़ी चिंता यह है कि subdomain delegate करते समय कितने प्रतिशत लोग यह पहचान पाएंगे कि leading underscore एक security vulnerability है।

  • हमेशा दोनों पक्षों की कहानी होती है, लेकिन DigiCert में validation bug बनाने वाले व्यक्ति ने उसी बात पर पहले ही resign कर दिया था, और यह अपने-आप में भी extreme है।
    Sectigo वाले व्यक्ति ने bug को बंद न होने देकर DigiCert की overall responsiveness पर और जवाब मांगना जारी रखने की कोशिश की, और subjective तौर पर कहें तो तरीका काफी तीखा था।
    कुछ हद तक आगे-पीछे की बहस ठीक और expected है, लेकिन अगर आप अपनी legal team वाली counterparty को लगातार push करते हैं, तो आखिरकार वे coffee machine के पास legal team से बात करेंगे, और legal team जब इसमें देखेगी तो यह उनका issue बन जाएगा।
    इसलिए पहला principle यह है कि अगर आप legal team को बुलाना नहीं चाहते, तो legal शब्द तक न छेड़ें।
    यह response सिर्फ पीछे हटने के लिए भेजा गया letter है, और legal team के होने की वजह ही यही है कि पक्ष आपस में argue करें।
    बस इस बार यह public में leak हो गया।
    यह viewpoint समझ आता है कि CA को discussion process में legal risk नहीं उठाना चाहिए, लेकिन यह इस fact से टकराता है कि वे अपने हितों की रक्षा करने वाली commercial entities हैं।
    जब तक सभी CA non-commercial नहीं होते, दोनों चीजें साथ-साथ नहीं मिल सकतीं; और non-commercial होने पर भी उसकी limits होंगी।

    • शायद उन्हें PR department से भी बात करनी चाहिए थी।
      वैसे ही जैसे company strategy के लिए जिम्मेदार किसी भी व्यक्ति से।
      क्योंकि legal team की कार्रवाई backfire कर गई।
    • आपने काफी detail में summarize किया है, जैसे काफी follow किया हो; उस resignation को लेकर आपका sense क्या है? क्या वह voluntary resignation था, या DigiCert management द्वारा उसे scapegoat बनाए जाने की ज्यादा संभावना वाली चीज?
    • असल में उसने resign नहीं किया।
      उसे contractor के तौर पर रखा गया, और संभव है कि वह शायद reinstatement का इंतजार कर रहा हो।
      यह गलत समझ लिया गया था।

  • यह shocking है।
    Web PKI contributors की legitimate speech को legal harassment से रोकने की कोशिश भर ही organization के purpose और goals को पूरी तरह उलट देती है, और personally मेरे हिसाब से DigiCert से जुड़ी हर चीज को तुरंत discard करने लायक है।

    • DigiCert से जुड़ी हर चीज को तुरंत discard करने की बात काफी extreme है, और लगता है कि इसके नतीजे कैसे दिखेंगे, इस पर पर्याप्त सोचा नहीं गया।
      problematic CA से निपटने का historical तरीका यह रहा है कि immediate नुकसान handle करने के बाद नए certificates issue करने या renew करने से रोका जाए।
      DigiCert इस्तेमाल करने वाली कई legitimate companies भी हैं, और उन्हें यह expectation होनी चाहिए कि वे दूसरा certificate provider खोजते समय short term में operations जारी रख सकें।

  • original report (https://bugzilla.mozilla.org/show_bug.cgi?id=1910322) देखने पर कुछ सवाल दिखते हैं जिनसे DigiCert बचता हुआ लगता है।
    Alegeus Technologies LLC v. DigiCert के public record में ऐसा कोई प्रयास नहीं दिखता कि court order को challenge किया गया हो, जबकि अगर ऐसी application दी गई होती तो DigiCert लगभग 120 घंटे के preference period के खत्म होने से कई दिन पहले certificates revoke कर सकता था।
    साथ ही comment 28 में एक और सवाल यह था कि Alegeus Technologies certificates revoke करने के DigiCert के अधिकार को तय करने वाली wording क्या थी।
    DigiCert इस बिंदु पर डांवाडोल रहा; पहले उसने imply किया कि wording website पर है, फिर बाद में यह confirm करने से इनकार कर दिया कि उस समय site की wording Alegeus Technologies पर लागू होती थी या नहीं।
    अंदाजा लगाएं तो हो सकता है DigiCert ने Alegeus और दूसरे customers को special terms दिए हों, और contractual basis न होने के कारण उसने TRO को court में challenge न किया हो।
    यह भी संभव है कि उस contract में confidentiality clause हो, जिसकी वजह से वे इस बारे में बोल नहीं सके।
    ऊपर quote किए गए सवालों के satisfy न होने के बावजूद forum ने इस issue को बंद होने दिया, यह हैरान करने वाला है; हालांकि मैंने linked issue पूरा नहीं पढ़ा है, इसलिए संभव है कि कहीं और इसका जवाब दिया गया हो।
    इसके अलावा, DigiCert ने दूसरे thread में जो जवाब दिया (https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c43) वह इस अनुमान से contradict करता दिखता है।
    खासकर यह हिस्सा: “DigiCert के TOU और MSA ने Alegeus की उस कार्रवाई को prohibit किया था, लेकिन जब Alegeus ने TRO के लिए apply किया और court ने लगभग तुरंत उसे grant कर दिया, तो DigiCert के हाथ बंध गए।”

    • तो क्या judge ने TRO sign करने से पहले TOU नहीं पढ़ा?
      सोचता हूं कि क्या CAB Forum के पास Alegeus या उस judge के खिलाफ lawsuit file करने का legal standing होगा, जिन्होंने invalid TRO से PKI procedures में बाधा डाली।

  • इन पत्रों में जिन तारीखों की ओर इशारा है, उनसे दो महीने से थोड़ा ज़्यादा समय बीतने के दौरान क्या हुआ था?

    • DigiCert ने 15 दिन पहले पोस्ट किया था, “हमने जवाबदेही से बचने के लिए legal team को ढाल की तरह इस्तेमाल नहीं किया”(https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c74)
      यह Sectigo के खिलाफ कानूनी धमकी से साफ़ तौर पर विरोधाभासी है
      इसलिए Sectigo ने community को यह बताने के लिए Threat of legal action bug पोस्ट किया कि DigiCert ने वास्तव में क्या किया था
      अगर DigiCert ने वह comment न किया होता, तो शायद Sectigo भी चुप रहता
    • Bugzilla पर आगे-पीछे चली चर्चा: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c63

  • Certificate Authorities पर सभी internet users का भारी भरोसा होता है। चाहे user को यह बात पता हो या न हो
    उस भरोसे के अनुरूप उन पर बहुत बड़ी ज़िम्मेदारी भी होती है, और नाम के मुताबिक Baseline Requirements हासिल किए जाने वाले न्यूनतम मानक हैं
    अगर वे तय समय के भीतर जारी किए गए certificates revoke नहीं कर सकते, या ऐसा करने की इच्छा नहीं रखते, तो वे इस भरोसे के योग्य नहीं हैं और उन्हें हटाया जाना चाहिए
    समझता हूँ कि TRO ने लगभग 70 certificates के revocation को रोका था, और उस मामले में वाकई कुछ और किया नहीं जा सकता था
    लेकिन बाकी revocation failures के लिए कोई बहाना नहीं है

  • bug को DigiCert के जवाब के साथ update किया गया है
    हर कोई अपना निष्कर्ष खुद निकाल सकता है, लेकिन DigiCert के अगले वाक्य पर मुझे सच में हँसी आ गई
    “असल में, आपको भेजा गया हमारा पत्र खुले और ईमानदार संवाद को बढ़ावा देने की हमारी इच्छा के अनुरूप था”

  • भले ही DigiCert के पत्र में बातचीत के वर्णन को ज्यों का त्यों मान लिया जाए, Sectigo वाला व्यक्ति अच्छे से अच्छा कहें तो कठिन था, और बुरे से बुरा देखें तो जानबूझकर trolling कर रहा हो सकता था
    मुझे नहीं लगता कि वास्तव में ऐसा था, लेकिन devil’s advocate बनकर कहें तो बात ऐसी हो सकती है
    फिर भी DigiCert ने कैसे सोचा कि legal team का शामिल होना अच्छा नतीजा देगा?
    Sectigo के पास इसे CAB में सार्वजनिक करके publicity पाने का मौका था, जैसा उसने यहाँ किया, और खोने को कुछ नहीं था; CAB कोई marriage counselor भी नहीं है जो दोनों कंपनियों में सुलह करा दे
    ऊपर से, इस तरह की बेहद विनम्र passive-aggressive “हम्म, actually” वाली बातचीत CAB की हर incident discussion में होती है
    समझ नहीं आता कि DigiCert खास तौर पर इसी मामले पर इतना नाराज़ क्यों हुआ

    • CAB reports बहुत ज़्यादा न देखने वाले व्यक्ति के तौर पर, वह हिस्सा काफ़ी चौंकाने वाला था
      DigiCert की कानूनी कार्रवाई अजीब लगती है, और यह विचार कि किसी कंपनी का customer legal system का इस्तेमाल करके उस कंपनी को अन्य entities के प्रति अपने दायित्व निभाने से रोक सकता है, सचमुच खतरनाक समस्या जैसा दिखता है
      लेकिन thread की बहस देखें तो इसे productive तरीके से संभालने का रास्ता साफ़ नहीं दिखता
      यह ऐसा लगता है जैसे मंच पर typical corporate drones और typical IRC geeks संवाद बोलते हुए कोई नाटक कर रहे हों; दोनों पक्ष दिलचस्प विषय के आसपास मंडराते हैं, लेकिन आपस में भिड़ने में लगे रहते हैं और असली मुद्दे तक पहुँच ही नहीं पाते