الخلاصة

  • غطّت SignatureValue الصيغة القانونية من SignedInfo، وربطت مراجعها بملخصات كائنات البيانات بعد سلسلة مرتبة من التحويلات.
  • لم يثبت نجاح التحقق الأساسي أن شجرة XML كلها موقعة، أو أن المستخدم رأى الشكل المحمي، أو أن KeyInfo موثوق، أو أن كل عنصر داخل Manifest فُحص، أو أن الإجراء مفوّض.

نُشرت RFC 3075 في مارس 2001 عن مجموعة XMLDSIG لتوقيع بيانات XML وغيرها. أمكن أن يكون الكائن داخل التوقيع، أو يحيط التوقيع به، أو يوجد في مورد منفصل. هذه المرونة خدمت بنية الويب، لكنها جعلت حدود التوقيع نتيجة لمسار معالجة لا لحواف الملف الظاهرة.

تحققان صنعا النتيجة الأساسية

في تحقق المرجع يحصل البرنامج على كائن كل Reference داخل SignedInfo، ويبني مدخل الملخص، ثم يقارن القيمة المحسوبة مع DigestValue. وفي تحقق التوقيع يحوّل SignedInfo إلى صيغته القانونية ويفحص SignatureValue بالمفتاح والطريقة المحددين.

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

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

مخرج التحويل هو الكائن الموقع

استطاع XPath اختيار جزء من الشجرة، وXSLT إنشاء تمثيل جديد، وفك Base64 استعادة بيانات ثنائية، والتحويل القانوني تسلسل مجموعة عقد. حُسب الملخص بعد هذه الخطوات، وما حُذف قبلها لم تحمه قيمة التوقيع.

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

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

ثبّت الشكل القانوني الحساب لا المعنى

تطبّع محللات XML نهايات الأسطر والصفات، وتوسّع الكيانات، وتنقل تعريفات فضاءات الأسماء إلى العقد. ويفقد DOM وSAX بعض خصائص النص الأصلي. قدّم التحويل القانوني تسلسلاً ثابتاً كي يحسب الموقّع والمتحقق على المدخل نفسه.

لكنه لم يثبت صحة schema أو تطابق العرض المرئي أو سلطة فضاء أسماء أو عدم أهمية عقدة مستبعدة. حافظ Canonical XML 1.1 لاحقاً على الحد نفسه: المساواة الخاصة بتطبيق ما ليست نتيجة تلقائية للصيغة القانونية العامة.

ما رآه الفاعل يجب أن يلتقي بما وقّعه

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

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

لم تجعل RFC من ذلك إثباتاً تلقائياً لهوية بشرية أو موافقة قانونية. ربطت مفتاحاً ببايتات مرجعية، وتركت معنى البيانات وعلاقة المفتاح بالمؤسسة وسياسة التفويض للتطبيق.

KeyInfo دلّ على المفتاح ولم يمنحه السلطة

أمكن لـ KeyInfo الاختياري حمل مفتاح عام أو شهادة أو اسم أو طريقة استرجاع. ويمكن حذفه إذا عرف التطبيق المفتاح من سياقه. وهو خارج SignedInfo في البنية الأساسية؛ وإذا أُريد تثبيت محتواه أمكن إدخاله عبر Reference مستقل.

حتى عند تثبيته، لا تكتمل الثقة. قد تكون الشهادة أصلية ولا تخوّل الفعل، وقد يكون اسم المفتاح مجرد فهرس محلي. كانت RFC 2807 قد تركت دلالات الثقة والادعاءات العامة خارج قلب مواصفة التوقيع.

توقيع Manifest لم يكن إيصالاً لكل عضو

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

إذن أصالة القائمة لا تساوي نجاح كل بند. يلزم سجل يبين أي الأعضاء جُلب وحُوّل وقورن. لا يجوز أن يحل إطار خارجي أخضر محل نتائج العناصر.

ضيقت الممارسة اللاحقة مساحة التنفيذ

حلّت RFC 3275 محل RFC 3075 في مارس 2002 بعد خبرة التشغيل البيني وغيرت بعض البنى. ثم أبقت XML Signature 1.1 وممارسات W3C على النموذج، وأضافت ضوابط أوضح: صادق على SignedInfo قبل تشغيل المراجع الخطرة، وأثبت الثقة بالمفتاح على نحو مستقل، وقيّد XPath وXSLT وRetrievalMethod وعدد التحويلات وURI الخارجية، وتأكد من أن العناصر التي يستخدمها التطبيق مشمولة فعلاً.

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

تُستخدم هنا كتابتا Lu Heng اللاحقتان عن أولوية الكود العامل وطبقات الواقع كعدستين معلنتين، لا كقول لمؤلفي RFC. تساعدان على فصل البنية والبايتات المنفذة والنتيجة التشفيرية والعرض والثقة والأثر. وكانت RFC 3075 نفسها قد وضعت القاعدة: دقة التوقيع تأتي من تحديد سلطته لا من توسيعها لغوياً.

المصادر

لم يكتب Lu Heng أو يقر RFC 3075 أو RFC 3275 أو توصيات W3C. تُستخدم مقالتاه كإطارين تحليليين لاحقين ومعلنين.