الخلاصة

  • يبدأ مؤقت القبول لمدة ثلاثين يوماً في RFC 9691 عندما يتحقق كل طرف معتمد لأول مرة من علاقة الخلف نفسها؛ ولا توجد ساعة عالمية تبدأ مع النشر.
  • يحتاج الانتقال القابل للمراجعة إلى ربط كائني TAK المتبادلين، وسجل المشاهدة، وتكافؤ المستودعين، والمفتاح المستخدم فعلاً، وتأخر TAL القديم، وإتلاف المفتاح السابق.

يمنح RFC 8630 المدقق مفتاح مرساة الثقة وعناوين شهادة السلطة داخل TAL. يمكن تجديد الشهادة مع بقاء المفتاح، أما استبدال المفتاح A بالمفتاح B فيغيّر نقطة بدء الثقة المحلية.

يعرّف RFC 9691 كائن TAK موقعاً. يذكر TAK تحت A أن B هو اللاحق، ويذكر TAK تحت B أن A هو السابق. وعلى المدقق أن يتحقق من B ومن TAK الخاص به، وأن يطابق مفتاحه الحالي مع اللاحق لدى A، وأن يطابق السابق مع A.

يثبت هذا الربط المتبادل مسار انتقال مقصوداً، لكنه لا يثبت أن مجتمع المدققات شاهده أو حافظ عليه أو اختار B للإنتاج.

لكل مدقق بداية مختلفة

يبدأ المدقق مؤقته عندما ينجح في التحقق من B ولم يكن B ظاهراً في تشغيله الناجح السابق. خلال المهلة يبقى A جذر التحقق العادي، ويُختبر B فقط. بعد انتهاء المؤقت المحلي واستمرار العلاقة الصحيحة، يمكن لذلك المدقق اعتماد B وإعادة التحقق منه.

إذا فشل B أو اختفى من TAK يُلغى المؤقت. وإذا تغير المفتاح أو مجموعة العناوين يبدأ عرض جديد. مدقق دائم التشغيل قد يبدأ فوراً، وآخر متوقف يبدأ لاحقاً، ومدقق بارد قد يبدأ بعد أشهر. تطبيق لا يدعم TAK يبقى مع TAL، وتطبيق يتطلب الموافقة اليدوية يكتفي بالتنبيه.

لذلك يجب تسجيل هوية المدقق وإصداره، وTAL المحلي، وبصمتي A وB، والعناوين، والتشغيل السابق، وأول نجاح، والإلغاءات وإعادة البدء، ووقت الانتهاء، والجذر المختار للإنتاج. عبارة «نُشر منذ ثلاثين يوماً» بلا صاحب للقبول.

يحذر RFC من سحب B ثم إعادته من دون تغيير. قد يفوت مدقق فترة الغياب ويحتفظ بمؤقته القديم فينتقل قبل غيره. تغيير عناوين B يجبر من يراه على بدء مؤقت جديد حتى لو بقي SubjectPublicKeyInfo نفسه. تاريخ المشاهدة جزء من القرار.

التوقيع لا ينسخ المستودع

أثناء التداخل، تحتفظ السلطة بـ A وB في دليلين مختلفين. ويجب أن تعطي شهادات CA وموارد IP وAS والتفويضات النتيجة نفسها من الجذرين، باستثناء TAK نفسه.

مع خادم نشر واحد، تجمع عمليات RFC 8181 للطرفين في طلب واحد. ومع خوادم متعددة قد يحدث فرق قصير. لا يكتمل إبطال شهادة أو تقليص موارد حتى تتحدث كل النقاط، ولا ينبغي إبلاغ الجهة التابعة بتوسعة قبل جاهزية الجذرين.

صحة TAK لا تثبت هذا التكافؤ. يلزم مقارنة الإسقاطات المتحققة تحت A وB: الموارد، التفويضات، الشهادات، manifests، CRLs وأجيال النشر. المطلوب تكافؤ المعنى، لا تطابق البايتات.

إزالة A قرار سلطة لا نتيجة مؤقت

المراحل الأربع هي: TAK لـ A وحده؛ إنشاء B والربط المتبادل؛ توزيع TAL لـ B مع إبقاء A للعملاء القدامى؛ ثم حذف مستودع A وإتلاف مفتاحه الخاص. اختبار المسار، وتغيير بيانات البدء، وسحب السلطة القديمة قرارات منفصلة.

يمكن استخدام عناوين مختلفة في TAL وTAK لتقدير قناة الوصول، لكن غياب الطلب لا يثبت الانتقال. قد يعني توقفاً أو تخزيناً مؤقتاً أو حزمة محدثة أو عدم دعم. شرح APNIC لعام 2025 ذكر أن سجلات الإنترنت الإقليمية تدرس التنفيذ ضمن برنامج NRO RPKI؛ وهو سياق تخطيط لا برهان انتشار.

بعد إزالة A لا يستطيع مدقق يعرف A وحده أن يتحقق بما يكفي ليتعلم B، ويحتاج إلى إصلاح محلي. وإذا فاتته أجيال متعددة فقد ينتظر ثلاثين يوماً لكل قفزة. إبقاء A دائماً يحفظ الاستمرارية ويحفظ أيضاً سلطة قديمة.

لا يعالج TAK اختراق المفتاح الحالي. من يسيطر على A يسيطر أصلاً على المواد الموقعة تحته. كما أن تحويل TAK موزع خارج القناة إلى TAL ينقل الثقة إلى الموزع إذا لم يكن متجذراً في سلطة موثوقة مسبقاً.

تحدد RFC 6487 وRFC 6488 وRFC 9286 وRFC 6481 الشهادات والكائنات والبيانات والمستودعات. ويظل RFC 9319 في طبقة لاحقة؛ نجاح انتقال الجذر لا يثبت تحميل المسارات أو وصول الحزم.

تدعم عقيدة Lu Heng مواصفة أولية صغيرة مع قرارات محلية معلنة. ويفصل نموذج طبقات الواقع بين الإعلان الموقع والحالة المنفذة ونتيجة الشبكة. أما أولوية الشيفرة العاملة فتجعل حالة المدقق المرصودة أقوى من التاريخ في التقويم.

المصادر