Summary

  • مسودة شفافية شهادات STI، النسخة 05 وثيقة عمل نشطة لفريق STIR في مرحلة المراجعة النهائية لدى IETF حتى 5 نوفمبر 2026. تقترح تسجيل شهادات الهوية الهاتفية وإدراج طابع زمني موقّع من السجل، SCT، قبل إصدار الشهادة النهائية.
  • يَعِد SCT بإضافة الشهادة التمهيدية إلى شجرة السجل خلال مهلة دمج قصوى. يتحقق نظام المكالمة من توقيع PASSporT وسلسلة الشهادة وإيصال السجل دون سؤال السجل مباشرة على مسار الاتصال.
  • يفحص مراقب مستقل الإدخالات الجديدة، ويقارن TNAuthList واسم الجهة بقائمة الأرقام أو رموز مزودي الخدمة التي يتابعها. اكتشاف مطالبة منافسة لا يحسم وحده قرار الإلغاء أو تعديل قائمة الثقة.

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

تنقل المسودة بنية السجل القابل للتدقيق في RFC 6962 إلى هوية الهاتف. يحدد RFC 8226 امتداد TNAuthList الذي يحمل معلومات الأرقام ورموز المزودين، ويتناول RFC 9060 تفويض نطاقات الأرقام. تقدم جهة إصدار شهادات STI شهادة تمهيدية وسلسلة الوسطاء. يتحقق السجل من وصول السلسلة إلى جذر يقبله وينشر قائمته، ثم يعيد SCT ليُضمَّن في الشهادة النهائية.

الإيصال يسبق التحقيق

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

صُمم مسار المكالمة ليكون سريعاً. يجوز لخدمة المصادقة التحقق من SCT عند تفعيل الشهادة وتخزين النتيجة. أما خدمة التحقق التي تتلقى ترويسة Identity فتحقق توقيع PASSporT، وسلسلة الشهادة حتى جذر STI مقبول، وتوقيع SCT بمفتاح سجل موثوق. تمنع الفقرة 7.2 طلب إثباتات متزامنة من السجل أثناء المكالمة. بذلك لا تصبح سرعة السجل العام شرطاً لكل اتصال.

لكن السجل يتحقق من سلسلة الشهادة ويَعِد بنشرها؛ لا يملك بالضرورة قائمة الحقوق الجارية لكل رقم. على المراقب أن يحفظ عناوين السجلات ورؤوس الأشجار التي شاهدها وقائمة الأرقام أو رموز المزودين التي يحميها. يجلب القيود الجديدة، ويفك TNAuthList، ويقارن اسم الجهة، ويرفع إنذاراً حين يظهر مدعٍ غير متوقع. إذا نقصت قائمته رقماً، فقد يقرأ كل قيود السجل ولا يلاحظ النزاع الأهم لصاحب ذلك الرقم.

من يملك قرار إطفاء الشهادة؟

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

حتى واجهة البرمجة لا تدعي أكثر من إعادة استخدام معقولة. تحافظ العمليات على معنى /ct/v1/ في RFC 6962، وتوصي المسودة بمسار /stict/v1/ لتوضيح التشغيل. تغيير اسم المسار لا يحدد من يراقب كل سجل، ولا من يحدث قوائم الأرقام، ولا من يوقع قرار الإلغاء. تلك حدود السلطة الحقيقية.

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

مسودة STI CT · RFC 6962 · RFC 8226 · RFC 9060 · RFC 8224