الخلاصة

  • يثبت توقيع PKCS#10 امتلاك مفتاح الطلب؛ أما BPKI فيوثّق الممثل ويربط الطلب بسجل عضو AFRINIC.
  • لا تصدر شهادة RPKI إلا إذا كانت الموارد المطلوبة جزءاً من الموارد المسجلة للعضو، لكنها لا تشهد علناً بهوية المؤسسة أو الفرد.
  • تفوض ROA الصحيحة رقماً مستقلاً لإعلان بادئات محددة؛ ولا تثبت إعلاناً جارياً أو قابلية الوصول أو سلامة المسار أو قبول الشبكة.
  • يستطيع إيصال منشأ أن يحفظ الإصدارات والبصمات والقرارات والأوقات من دون نشر وثائق الهوية أو جهات الاتصال الخاصة أو بيانات الدخول.

الاسم غير المقروء حد وظيفي مقصود

ينص بيان ممارسات التصديق لدى AFRINIC على أن اسم موضوع شهادة المشترك قد يولده المُصدر ولا يلزم أن يكون ذا معنى بشري. فالشهادات تستخدم للتفويض دعماً لأمن التوجيه، لا للتعريف بالهوية. وباستثناء السجلات، لا تشهد بهوية المؤسسة الحائزة للموارد ولا بهوية الفرد.

وتكرر صفحة تصديق الموارد أن شهادات الموارد ليست شهادات هوية. وظيفتها تمكين تطبيقات متخصصة من التحقق من حق استخدام عنوان IP أو رقم نظام مستقل. يحتاج المدقق العام إلى علاقة المفتاح بالموارد، لا إلى مستندات خدمة العضو.

سبعة أحكام مستقلة خلف كلمة «صحيحة»

أولاً، يوقّع طلب PKCS#10 بالمفتاح الخاص المقابل للمفتاح العام المطلوب. هذا يثبت حيازة المفتاح، لا صفة الممثل ولا الموارد.

ثانياً، لا يطلب شهادة RPKI إلا شخص يحمل شهادة BPKI من AFRINIC. ثالثاً، تربط شهادة BPKI الطلب بقاعدة الأعضاء التي تحتفظ بسجلات تخصيص الموارد.

رابعاً، تقارن AFRINIC المجموعتين ولا تصدر الشهادة إلا إذا كانت الموارد المطلوبة جزءاً من المسجل. خامساً، يفرض RFC 6487 امتدادات لموارد IP أو AS ومساراً تشمل فيه موارد المصدر موارد الشهادة التابعة.

سادساً، تعرّف RFC 9582 ROA باعتبارها تفويضاً لرقم AS كي يكون أصل مسارات بادئات محددة وبأطوال قصوى معينة. سابعاً، تستخرج RFC 6811 أصل المسار من إعلان BGP مستلم وتقارنه بحمولات ROA المدققة.

لا تتحول خطوة صحيحة إلى الخطوة التالية. حيازة المفتاح لا تمنح صفة ممثل؛ وBPKI لا يوسع الموارد؛ والشهادة لا تختار أصل المسار؛ وROA لا تبث مساراً؛ وحالة Valid لا تفحص AS_PATH كاملاً ولا تلزم أي شبكة بقبول المسار.

BPKI هو الوصلة الخاصة خلف الكائن العام

غياب اسم الشركة لا يعني غياب الضوابط. يضع البيان تعريف الممثل وتوثيق الطلب في BPKI، وحالة الموارد في سجل العضو، وحد التفويض في اختبار الجزء من المجموعة. ثم تنشر شهادة RPKI النتيجة اللازمة للطرف المعتمد فقط.

يتفق ذلك مع RFC 6480: توفر RPKI تفويضاً لا توثيق هوية، ولا ينبغي أن يدعي الاسم المميز وصف هوية الشخص أو المؤسسة. ويمكن أن يبقى الاسم مرجعاً يعيد المصدر إلى سجله الداخلي.

لكن سجل العضو يظل سجلاً تشغيلياً لـAFRINIC. يدعم قرار الإصدار، ولا يصبح حكماً قضائياً أو تفويضاً مؤسسياً أو سند ملكية قانونياً.

ROA تعطي إذناً وBGP يسجل حدثاً

توضح RFC 9582 أن بنية التحقق من ROA تقدم التفويض، لا توثيق الهوية ولا عدم التنصل. تعني ROA الصحيحة السماح بعلاقة ASN–بادئة. أما معرفة حدوث الإعلان فتحتاج إلى رصد BGP ذي مصدر ووقت.

حالات Valid وInvalid وNotFound ناتجة عن مقارنة المسار مع VRP وتدخل في سياسة محلية. وهي لا تثبت المسار كله. تحدد صفحة TAL لدى AFRINIC مدخل مرساة الثقة، لكن إعادة إنتاج النتيجة تحتاج أيضاً إلى حالة المستودع والبيان وCRL وROA وعينة BGP في ذلك الوقت.

إيصال تفويض يحفظ الخصوصية

الاقتراح التحريري هو إيصال منظم. في جانب السجل: وقت الطلب، بصمة المفتاح، مرجع BPKI أو دور غير سري، نتيجة التوثيق، إصدار أو بصمة سجل العضو، لقطة الموارد، المجموعة المطلوبة، قرار الاحتواء، ثم الرقم التسلسلي وSKI والامتدادات وفترة الصلاحية.

وفي جانب التحقق: نقطة النشر والبيان وCRL وTAL والوقت. ولـROA: شهادة EE وASN والبادئات وmaxLength وبصمة الكائن والنتيجة. ولأصل المسار: مصدر BGP والوقت ونقطة الرصد والبادئة والأصل المرصود ونتيجة المقارنة.

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

المصادر