حصلت الخوارزمية على رقم، لا على سلسلة ثقة

الخلاصة

• يخصص RFC 9563 الرقم 17 لخوارزمية SM2 مع SM3 في DNSSEC، والنوع 6 لملخص SM3 في سجل DS، فأصبحت القيم ذات معنى محدد على السلك.
• الوثيقة Informational من Independent Stream وليست مواصفة Standards Track؛ وهي تقول صراحة إن IETF وIRTF لم تحللا ملاءمة الخوارزميات لهذا الاستخدام.
• بعد سجل IANA تبقى أدلة مستقلة على تنفيذ جهة التوقيع والتفويض وقدرة المدقق وسياسته والتحقق من التوقيع والنتيجة التي تصل إلى التطبيق.

يتلقى محلل DNS متحقق إجابة موقعة ويقرأ الرقم 17. لم يعد الرقم مجهولاً، إذ يحدد سجل IANA معناه. لكن البرنامج قد لا ينفذ SM2، أو قد لا يدعم ملخص DS الذي يستخدمه النطاق الأب، أو قد ترفض سياسته المحلية المسار. وحتى نجاح العملية الرياضية لا يبين من كان يحوز المفتاح الخاص. الرقم يفتح سلسلة التحقيق ولا يغلقها.

نُشر RFC 9563 في 4 ديسمبر 2024، ويحدد تمثيل SM2 وSM3 في DNSSEC. منح خوارزمية التوقيع الرقم 17 والاسم المختصر SM2SM3، ومنح SM3 النوع 6 في DS. وفي الوقت نفسه رسم حدود سلطته بوضوح: وثيقة Informational من Independent Stream، وليست ثمرة توافق مجتمع IETF. وتذكر أن IETF وIRTF لم تدرسا صلاحية SM2 أو SM3 لهذا الغرض، وأن نقاط ضعف مقصودة أو غير مقصودة قد تكون موجودة.

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

التخصيص يزيل الغموض ولا يزيل عدم اليقين

من دون رمز مشترك لا تستطيع تطبيقات مختلفة الإشارة بثبات إلى الخوارزمية نفسها في DNSKEY أو RRSIG أو DS. لذلك يحقق التخصيص قيمة حقيقية: يمنح التنسيق اسماً قابلاً للتشغيل البيني ويمنع تضارب التفسيرات الخاصة.

عند فحص سجل IANA في 27 سبتمبر 2026، كانت توصيات استخدام وتنفيذ الخوارزمية 17 للتوقيع والتحقق كلها MAY. وكان النوع 6 في سجل DS يحمل توصيات MAY أيضاً. هذه حقيقة مؤرخة عن حالة السجل، لا مسح انتشار ولا موافقة شراء ولا حكماً في التحليل التشفيري.

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

يوضح RFC 7841 كيف يبيّن رأس الوثيقة والنص القياسي مسار النشر والحالة. رقم RFC يحدد منشوراً ثابتاً، لكنه لا يمحو Independent Stream ولا ينشئ توافق IETF.

تحقق DNSSEC مسار كامل لا عملية منفردة

لا يقتصر DNSSEC على سؤال نجاح معادلة توقيع. يفرق RFC 4033 بين الخوادم السلطوية والمحللات المدركة للأمن ومراسي الثقة. ويحدد RFC 4034 سجلات DNSKEY وRRSIG وDS وإثباتات عدم الوجود. ثم يطلب RFC 4035 من المدقق بناء مسار توثيق: اختيار خوارزمية مدعومة، والعثور على المفتاح، وإعادة بناء البيانات المعيارية، وفحص فترة الصلاحية، والتحقق من التوقيع ضمن سلسلة مقبولة.

قد يقرأ المنتج الرقم 17 من دون القدرة على حساب SM2. وقد ينفذ SM2 ولا يقبل ملخص DS 6. وربما ينشر النطاق الابن DNSKEY بينما لا يقدم تفويض الأب سجل DS قابلاً للاستخدام. وحتى مع وجود كل البدائيات يمكن للسياسة المحلية رفض المسار.

يشرح RFC 6840 نتيجة مهمة: يُتجاهل ملخص DS غير المدعوم مثل خوارزمية DNSKEY غير المدعومة. وإذا لم يبقَ أي DS مدعوم فقد يُعامل التفويض على أنه insecure بدلاً من bogus. يكون النطاق موقعاً والسجل دقيقاً، ومع ذلك لا يملك هذا المدقق مسار توثيق يستطيع تنفيذه.

لهذا يحافظ RFC 8624 على توصيات الاستخدام والتنفيذ. تتطلب مرونة الخوارزميات فترة تداخل بين الموقّعين والمدققين. جدوله أقدم من RFC 9563، ولذلك لا يثبت الدعم الحالي للرقم 17 أو النوع 6. يجب قياس ذلك بحسب المنتج والإصدار ومكتبة التشفير والبناء والإعداد ومجتمع المحللات الفعلي.

التوقيع الصحيح يجيب عن سؤال محدود

يحدد RFC 9563 ترميز المفتاح العام والتوقيع اللازم للعملية. يبين نجاح التحقق أن بيانات DNS المعيارية تطابق التوقيع تحت مفتاح وقواعد ونافذة زمنية محددة. لكنه لا يثبت من سيطر على المفتاح الخاص، أو أن استخدامه كان مخولاً، أو أن تدوير المفاتيح حافظ على الاستمرارية، أو أن التطبيق قبل العنوان المعاد.

يتعامل RFC 7583 مع توليد المفتاح وتخزينه وتدويره واختراقه وسحبه كأعمال تشغيلية مستقلة. ويطلب RFC 9563 مرونة تشفيرية أيضاً: إذا ظهرت نقطة ضعف فقد يلزم تجديد DS وDNSKEY وRRSIG وNSEC3 مع مراعاة التخزين المؤقت. لا تنفذ خانة في السجل هذا الانتقال.

تربط سلسلة الأدلة السليمة بين مصدر الوثيقة وحالتها، والوضع الحالي في IANA، وبناء جهة التوقيع وإعدادها، وسجلات DNSKEY وDS وRRSIG المرصودة، وقدرات المحلل ومراسيه وسياسته، وسجل التحقق، واستمرارية التدوير، ونتيجة التطبيق. لكل إيصال حدود لا يجوز تجاوزها.

يعطي مبدأ Heng Lu عن أولوية الكود العامل قاعدة القراءة: السلطة الرمزية والنية المضبوطة والقدرة القابلة للتنفيذ والنتيجة المرصودة طبقات حقيقية منفصلة. جعل RFC 9563 من الممكن تسمية SM2 وSM3 بدقة داخل DNSSEC؛ أما ما حدث بعد ذلك فلا يثبته إلا النظام الذي عمل فعلاً.