الخلاصة

  • سجّل RFC 9734 المعرّف id-kp-imUri، أي OID 1.3.6.1.5.5.7.3.40، للشهادات التي يُقصد بمفتاحها توقيع بيانات هوية عميل مراسلة فورية، بدلاً من منحه غرض مصادقة TLS عاماً.
  • يصف EKU غرض المفتاح. أما معرّف الحساب فيوجد في subjectAltName، وتبقى سلسلة الثقة ومطابقة الاسم المتوقع والسيطرة الحالية والإبطال والتفويض قرارات مستقلة.
  • يربط MLS المفتاح العام في الشهادة بمفتاح توقيع LeafNode، لكن التطبيق وخدمة المصادقة يظلان مسؤولين عن اختيار المعرّفات المقبولة والتحقق منها.

يصل هاتف قديم إلى مجموعة عمل بعد أن أزيل من إدارة المؤسسة. الشهادة لم تنتهِ، والسلسلة صحيحة، وid-kp-imUri موجود. تعرض واجهة المصادقة عبارة «هوية موثقة»، بينما يسجل نظام الأجهزة أن الهاتف غير مسموح.

البيانتان لا تتعارضان. كل منهما يجيب عن سؤال مختلف، والخطأ يبدأ عندما تمنح المؤسسة السطر الأول سلطة السطر الثاني.

نشر RFC 9734 في فبراير 2025 غرض مفتاح موسعاً خاصاً بشهادات هوية عملاء المراسلة الفورية. قد لا ترغب المؤسسة في إصدار شهادة IM تحمل id-kp-clientAuth أو id-kp-serverAuth، لأن الغرض العام قد يسمح بقبولها في بروتوكول آخر. لذلك يوصي النص بعدم جمع هذين الغرضين مع id-kp-imUri.

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

الغرض والاسم ليسا حقلاً واحداً

يفصل RFC 5280 بين Extended Key Usage، الذي يحدد الأغراض المسموح بها للمفتاح العام، وSubject Alternative Name، الذي يربط هويات بموضوع الشهادة. تُشفّر هوية URI في uniformResourceIdentifier.

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

يعرّف RFC 3860 مخطط im: لعنوان INSTANT INBOX، ويوصي بإدراج URI الخاص بالموضوع في subjectAltName لعمليات S/MIME للمراسلة. كما يوضح أن الخدمة المجردة تفترض التسليم الموثوق ولا تقدم ضمان تسليم على طبقة التطبيق. صحة العنوان ليست إيصالاً بالوصول.

وفي XMPP، يحدد RFC 6121 JID للحساب أو المورد، لكنه يبقي تفويض عمليات مثل تعديل قائمة الاتصال مستقلاً. الاسم يحدد من يخضع للقاعدة؛ لا يمنحه كل فعل.

الرقم 40 إحداثية مشتركة، لا شهادة حسن سلوك

يسجل سجل SMI لدى IANA الرقم 40 باسم id-kp-imUri تحت فرع PKIX. يمنع ذلك أن تفسر مواصفتان الرقم نفسه بمعنيين مختلفين. لا يفحص السجل طلب شهادة بعينه أو حساباً أو جهازاً.

يجوز للمُصدر جعل EKU حرجة أو غير حرجة، ويجوز للتطبيق اشتراط الغرض المحدد. لذلك لا يقاس التنفيذ بعدد الشهادات التي تحمل OID فقط، بل بمسارات الرفض: هل تُرفض شهادة IM في مصادقة TLS للعميل والخادم؟ هل تُرفض شهادة TLS عامة عند مدخل يشترط غرض IM؟ هل يؤدي غرض حرج غير مفهوم إلى فشل صحيح؟

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

مسار PKI الصحيح لا يعرف الاسم الذي قصده التطبيق

يفحص مسار الشهادة التواقيع والفترات والمراسي والقيود والسياسات وKey Usage وEKU. لكنه لا ينشئ URI الذي توقعه المستخدم أو النظام.

يميز RFC 9525، في سياق هوية الخدمات، بين المعرّفات المعروضة في الشهادة والمعرّف المرجعي الذي يتوقعه العميل. هذه اللغة تمنع خلطاً شائعاً: وجود اسم صالح لا يثبت أنه الاسم المقصود.

