الخلاصة

  • يعرّف RFC 9881 استخدام الإصدارات النقية من ML-DSA، وهي ML-DSA-44 وML-DSA-65 وML-DSA-87، داخل شهادات X.509 وقوائم إبطال الشهادات.
  • معرفات الكائنات هي 2.16.840.1.101.3.4.3.17 لـ ML-DSA-44، و2.16.840.1.101.3.4.3.18 لـ ML-DSA-65، و2.16.840.1.101.3.4.3.19 لـ ML-DSA-87. وفي AlgorithmIdentifier يجب أن يكون مكوّن parameters غائباً، لا أن يكون موجوداً بقيمة NULL.
  • يضع توقيع الشهادة أو CRL المعرّف في AlgorithmIdentifier، بينما يحمل الحقل signatureValue توقيع ML-DSA الخام على البنية الموقعة المشفّرة بترميز DER؛ ويظل نص السياق الاختياري فارغاً.

المشكلة العملية ليست اسم ML-DSA وحده. فقد يعلن المُصدِر والمتحقق دعمهما للخوارزمية نفسها، ثم تفشل السلسلة لأن أحدهما أرسل parameters بقيمة NULL، أو لأن الطرف الآخر فسّر حاوية مفتاح خاص بحسب طولها بدلاً من وسم ASN.1. لذلك يصبح العقد الحقيقي سلسلة من البايتات والقواعد: معرّف دقيق، وغياب مقصود، وتمثيل لا يضيف غلافاً غير مسموح، وسلوك رفض يمكن التنبؤ به.

هوية الخوارزمية في الشهادة

في AlgorithmIdentifier الخاص بتوقيع الشهادة أو CRL، يكون OID هو الذي يميز مستوى ML-DSA، وتبقى parameters غائبة. هذه ليست طريقة مختصرة لقول “لا توجد معلومات إضافية”، بل جزء من الترميز المطلوب. إدراج NULL قد يجعل مُحلِّلاً متسامحاً يقبل الكائن، لكنه لا يحوّله إلى تمثيل مطابق، ولا ينبغي أن يُبنى ملف إصدار يعتمد على هذا التسامح.

يطبق التوقيع على البنية الموقعة بعد ترميزها بترميز DER، وتوضع قيمة التوقيع الخام في signatureValue. أما context string الاختياري فيبقى فارغاً. ومن ثم فإن تغيير حدود DER أو تمرير سياق غير فارغ ليس تحسيناً محلياً؛ بل يغير المدخل الذي يتحقق منه الطرف المقابل.

المفتاح العام والاستعمال المسموح

يحمل SubjectPublicKeyInfo سلسلة بايتات مفتاح ML-DSA العامة الخام، من دون غلاف ASN.1 إضافي داخل BIT STRING. يبلغ حجم المفتاح العام 1312 octets لـ ML-DSA-44، و1952 octets لـ ML-DSA-65، و2592 octets لـ ML-DSA-87. هذه الأحجام أدوات تحقق من التمثيل، لكنها لا تبرر استنتاج النوع من الطول وحده في كل سياق؛ فالهوية الأساسية تأتي من OID وبنية الحاوية.

عند وجود keyUsage، يجب أن يكون بت واحد على الأقل من البتات المتعلقة بالتوقيع مضبوطاً، ولا يجوز ضبط بتات التشفير أو اتفاق المفاتيح لمفتاح ML-DSA. وهذا يربط قدرة المفتاح بالوظيفة التي يصفها ملف PKIX، بدلاً من ترك اسم الخوارزمية يبرر استعمالاً أوسع من اللازم. هذه قاعدة معيارية من RFC 9881 وRFC 5280، وليست ادعاءً بأن كل منتج يطبقها بالفعل.

المفتاح الخاص ليس رقماً بطول ثابت

يمكن أن تحتوي OneAsymmetricKey على seed، أو expanded key، أو كليهما. وتوصي المواصفة بصيغة seed-only عندما يكون تخزين أصغر مناسباً. لكن البدائل لا تُعرَف بتخمين الطول: يجب على المحلل استخدام وسوم ASN.1 الصحيحة للتمييز بين الخيارات. وجود seed وexpanded key معاً يتيح فحص اتساق إضافياً؛ فإذا كشفت المراجعة أن المفتاحين لا ينتميان إلى المادة نفسها، فيجب رفض المفتاح الخاص باعتباره مشوهاً، لا اختيار أحدهما بصمت ولا محاولة إصلاحه.

وتضع المواصفة حدوداً مهمة للتوافق. فـ HashML-DSA لا يجوز استخدام معرفاته في بروتوكولات PKIX المشمولة هنا؛ الاختيار هو pure ML-DSA، مع إبقاء السياق فارغاً. كذلك فإن ML-DSA ليس متوافقاً مع خوارزمية Dilithium السابقة للتوحيد. لذلك لا يكفي استبدال اسم في سجل خوارزميات أو افتراض أن تنفيذ Dilithium القديم سيقرأ هذه الشهادة بأمان.

ما هو مصدر وما هو تحليل؟

العبارات الخاصة بالمعرفات، وغياب parameters، وترميز signatureValue، والبايتات الخام وأحجام المفاتيح، وkeyUsage، وبدائل OneAsymmetricKey، وفحص الاتساق، وحدود HashML-DSA وDilithium، مستندة إلى RFC 9881 وFIPS 204 وRFC 5280 كما هو مبين في المصادر أدناه. أما اقتراح اعتماد اختبارات بايتية، وتسلسل إصدار مضبوط، وقياس حالات الرفض، والتنسيق بين المُصدِرين والمتحققين، فهو تحليل تشغيلي في هذا المقال، وليس متطلبات ينسبها النص المعياري إلى المشغلين.

المصادر