المجال الرئيسي
الأمن
ضمن فئة المجال الرئيسي، تجمع تحليلات الأمن التقارير حسب المجال الأساسي ليتمكن القراء من متابعة مجال مركّز من مجالات البنية التحتية للإنترنت أو الحوكمة أو أسواق الاتصالات أو رأس المال الرقمي. وتضم الصفحة المقالات ذات الصلة والأدلة العامة والمؤسسات والشركات والأشخاص والانتشار الإقليمي والتبعيات التشغيلية وسياق السوق التي قد تكون موزعة عبر صفحات فئات منفصلة. وتشرح الصفحة المجال ونوع الجهات الفاعلة المحتملة وسياق السوق أو الحوكمة والمادة المصدرية التي ينبغي للقراء استخدامها عند مقارنة المؤشرات. ويمكن للمشغلين والمحللين والمهتمين بالحوكمة أن يروا كيف يظهر المجال نفسه عبر الأحداث والملفات الشخصية وتحولات السوق والأدلة المستقاة من المصادر العامة والتبعيات الإقليمية وقرارات البنية التحتية طويلة الأجل بمرور الوقت.
IETF
Rich Salz ومتطلب TLS 1.3 الذي لم يكن إيصال نشر
يمكن للمعيار أن يضع قاعدة حازمة من دون أن يصنع بنفسه دليلاً على أن القاعدة تحققت في كل نظام يعمل. ليس ذلك نقصاً في المعيار، بل حدٌّ يمنع تحويل قرار صحيح في تصميم البروتوكول إلى ادعاء غير مرصود عن النشر. يطلب RFC 9852، الذي شارك Rich Salz في تأليفه، من مؤلفي البروتوكولات الجديدة…
IETF
Nancy Cam-Winget وحدث SCIM الذي لم يكن إيصال تسوية
إبلاغ نطاق هويةٍ نطاقاً آخر بتغيّر ما لا يثبت أن الطرف المتلقي استوعب ذلك التغيّر. فما زال عليه أن يطابق المورد، ويوفّق بين المخططات، ويقرر إن كان يحتاج إلى استعلام عكسي، ويطبق قاعدته المحلية، ويراقب حالته الخاصة. يحفظ RFC 9967، الذي شاركت Nancy Cam-Winget في تأليفه، هذا الفصل…
IETF
Chris Wendt والاستجابة الموقّعة التي لا تُثبت مصدر الوسيط
في الاتصال الهاتفي، وصول استجابة ليس حكماً نهائياً في الهوية. قد يعرف المتصل عنواناً وصلت إليه الإشارة، لكنه لا يعرف من تلك المعلومة وحدها من يرسل الصوت لاحقاً، ولا من يملك صلاحية اتخاذ قرار القبول. يضيف RFC 9970، الذي شارك Chris Wendt في تأليفه، دليلاً محدداً إلى هذا المشهد من…
IETF
Michael Prorock ومعرّف الخوارزمية الذي لا يختار سياسة الثقة
يمكن لمعرّف خوارزمية واضح أن يجعل التحقق بين تنفيذين قابلاً للتكرار، لكنه لا يحوّل المفتاح إلى مصدر موثوق تلقائياً. فلا المعرّف يشرح كيف وصل المفتاح، ولا يختار جهة الإصدار، ولا يفسر الادعاء الموقّع، ولا يقرر الأثر الذي ينبغي أن يرتبه الطرف المعتمد. في RFC 9964، يضع Michael…
ملف القضية
وصل الرمز قبل المكالمة، لكن التحقق ظل ينتظر: RFC 9888
كان مزود الوجهة قد استلم بيان الهوية الموقّع، بينما لم تصل المكالمة المرتبطة به بعد. تفتح RFC 9888 مساراً خارجياً لأدلة STIR عندما يعجز SIP عن حملها من طرف إلى طرف، لكنها لا تمنح النظام حق دمج حدثين مستقلين بلا إثبات.
IETF
Dan Harkins ومفتاح الإقلاع الذي لا يثبت سلسلة حيازته بنفسه
إثبات أن جهازاً يملك مفتاحاً خاصاً لا يجيب عن السؤال السابق للمصافحة: من سلّم مفتاحه العام إلى الخادم، وبأي سجل، ومن يملك حق السماح للجهاز بالدخول؟ تجعل RFC 9966 هذا الحد واضحاً. فهي تبني برهان TLS ضيقاً حول مفتاح إقلاع، ولا تحوّله إلى سند حيازة أو قرار نفاذ.
ملف القضية
وُقّع الطلب، لكن حيازة المفتاح الخاص الآخر بقيت مجرد إقرار: RFC 9883
قد يثبت التوقيع الصحيح هوية صاحب الإقرار من دون أن يثبت تقنياً حقيقة ما أقر به. في RFC 9883 يوقّع مفتاح خاص سبق اعتماده طلباً جديداً، بينما تبقى حيازة مفتاح خاص مختلف لإنشاء المفاتيح ادعاءً تقبله سياسة جهة التصديق.
ملف القضية
ألزم RFC 9882 بكتابة SHA-512، لكنه لم يجعله جزءاً من كل توقيع
قد يكون الحقل في رسالة CMS صحيحاً وإلزامياً، ومع ذلك لا يصف العملية التشفيرية التي نُفذت فعلاً. يحوّل RFC 9882 هذه المفارقة إلى قاعدة تشغيلية واضحة: في أحد مساري ML-DSA يجب على الموقّع ذكر SHA-512 للتوافق، ويجب على المدقق تجاهل قيمة الحقل.
ملف القضية
حدّث RFC 9879 آلية MAC، لكنه لم يُحِل القارئ القديم إلى التقاعد
قد تعلن شاشتان نجاح استيراد ملف PKCS #12 نفسه، بينما تعني كل شاشة شيئاً مختلفاً. الأولى تحققت من PBMAC1 الجديد؛ والثانية لم تفهمه، فتجاوزت فشل التحقق ووصلت إلى مادة المفتاح المشفرة. وحّد RFC 9879 المسار الأول، لكنه لم يُلغِ إمكان المسار الثاني.
ملف القضية
حملت الحزمة شكلين، لكنهما لم يصبحا مفتاحاً واحداً بعد: RFC 9935
يمكن لحزمة مفتاح ML-KEM الخاص أن تضم البذرة المدمجة ومفتاح فك التغليف الموسّع معاً. يفيد ذلك التوافق، لكنه يخلق واجب إثبات: قبل إعادة الاشتقاق والمقارنة، لا يملك المستورد إلا قيمتين قابلتين للقراءة.
ملف القضية
سمّى OID حزمة المفتاح، لكنه لم يأذن باستخدامها: RFC 9939
ظهر في السجل نوع محتوى CMS معروف، واستطاع المحلل قراءة بنية PKCS #8. هذه حقيقة عن صيغة كائن وصل إلى النظام. ليست دليلاً على من يملك المفتاح الخاص أو من يحق له فكّه أو استعماله.
ملف القضية
سمّى المورد خادم التفويض، لكنه لم يمنح حقاً: حدّ الاكتشاف في RFC 9728
يمكن للمورد المحمي أن يدلّ العميل بدقة إلى موضع الخطوة التالية، من دون أن يسمح له بأي استدعاء لواجهة API. ميتاداتا RFC 9728 أداة لاكتشاف المسار وتنسيقه؛ ليست رمز وصول، ولا قرار قبول من خادم المورد، ولا دليلاً على أن عملية ما أنتجت أثراً.
ملف القضية
كانت محادثة التفويض ما تزال معلّقة، ولم تكن حقاً في واجهة API: حدّ الاستمرار في GNAP
قد يُسمح للعميل بمتابعة محادثة تفويض من دون أن يُسمح له باستدعاء واجهة API التي طلبها. تفصل RFC 9635 بين الأمرين: فاعتماد الاستمرار يدفع طلباً واحداً إلى الأمام لدى خادم التفويض؛ أما حق المورد، إن نشأ، فلا يظهر إلا لاحقاً وبفحص مختلف.
IETF
Sean Turner وإثبات المفتاح الخاص الذي لم يمنح إذن إصدار الشهادة
يمكن لطلب شهادة أن يحمل توقيعاً صحيحاً من دون أن يملك صاحبه حق الحصول على الشهادة المطلوبة. فالتوقيع يثبت أمراً محدوداً عن المفتاح؛ أما الهوية والاسم والتعديل الوسيط وقرار الإصدار فلها أدلتها وسلطاتها المستقلة.
IETF
Panos Kampanakis وجلسة SSH ذات الإيصالات الأمنية الثلاثة
يمكن لاتصال SSH واحد أن يستخدم تبادل مفاتيح هجيناً مع ML-KEM، وأن يثبت الخادم هويته بمفتاح مضيف مستقل، ثم يسمح لمستخدم بالدخول اعتماداً على بيانات اعتماد أخرى. تجتمع القرارات في قناة واحدة، لكنها لا تتحول إلى ضمان واحد.
IETF
Bas Westerbaan: مصافحة TLS الهجينة لم تجعل الشهادة مقاومة للكمّ
في انتقال TLS إلى ما بعد الحوسبة الكمّية تعمل ساعتان مختلفتان. الأولى تخص خصماً سلبياً يخزن الحركة اليوم كي يفكها غداً، والثانية تخص خصماً نشطاً قد يزوّر هوية الخادم مستقبلاً. تعالج RFC 10024 جزءاً مهماً من الساعة الأولى، لكنها لا توقف الثانية تلقائياً.
IETF
Daniel Fett: صادقت MFA على المستخدم، لا على سياق رمز QR
لم يُدخل المستخدم كلمة المرور في موقع مزيف، ولم يتجاوز المهاجم العامل الثاني. وصل المستخدم إلى الخدمة الحقيقية وأكمل المصادقة الصحيحة ثم منح الإذن بنفسه. ومع ذلك ذهبت الصلاحية إلى جهاز المهاجم، لأن النظام أثبت هوية صاحب القرار ولم يثبت مصدر الطلب الذي وافق عليه.
ملف القضية
تحققت الشهادة من الطرف، وبقيت PSK الخارجية بحاجة إلى أمين: RFC 9973 وحدود السلطة في TLS
قد يقال بعد فحص اتصال ما إن الشهادة صحيحة وإن الـ binder سليم وإن TLS أنهى المصافحة. هذه حقائق نافعة، لكنها لا تجيب عن السؤال الذي يهم مالك المخاطر: من أنشأ السر الخارجي، ومن يستطيع نسخه أو استعادته أو عرضه، ومن قرر أن الطرف الموثق يجوز له تنفيذ الفعل اللاحق؟ لا ينبغي لنجاح…
ملف القضية
وصل الـCookie مع الطلب، لكنه لم يثبت قراراً: RFC 10025 والسلطة المحيطة
قد يمر طلب تغيير حساس عبر اتصال آمن، ويحمل Cookie لجلسة معروفة، ويستقبل استجابة ناجحة. تلك وقائع مهمة، لكنها ليست جواباً عن صاحب الإرادة، ولا عن بقاء الجلسة مقبولة، ولا عن صلاحية الفعل، ولا عن تحقق أثره. يوضح RFC 10025 كيفية احتفاظ المتصفح بحالة وإعادتها؛ ولا يحوّل تلك الحالة إلى…
ملف القضية
وصل النص المشفر إلى المفتاح، لكنه لم يسمِّ مرسله: RFC 9180 والسلطة الغائبة في نمط HPKE Base
قد يفتح حامل المفتاح الخاص رسالة HPKE بنجاح، من غير أن يعرف ذلك النجاح من أرسلها أو ما إذا كان مخولاً أو أن محتواها ما زال صالحاً للتنفيذ. يضبط RFC 9180 عملية تشفير محددة؛ أما الاسم والسياق والزمن والسياسة والأثر فتبقى مسؤولية التطبيق الذي يستخدمها.