قد تحمل الشهادة أكثر من URI. وقد يُعاد تعيين اسم مستعار أثناء صلاحيتها. وقد تغيّر قاعدة تطبيع غير موثقة معنى المقارنة. يحتاج سجل القرار إلى الاسم المرجعي، والأسماء المعروضة، وقاعدة المطابقة، ومرساة الثقة، والسياسة، والوقت، والنتيجة والسبب.

MLS يثبت صلة المفتاح ولا يكتب سياسة الحساب

يشترط RFC 9420 في X509Credential أن يطابق المفتاح العام للشهادة النهائية signature_key في LeafNode. تمنع هذه القاعدة تقديم شهادة ثم توقيع كائنات المجموعة بمفتاح غير ذي صلة.

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

يجب إبقاء أربعة إيصالات منفصلة: تطابق مفتاح الشهادة وLeafNode؛ قبول المسار والغرض؛ مطابقة URI المعروض للمتوقع؛ قبول العميل في مجموعة ودور وepoch معين. يسهم id-kp-imUri في الإيصال الثاني فقط.

وقد تستخدم أجهزة متعددة معرّف الحساب نفسه. ينبه RFC 9420 إلى أن معرّف التطبيق قد لا يميز العميل بصورة فريدة، وأن leaf index صالح داخل epoch بعينه. إذا فرّقت السياسة بين جهاز مُدار وهاتف شخصي وروبوت، فعليها الاحتفاظ بإحداثية جهاز مستقلة.

تتغير الحالة بعد الإصدار

يمكن تعليق الحساب أو فقد الجهاز أو انتهاء الوظيفة أو إزالة العضو فيما تبقى الشهادة والمفتاح قابلين للاستخدام.

يعرّف RFC 6960 حالات OCSP: good وrevoked وunknown. تعني good في الحد الأدنى أن شهادة بالرقم التسلسلي المطلوب، ضمن فترة صلاحيتها، ليست مسجلة كمبطلة. لا تثبت بالضرورة أن الشهادة أُصدرت أو أنها صالحة من كل وجه. وتحدد thisUpdate وnextUpdate وproducedAt الإطار الزمني للجواب.

يناقش draft-barnes-mimi-identity-arch-02، الذي يستشهد به RFC 9734، الشهادات القصيرة وOCSP وقوائم الإبطال كتدفقات منفصلة لهوية الاتصال من طرف إلى طرف. إنه مسودة جارية لا تثبت نشراً. لكنه يوضح حقيقة تشغيلية: الشهادة الساكنة لا تعدّل نفسها بعد تغير الحساب.

تحويل الشارة الخضراء إلى ملف قابل للتدقيق

عند الإصدار، احفظ URI المطلوب، وطريقة إثبات الحساب، والجهة، وإصدار السياسة، وإثبات امتلاك المفتاح، وsubjectAltName، وEKU، والرقم التسلسلي والصلاحية. عند التحقق، احفظ المرجع والأسماء المعروضة وقاعدة المطابقة والسلسلة والمرساة وقرار الغرض ومصدر الحالة وحداثتها وسياسة الفشل. في MLS، احفظ LeafNode وبصمة الاعتماد وقرار خدمة المصادقة والمجموعة وepoch والعميل وقاعدة القبول. أما التسليم فلا يثبت إلا ما رصدته طبقته.

يثبت النص وXML وسجل RFC Editor وفهرس التصحيحات وتاريخ IETF أصل الوثيقة، لا تطبيقها في منتج.

يسأل مبدأ أولوية الكود العامل لدى Heng Lu عن الفحوص التي نُفذت فعلاً. تحافظ المواصفة الابتدائية الدنيا على OID كتنسيق مشترك ضيق وتترك قرارات الحساب والقبول لمسؤوليات ظاهرة. ويمنع فصل طبقات الواقع دمج رقم مسجل وامتداد واسم وتفويض ونتيجة في حقيقة واحدة.

قوة RFC 9734 أنه يجعل الادعاء أصغر وأكثر دقة. لا ينبغي للواجهة أن تعيده إلى ادعاء هوية شامل.

المصادر