الخلاصة

  • يضع تخطيط RIPE NCC الفصلي لخدمة RPKI، المحدث في 17 سبتمبر 2026، نقل لوحة الخدمة إلى OpenID Connect وتعديل مفاتيح واجهة البرمجة أولاً، ثم أعمال الامتثال والتدقيق. أما دعم قوائم الموارد الموقّعة RSC عبر API فمخطط له إذا سمحت طاقة الفريق، بحسب تقدّم البندين السابقين؛ ولا تُضاف واجهة مرئية إلا إذا ظهر طلب عليها.
  • اقترح تحديث موجه إلى فريق عمل التوجيه في مايو 2024 إصدار RSC عبر الواجهة واللوحة بعد ASPA، أو قبله إن تأخرت المرحلة النهائية للمعيار. ثم سجّل الأرشيف الطلب RPKI-2024#01 مسألةً قيد الدراسة. لا تثبت هذه النصوص موعد تسليم ملزماً فُوّت.
  • يحدد RFC 9323 كائناً يوقّع بصمات ملفات ضمن نطاق موارد IP أو ASN محدد، ويحظر توزيعه عبر مستودع RPKI العالمي. حتى لو صدرت واجهة توقيع مستقبلاً، يبقى تسليم الملف الموقّع والتحقق المستقل منه وقبول الجهة المستقبلة قرارات منفصلة.
  • لا تسند المصادر التي فُحصت القول بوجود واجهة RSC عامة عاملة لدى RIPE NCC الآن، أو تاريخ إطلاق، أو حادثة تشغيلية، أو ضرر لحامل موارد. تعرف مكتبة برمجية على الامتداد ليس دليلاً على توافر خدمة إصدار.

كلمة «مخطط» لا تكفي لتشغيل علاقة عميل

الفائدة المتوقعة مفهومة. عميل يريد أن يستخدم بادئاته لدى مزوّد جديد، فيطلب المزوّد ملفات أو تحدياً موقعاً. يمكن لقائمة RSC، التي قُننت عام 2022، أن تربط بصمات تلك الملفات بتوقيع صادر ضمن موارد رقمية معينة. يتأكد المتلقي من سلسلة الشهادات ومن أن البايتات التي وصلته هي نفسها التي شملها التوقيع. هذا أقوى من الاعتماد على صورة شاشة أو خطاب قابل لإعادة الإرسال، لكنه لا يقرر من يكون العميل قانونياً ولا يلزم المزوّد بتفعيل الخدمة.

قبل الوصول إلى ذلك السؤال التجاري توجد مسألة أبسط: هل لدى RIPE NCC مسار عام لإصدار القائمة؟ الخطة المنشورة حالياً تجيب بحذر. البند الأول يربط دخول المستخدمين في لوحة RPKI بنظام RIPE NCC Access عبر OpenID Connect، ويبدأ استبدال مفاتيح API القائمة بمفاتيح مرتبطة بنظام الدخول الموحد. البند الثاني يشمل ISO 27001 وتدقيقاً جديداً من نوع SOC 2 Type II بدأ في مايو. البند الثالث، RSC، يتوقف على تقدّم هذين العملين وعلى القدرة المتبقية لدى الفريق. البدء المقترح يكون بواجهة برمجية، أما واجهة المستخدم فلا تدخل إلا مع طلب يبررها.

قد يكون ترتيب الأولويات سليماً. فالجهة التي توقع كائناً باسم موارد رقمية يجب أن تضبط هوية طالب التوقيع ونطاق سلطته، وتحتاج خدمة الثقة إلى إجراءات قابلة للفحص. لكن سلامة الترتيب لا تحوّل البند الثالث إلى منتج. ليس في الخطة مواصفات طلب RSC أو تاريخ إتاحة أو طريقة استرجاع مضمونة. من يعد عميلاً اليوم بأن قبوله في السحابة سيعتمد على واجهة RIPE NCC هذه يحمّل العقد ما لم تقله الخطة.

كيف تغيرت الفكرة من دون أن نختلق إخفاقاً

في رسالة مايو 2024 إلى مجتمع التوجيه، استعملت RIPE NCC مثال توقيع تحدٍّ من مزوّد إلى صاحب بادئة. واقترحت أن تعمل على RSC في API ولوحة التحكم بعد ASPA، أو قبل ذلك إذا تعطلت الدعوة النهائية لمعيار ASPA داخل IETF. وبعد ذلك لم يسجّل الأرشيف «خدمة منجزة»، بل طلباً مجتمعياً معروف الاستخدامات تنتظر إمكاناته الدراسة ورداً أوفى.

