الخلاصة

  • تثبت بيانات الاعتماد المفوّضة الصالحة صلاحية محدودة لمصادقة اتصال TLS أو DTLS 1.3 متوافق في إطار شهادة الكيان النهائي الأصلية.
  • ولا تثبت السيطرة على النطاق أو سلطة إصدار الشهادات أو الهوية القانونية أو تفويضًا له قناة إلغاء مبكر مستقلة.

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

تعرّف RFC 9345 آلية أضيق. يوقّع صاحب الشهادة بنية تحتوي على مفتاح عام وخوارزمية توقيع وفترة صلاحية قصيرة. يستطيع الطرف المتوافق إنهاء الاتصالات من دون تسلّم المفتاح الخاص طويل الأجل للشهادة. ويربط التوقيع بيانات الاعتماد بالشهادة النهائية كاملة وبسياق مصادقة العميل أو الخادم.

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

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

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

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

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

المصادر