سؤال

أنا أعاني من السيناريو التالي:

  1. يتم إنشاء XML-message من جانب العميل وتوقيع رقميًا باستخدام Window.crypto.signtext Mozilla. بعد التوقيع ، يتم إرسال الرسالة والتوقيع عبر خدمة WebS (.NET) إلى الخادم. كل شيء على ما يرام حتى هذه النقطة.

  2. على الخادم ، يتم تضمين XML في حجة XML أخرى ، والتي يمكن الوصول إليها للجمهور. يجب نشر التوقيع أيضًا من أجل منح عدم التعبئة.

س: هل هناك خيار سلس لتحويل PKCS#7 المنفصل إلى XML-DIG (على سبيل المثال الوظيفة ضمن إطار .NET)؟

Q2: أم أنه من الممكن إنشاء XML-DIG من جانب العميل بالفعل دون استخدام المكونات الإضافية الخارجية؟

TNX لمساعدتكم!

الويس بولين

هل كانت مفيدة؟

المحلول

نظرًا لطبيعة كل من تنسيقات التوقيع الرقمي XML و PKCS#7 ، لا يمكن التحويل من واحد إلى آخر.

في تفسير مبسط للغاية ، التوقيع في PKCS#7 يحتوي التنسيق ، من بين أشياء أخرى ، بعض بنية بيانات محددة تسمى DigestInfo التي تحتوي على هضم البيانات و OID (معرف الكائن) ، وتم تشفيرها مع المفتاح الخاص للمستخدم. ال XML-dig ينطبق التنسيق على الخطوة الأخيرة من خوارزمية التشفير (مرة أخرى مع المفتاح الخاص للمستخدم) على قيمة بيانات مختلفة محسوبة من هضم بيانات XML الأصلية وبعض هياكل بيانات XML-DIG المحددة. لذلك ، نظرًا لأن كلتا القيمين المشفرتين لن يكونا متماثلين ، فمن الممكن فقط إنشاء توقيع XML-DIG من خلال توقيع البيانات باستخدام المفتاح الخاص للمستخدم ، والذي لن تتمكن من الوصول إليه (وبالتالي اسم الاسم الخاص).

من هذا التفسير ، الإجابة على سؤالك الأول هي "لا ، لا يوجد خيار سلس ، فهو غير ممكن على الإطلاق".

لذلك فإن الخيار الوحيد هو إنشاء XML-DIG مباشرة في جانب العميل. هذا غير ممكن باستخدام JavaScript القياسي ، وبالتأكيد ليس مع نافذة Firefox.crypto (التي تولد فقط توقيعات PKCS7 المنفصلة). في شركتي (www.isigma.es) ، نقوم بحل ذلك باستخدام Applet ، وهو حل شائع في صناعة التوقيع الرقمي (هناك العديد من الحلول التجارية وأيضًا مفتوحة المصدر). قد لا يكون ذلك خيارًا في حالتك ، إذا كنت لا تريد الإضافات المتصفح.

Capicom (المكون النشط/X المستند إلى Windows الذي قد تستخدمه في إعداد Microsoft) لا يولد أيضًا XML-DIG ، فقط CMS/PKCS7.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top