لغة سبتمبر 2026 أضيق: تقدّم عملين آخرين، طاقة فريق، API محتملة، ثم قرار منفصل بشأن الشاشة. لا يجوز تحويل هذا التبدل إلى اتهام بتأخر عن عقد. الاقتراح القديم لم يحدد موعداً ملزماً، والنص الحالي لا يقول إن خدمة قائمة سُحبت. الذي تغير بالفعل هو مقدار ما يستطيع المطور استنتاجه من الوثائق. تصور «اللوحة والواجهة بعد ASPA» لم يعد يصلح بديلاً عن سؤال: ما الخدمة المعلنة والمتاحة الآن؟

توثيق واجهة إدارة RPKI يشرح إدارة سلطة إصدار شهادات LIR وROA بمفتاح وصول. لا يصف عملية عامة لإنشاء RSC. هذا حد لما يستطيع الطرف الخارجي بناءه اعتماداً على الوثيقة، لا برهان على خلو المختبرات الداخلية من التجارب. ويذكر سجل تحديثات rpki-commons خطوة أولى في عام 2024 للتعرف على امتدادات متصلة بـRSC. التعرف على نوع كائن داخل مكتبة لا يساوي إصدار ذلك الكائن لمستخدمين مع عقد تشغيل واضح.

أين يذهب الملف إذا لم يذهب إلى المستودع؟

تستعير RSC سلسلة شهادات RPKI، لكن لا ينبغي تصورها ROA ثانية تصل تلقائياً إلى جميع المدققين. تحتوي رسالة 2024 في بدايتها وصفاً عاماً يوحي بنشر القائمة داخل RPKI، ثم تصحح مسار التوزيع صراحةً: لا تُنشر القوائم في المستودع العالمي، بل يتبادلها الموقّع والمتحقق. يحسم RFC 9323 هذه النقطة تقنياً؛ فشهادة الكيان النهائي المخصصة للتوقيع الواحد لا تتضمن امتداد موقع المستودع، وتوزيع RSC عبر النظام العالمي ممنوع.

من هنا لا تنهي استجابة API ناجحة المسار. على صاحب الطلب أن يحصل على ملف .sig ويسلمه مع الملفات المقصودة إلى طرف محدد. وعلى المستلم أن يتحقق من المسار التوثيقي، ومن الموارد الداخلة في الشهادة، ومن خوارزمية البصمة وتطابق البايتات. بعد ذلك فقط ينظر في علاقته التعاقدية والعملية مع مقدم الطلب. لا تجعل القائمة مسار BGP صالحاً، ولا تمنح AS تصريحاً تلقائياً بإعلان بادئة.

إن قُدمت API قبل اللوحة، فقد تكون نافعة للفرق القادرة على الأتمتة. لكن عليها أن تعرف هوية المستدعي المخوّل، وحدود الموارد، وشكل النتيجة، وآلية التنزيل، والأخطاء، والعمر التشغيلي، وحالات اختبار تتحقق منها أدوات مستقلة. هذه معايير لفحص إصدار مستقبلي، وليست وصفاً لثغرة حاضرة. خطة RIPE NCC لم تنشر هذه التفاصيل بعد.

نتيجة صحيحة وحدود لا تتسع من تلقاء نفسها

ينبه RFC 9323 إلى أن بيانات القائمة من قول الموقّع نفسه. أقصى ما يستنتجه المتحقق من صحتها هو سيطرة كافية على سلطة الإصدار لإنشاء الكائن، لا الهوية القانونية للشركة أو صحة كل وثيقة أو ملكية مورد بوصفها حقاً مالياً. يورد أرشيف RIPE NCC عبارة عن «إثبات ملكية ASN» مثالاً على الاستخدام، لكنها ليست تفسيراً ملزماً للمعيار ولا حكماً في حقوق الأطراف.

تناولت مواد BTW سابقة الفرق العام بين سلامة البصمة والسلطة التجارية. زاوية هذه المقالة أضيق: ترتيب خدمة RIPE NCC، وحد الإطلاق الذي يبدأ من API، وواجب نقل الكائن خارج المستودع إلى متلقٍ يقرر بنفسه. حتى الآن، لا تُظهر الأدلة سوى أعمال هوية وتدقيق جارية، ومشروع RSC مشروطاً، وواجهة مرئية مؤجلة إلى حين ظهور حاجة. لا توجد حادثة RSC يمكن نسبتها أو مستخدم متضرر يمكن وصفه.

المصادر