الخلاصة

  • تضع RFC 9598 صندوق البريد ذي الجزء المحلي غير ASCII في SmtpUTF8Mailbox داخل otherName في X.509؛ أما الجزء المحلي المؤلف من ASCII فقط فيبقى في rfc822Name حتى لو كان النطاق دولياً.
  • يتحول النطاق إلى A-label وفق IDNA2008 وبحروف صغيرة، لكن لا يجوز طي حالة الأحرف أو تطبيق تطبيع Unicode أو خرائط التوافق على الجزء المحلي. بعد إعداد النطاق تُقارن العنوانات بايتاً ببايت.
  • تطابق الاسم إيصال لعملية مقارنة محدودة، لا برهاناً على صلاحية المسار أو قيود الأسماء أو الغرض أو السيطرة الحالية على الصندوق أو مسار SMTPUTF8 أو التفويض أو النتيجة.

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

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

تضع RFC 9598 حداً واضحاً لهذا التوسع. للنطاق إجراء إعداد منصوص عليه؛ أما الجزء المحلي فلا يملك قاعدة عالمية للتكافؤ. لذا تُطبَّق التحويلات على يمين علامة @ فقط، ويُحفظ ما على يسارها. التشابه البصري إشارة للفحص، وليس قاعدة للمطابقة.

فضاء أسماء واحد وتمثيلان متنافيان

يسجل RFC Editor وIETF Datatracker الوثيقة RFC 9598 معياراً مقترحاً نُشر في مايو 2024. وهي تحدّث ملف PKIX في RFC 5280 وتلغي RFC 8398.

يستوعب rfc822Name التقليدي صندوق بريد بصيغة ASCII، لكنه لا يمثل جزءاً محلياً دولياً. لذلك تستعمل المواصفة فرع otherName القابل للتوسعة من GeneralName وتعرّف SmtpUTF8Mailbox بالمعرف 1.3.6.1.5.5.7.8.9. ويثبت سجل IANA لأرقام SMI هذا التخصيص.

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

لهذا أثر مباشر في الجرد. الماسح الذي يبحث عن rfc822Name فقط لا يرى الأجزاء المحلية الدولية. والمُصدر الذي يضع جزءاً محلياً ASCII في SmtpUTF8Mailbox ينتج قطعة خارج العقد. أما المحلل الذي يمحو نوع GeneralName بعد القراءة فيفقد دليلاً موقعاً عن الشكل الذي حملته الشهادة فعلاً.

القيمة صندوق بريد للمغلف وليست عنوان عرض. لا تدخل فيها العبارة الوصفية ولا التعليقات ولا القوسان الزاويان. قيمة SmtpUTF8Mailbox هي UTF8String غير فارغة في ASN.1، ويُحظر وجود علامة ترتيب البايتات في ترميزها. تحدد RFC 3629 حد UTF-8، وتقدم RFC 6532 سياق رؤوس الرسائل الدولية.

للنطاق عقد إعداد محدد

يتبع جانب النطاق IDNA2008. توفر RFC 5890 مصطلحات A-label وU-label وLDH، وتحدد RFC 5891 تحويلات البروتوكول. وتطلب RFC 9598 أن تتوافق نطاقات البريد في شهادات X.509 مع IDNA2008، من دون تحويل الخرائط التي يناقشها الإطار إلى اختصارات محلية.

داخل SmtpUTF8Mailbox يُخزن وسم النطاق غير ASCII في A-label لا U-label. وتلتزم الوسوم ASCII بقيود NR-LDH. كما تظهر حروف A-label وNR-LDH في النطاق بحالة صغيرة. تمنح الشهادة بذلك صيغة مقارنة واحدة، فلا يحتاج مدقق المسار إلى الرجوع إلى عرض Unicode ثم التخمين من جديد.

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

هذا هو الإصلاح الرئيس قياساً إلى RFC 8398 التي كانت تسمح، بشروط، بـ A-label أو U-label. اختيار A-label دائماً في الشهادة لا يثبت أن كل جهة إصدار وكل تطبيق قد انتقل إلى السلوك الجديد، لكنه يجعل الناتج قابلاً للاختبار ويحدد موضع الخطأ عندما يفشل.

الجزء المحلي بايتات هوية لا مادة تجميل

ينتمي الجزء المحلي إلى إطار البريد الدولي في RFC 6530 وامتداد SMTP في RFC 6531. يُشفّر بـ UTF-8، لكن UTF-8 طريقة ترميز، وليس سجلاً عالمياً يقرر متى يكون صندوقان متكافئين.

لذلك تمنع RFC 9598 تحويل الجزء المحلي. لا طي لحالة الأحرف. لا تطبيع Unicode. لا خريطة توافق. بعد إعداد النطاق، يُقارن صندوق البريد الناتج أوكتيتاً بأوكتيت. وإذا كان الطرفان قيمتي SmtpUTF8Mailbox مشفرتين، فلا يحتاجان أي إعداد: التطابق الكامل للبايتات وحده يثبت التكافؤ.

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

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

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

قيود الأسماء تضبط جهة الإصدار لا صندوق البريد

يمثل rfc822Name وSmtpUTF8Mailbox فضاء أسماء بريدياً واحداً. وإذا كانت سلطة تصديق فرعية مقيدة بنطاق عبر قيود rfc822Name، فلا ينبغي أن يصبح otherName الجديد منفذاً للخروج من ذلك الحد.

تحدّث RFC 9549 قواعد PKIX الدولية بحيث تغطي قيود rfc822Name الشكلين. تعبّر شهادة CA عن قيد البريد بقيمة rfc822Name متوافقة مع IDNA2008 وفي صيغة A-label. يُحضّر نطاق الموضوع، ويُحذف الجزء المحلي، ثم يُجرى اختبار المضيف الدقيق أو لاحقة النطاق. ولا ينبغي استعمال قيد موجه إلى صندوق بريد واحد بعينه.

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

ولهذا يفصل سجل التحقق أربعة أقوال على الأقل: حملت القطعة نوع GeneralName والبايتات المتوقعة؛ نجحت مقارنة الصندوق وفق خوارزمية RFC 9598؛ نجح مسار الشهادة وقيود الأسماء تحت سياسة الثقة المختارة؛ قبل التطبيق الشهادة لغرض معلن. وحتى اجتماعها لا يثبت أن رسالة مرت في مسار قادر على SMTPUTF8.

التطابق لا ينقل رسالة ولا يمنح صلاحية

قدرة SMTPUTF8 سطح تشغيل مستقل. تسمح RFC 6531 لعُقد SMTP بإعلان واستعمال عناوين مغلف دولية. يمكن أن يتطابق اسم الشهادة بينما لا يدعم المرحّل التالي الامتداد. ويمكن أن تصل رسالة عبر مسار SMTPUTF8 من دون تقديم شهادة RFC 9598 أصلاً.

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

يحوّل مقال Lu Heng عن أولوية الشفرة العاملة الادعاء إلى اختبار. عبارة «ندعم RFC 9598» ليست نتيجة. النتيجة أثر يحفظ بايتات الشهادة، وخَرْج المحلل، والنطاق الخارجي قبل IDNA وبعده، والجزء المحلي غير المتحول، والمقارنة، والمسار، والقيود، وقرار السياسة، والفعل، والأثر.

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

المهمة القيادية هي حماية هذه الفواصل حين تطالب واجهة واحدة بإخفائها.

المصادر