الخلاصة

  • تقترح draft-cel-nfsv4-rpc-tls-othername-04، المؤرخة في 5 سبتمبر 2026، وضع هوية مستخدم RPC واحدة في otherName داخل subjectAltName لشهادة X.509. وهي Internet-Draft فردية، لا RFC ولا إجماعاً صادراً عن IETF ولا دليلاً على النشر.
  • عندما يطبق الخادم الآلية، تحل هوية الشهادة بعد التحقق والتفويض محل هوية AUTH_NONE أو AUTH_SYS الواردة في الترويسة. وإذا فشل الربط أو التفويض، يرفض بـAUTH_TOOWEAK ولا يعود إلى الترويسة.
  • الخادم غير الداعم، وكذلك الخادم الذي عطّل الميزة، يتجاهل الحقل ويعالج بيانات RPC المعتادة. ولا يستطيع العميل التفريق بين الحالتين، لذلك لا يثبت إصدار الشهادة أن التقييد نُفذ.

لنفترض أن جهاز نسخ احتياطي مُنح شهادة تقصر عمله على حساب backup. عند أول عقدة تخزين، لا تفيده كتابة UID مختلف في ترويسة RPC؛ فالخادم ينفذ الطلب باسم الحساب الموجود في الشهادة. وعند عقدة أقدم، ينجح توثيق TLS نفسه، لكن نوع الاسم الجديد لا يُفهم، فيعود UID الذي صرحت به الترويسة إلى دائرة القرار.

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

تنطلق المراجعة 04 من المسودة من حد تركته RFC 9289 عمداً. يوفر RPC عبر TLS السرية والسلامة وتوثيق الطرف النظير، لكنه لا يعيد تعريف هوية مستخدم RPC في كل استدعاء. لذلك تقترح المسودة أن تحمل شهادة العميل المستخدم المقصود، وأن يتحقق الخادم منه ويربطه بجلسة TLS، ثم يستعمله بدلاً من ادعاء أضعف يأتي مع كل طلب.

هناك ثلاثة تمثيلات. يحمل RPCAuthSys أرقام UID وGID. ويحمل GSSExportedName اسماً مصدّراً خاصاً بآلية GSS، ومنها صيغة Kerberos الموصوفة في RFC 4121. أما NFSv4Principal فيحمل صيغة user@domain الواردة في RFC 8881، ويعتمد على خريطة المالكين المحلية في الخادم.

ليست هذه الأشكال نسخاً متكافئة من جواب واحد. الأرقام تفترض اتساق قواعد المستخدمين والمجموعات، واسم GSS يفترض دعماً كاملاً للآلية، وuser@domain يفترض سياسة محلية للمجال. وإذا ظهرت أكثر من هوية squashing في الشهادة، فعلى الخادم رفضها. التوقيع على جوابين لا يزيل التعارض بينهما.

المنع الحقيقي هو منع الرجوع إلى الترويسة

يبدأ الخادم المطبق بالتحقق من مسار X.509 وفق RFC 5280 وقواعد RPC-with-TLS. ثم يقرأ هوية واحدة، ويحولها إلى مستخدم محلي، ويتأكد من أن الطرف الموثق مسموح له باستخدامها. قد تدخل في ذلك قوائم وصول مرتبطة بموضوع الشهادة، ونطاقات UID/GID، وقواعد المجموعات والمجالات، وسياسة الثقة بآليات GSS.

إذا نجحت السلسلة، تُربط الهوية بجلسة TLS. في كل طلب AUTH_NONE أو AUTH_SYS ضمنها، يتجاهل الخادم بيانات الهوية في ترويسة RPC المعرفة في RFC 5531. ولا يشمل ذلك RPCSEC_GSS، لأن سياق الأمان في RFC 2203 قد أثبت هوية مستقلة بالفعل.

مسار الفشل أهم من مسار النجاح. فالهوية المشوهة أو غير القابلة للربط أو غير المأذونة تؤدي إلى AUTH_TOOWEAK في الإجراءات غير NULL المعنية. وتحظر المسودة أن يستعين الخادم بعدها بهوية الترويسة؛ لأن هذا التراجع يعيد تحديداً السلطة التي كان يفترض أن تنتزعها الشهادة.

لكن هذا الواجب لا يصل إلى برنامج لا يعرف المواصفة. يشترط ملف الشهادة subject غير فارغ وSAN غير حرج، ويوضع المعنى الجديد في type-id داخل otherName. يستطيع تطبيق قديم أن يفهم امتداد SAN، ثم يتجاهل النوع الداخلي المجهول ويواصل العمل بسياسة الترويسة القديمة. ويعطي خادم حديث عطلت فيه الميزة النتيجة ذاتها، من دون إشارة تمكّن العميل من معرفة أيهما واجه.

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

المطلوب إيصال لكل عقدة، لا قائمة بالشهادات

سطح التحكم الفعلي يربط ملف إصدار الشهادة، والغرض منها، ومرساة الثقة، وإصدار برنامج العقدة، وحالة الميزة، ونطاق السياسة، وبيانات تحويل الهوية، ونمط RPC، والجلسة بعينها. تترك المسودة للخادم إمكان التطبيق على الخدمة كلها أو على export واحد أو على وحدة محلية أخرى. عبارة «المنتج يدعمها» لا تقول أين تعمل.

يمكن لموازن حمل أن يرسل جلسة إلى عقدة تستبدل UID، ثم يرسل التالية إلى عقدة تبقيه. ترد العقدتان بنجاح وتظل لوحة التوافر خضراء، بينما تتغير دلالة الصلاحية بين اتصال وآخر.

الإبطال جزء آخر من السلسلة وليس نهايتها. حيث يطبّق الحقل، تمنح الشهادة وصولاً على مستوى المستخدم، ولذلك تهم مدة الصلاحية وحداثة CRL أو OCSP. وتوصي المراجعة بفصل مراسي الثقة لهذه الشهادات عن الشهادات التي لا تفعل سوى توثيق طرف TLS. لكن استجابة إبطال حديثة لا تثبت قراءة OID، كما أن قارئاً صحيحاً لا يثبت صحة ربط المستخدم أو المجموعة.

تسجل المسودة أن مساهمين وصفوا تنفيذ FreeBSD لصيغة user@domain بأنه مكتمل. وتوضح الفقرة نفسها أن ذلك ليس تزكية من IETF، ولم يُتحقق منه مستقلاً، وليس فهرس منتجات، كما لا تُبلغ عن خبرة تنفيذية. تشرح RFC 7942 لماذا تفيد إفصاحات الشيفرة العاملة عملية المعايير، لكنها لا تحول إفادة المساهم إلى قياس لشبكة إنتاج.

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

لذلك ليس سؤال التدقيق: «هل تحتوي الشهادة على الهوية؟» بل: «أي عقدة أثبتت أنها استخدمت هوية الشهادة لهذه الجلسة ورفضت الجواب المنافس في الترويسة؟»

المصادر