الخلاصة

  • يحمي التوقيع signature base مكوّنة من حقول وعناصر مشتقة ومعاملات مرتبة ومعلنة. ويمكن تغيير method أو authority أو target أو credential أو body غير المدرج من دون كسر الحساب.
  • يختار verifier التوقيع الملائم والمفتاح المقبول، ويفرض الوقت ومنع replay، ويعيد حساب digest، ثم يربط principal بالمورد والفعل المسموحين. لا ينفذ keyid أو nonce هذه القرارات تلقائيًا.
  • إذا تحقق proxy من توقيع العميل ثم غيّر الرسالة ووقّعها من جديد، فقد أنشأ شهادة حيازة جديدة. توقيعه لا يجعل الحقول التي أضافها لاحقًا جزءًا مما قصده العميل.

جسم صحيح وصل إلى عملية لم تُوقّع

تستقبل منصة إدارية طلب POST يحمل توقيعًا صحيحًا. المفتاح معروف، والخوارزمية مسموحة، ووقت created حديث، وContent-Digest يطابق JSON المستلم. تعرض الشاشة نتيجة خضراء.

لكن Signature-Input لا يغطي سوى date وcontent-digest. يغيب @method و@authority و@target-uri وسياق التفويض والقيمة أحادية الاستخدام. قد يكون صاحب المفتاح وافق على تلك البايتات، لكنه لم يثبت أنها موجهة إلى هذا المضيف وهذا المسار وبهذه الطريقة ولهذا الحساب ولمرة واحدة.

يمكن نقل الجسم من endpoint للاختبار إلى endpoint للتنفيذ. ويمكن إعادة الطلب الملتقط داخل النافذة الزمنية. وقد يحوّل gateway الـauthority الخارجية إلى خدمة داخلية أخرى. يبقى التوقيع صحيحًا لأن المعنى الذي تغيّر لم يدخل أصلًا في الكائن الموقّع.

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

تبني RFC 9421 كائنًا دلاليًا لا صورةً خامًا للسلك

تمر رسائل HTTP عبر وسطاء يدمجون أسطر الحقول ويترجمون إصدارات البروتوكول ويضيفون سياق التوجيه ويغيّرون encoding. ولو وُقعت الصورة الخام للبايتات، لكسر proxy شرعي التوقيع.

لهذا تعرّف RFC 9421 signature base حتمية. يختار signer حقول HTTP أو عناصر مشتقة مثل @method و@authority و@target-uri و@status. يظهر ترتيبها في Signature-Input، ويربط @signature-params القائمة نفسها مع created وexpires وkeyid وnonce وtag.

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

لذلك لا يمثل توقيع عنصرين نسخة أضعف من توقيع عشرة عناصر؛ كل واحد يصف كائنًا مختلفًا.

قائمة التغطية هي سياسة العملية

لا تعرف المواصفة العامة ما الذي يغيّر معنى كل API. قد تحتاج القراءة إلى method وauthority وtarget. وقد يحتاج تغيير بنية تحتية إلى digest وهوية الحساب وإصدار المورد وidempotency key وتحدٍ من الخادم. أما الإيصال فيحتاج status وربطًا بطلبه الأصلي.

يجب أن يقارن التطبيق ما غُطي بالـprofile المحدد للطريقة والمسار. وجود Signature لا يفي بالشرط وحده.

من دون @method يمكن إرفاق موافقة على قراءة بطلب حذف. ومن دون authority وtarget تنتقل الرسالة بين services أو tenants. وإذا بقي حقل التفويض خارج القاعدة، فقد تُستبدل هوية بجوار توقيع سليم.

ولا يصح توقيع كل الحقول عشوائيًا. تتغير Via وForwarded بطبيعتها عند الوسطاء. يغطي التصميم الآمن كل ما يؤدي تغييره إلى تغيير السلطة أو الأثر، ويحدد صراحة ما يجوز لكل proxy موثوق تحويله.

يظهر هنا منطق Heng Lu في Minimum Initial Specification: الطبقة المشتركة تحدد البناء والتحقق بدقة محلية، بينما يبقى اختيار التغطية والمفاتيح والرفض مع المشاركين الذين يشغّلون النظام.

يدخل المحتوى عبر digest موقّع ومُعاد الحساب

لا تضع RFC 9421 محتوى arbitrary مباشرة في القاعدة. تقدم RFC 9530 Content-Digest. وتكتمل السلسلة بحساب الحقل، وإدخاله ضمن التغطية، والتحقق من التوقيع، ثم إعادة حساب digest على المحتوى المستلم.

إذا لم يُوقّع digest أمكن استبداله مع الجسم. وإذا وُقّع ولم يُعد حسابه أمكن إبقاء قيمته المحمية وتغيير الجسم. يحمي التوقيع الادعاء؛ وتربط إعادة الحساب الادعاء بالواقع.

كما يهم Content-Type وContent-Encoding. قد تعطي البايتات نفسها معنى مختلفًا لدى parser آخر، أو يتغير نطاق representation الذي يحسب عليه digest.

قد يسقط intermediary الـtrailer. وإذا نفذ التطبيق أثناء streaming قبل وصول digest، فقد سبق الأثر الدليل. يصلح ذلك لمعالجة قابلة للتراجع، ولا يصلح تلقائيًا لأمر نهائي.

تشرح مقالة BTW السابقة عن Digest Fields أي بايتات يسمّيها الملخص. أما هذه المقالة فتبحث من ربط ذلك الادعاء بالطريقة والهدف وصاحب السلطة. الحدّان متجاوران وليسا مكررين.

keyid عنوان بحث لا هوية موثوقة

يوفر signer قيمة keyid. لا تصادق السلسلة على نفسها. تترك RFC 9421 اكتشاف المفتاح والخوارزميات المقبولة وربط الهوية للتطبيق.

إذا قبل verifier أي public key يقدمه الطلب، يستطيع المهاجم توقيع أمره بمفتاحه والنجاح. تثبت الرياضيات حيازة private key؛ وعلى trust policy المحلية أن تثبت principal والدور والفترة ونطاق العملية.

يجب حفظ key version الفعلية، ومصدر الثقة وإصدار السياسة والخوارزمية وفترة التفعيل والسحب والصلاحيات. لا تكفي سلسلة keyid لإعادة بناء القرار بعد rotation.

يمكن استخدام dual signatures خلال الانتقال، بشرط وجود بداية ومقارنة وموعد retirement. أما التوافق المفتوح فيُبقي السلطة القديمة بلا نهاية.

يجعل تسجيل IANA الاسم قابلًا للتشغيل البيني، ولا يقرر ملاءمة الخوارزمية لحذف بيانات أو تحويل أموال.

الحداثة لا تمنع إعادة الاستخدام

يحدد created وقت إنشاء التوقيع، ويعبّر expires عن نهاية استعداد signer لضمانه. يختار verifier العمر المقبول وانحراف الساعة. وقد يبقى التوقيع صحيحًا حسابيًا لكنه قديمًا وفق السياسة.

لكن النافذة القصيرة تسمح بتكرار الطلب داخلها. الزمن لا يستهلك الأمر.

يحمل nonce قيمة مفردة، لكن على verifier تسجيل استخدامها ذرّيًا. قد ترى منطقتان في اللحظة نفسها أنها غير مستخدمة فتنتجان commitين. منع replay حالة موزعة لها scope ومدة حفظ.

يساعد tag في اختيار توقيع موجه إلى profile، لكنه علني ويمكن نسخه، ولا يمنح تفويضًا.

توقيع proxy شهادة أخرى لا امتداد لأمر العميل

تعد RFC 9110 الوساطة جزءًا طبيعيًا من HTTP. يمكن gateway التحقق من توقيع client، وحذف حقل خاص، وإعادة كتابة internal target، ثم توقيع الشكل الجديد.

يصف التوقيع الثاني ما يقر به gateway. ولا يثبت أن العميل وافق على الحقول المضافة لاحقًا. على origin تحديد إن كان proxy ينقل نتيجة التحقق فقط أم يملك سلطة العمل كـprincipal داخلي.

إن حفظ signature_valid=true في آخر hop يمحو provenance. يلزم الاحتفاظ بالسياق الخارجي، وتوقيع العميل المختار، والـprofile، والتحويل، والسياق الداخلي وتوقيع proxy.

عند الترجمة بين HTTP/1.1 وHTTP/2 تظهر authority في Host أو :authority. يمثّل @authority المعنى عبر النسخ. توقيع شكل wire واحد قد ينكسر شرعيًا أو يجعل verification وauthorization يقرآن سلطتين مختلفتين.

تعدد التوقيعات يحتاج قاعدة اختيار

قد تحمل الرسالة توقيع client وgateway وapprover، أو خوارزميتين أثناء migration. يمكن أن تكون كلها valid ولا يكون أي منها كافيًا للعملية الحالية.

قبول أول توقيع ينجح يخلط توقيع audit بتفويض التنفيذ، أو receipt من proxy بأمر المستخدم. يختار label وtag المرشحين، ثم تفرض السياسة الدور والمفتاح والتغطية والسياق.

في response يسمح req بتغطية عناصر الطلب المرتبط. يجب أن يملك verifier الطلب الدقيق. وجود توقيع على سجلين منفصلين لا يثبت أن أحدهما نتيجة الآخر.

لا يلغي التوقيع TLS ولا قرار التطبيق

تحمي TLS 1.3 القناة وتوفر confidentiality. وتحفظ HTTP Message Signatures دلالات مختارة عبر connection أو بعض الوسطاء. لا تشفّر الرسالة ولا تستبدل TLS.

تقدم HTTP authentication credentials، ثم يقارن التطبيق principal والمورد والفعل والحالة. ولا تصبح response موقّعة صالحة للـcache تلقائيًا؛ يبقى ذلك تحت RFC 9111.

وفق Reality Layers لدى Heng Lu، signature base artifact للتنسيق، وverification حقيقة تشفيرية، وkey mapping ادعاء هوية، وauthorization قرار محلي، وcommit مع أثره واقع تشغيلي. لا تمنح دقة الطبقة الأولى سلطة على الطبقة التالية.

المصادر وحدود الدليل

تحدد المصادر التنسيق والحدود الأمنية. ولا تثبت نسبة الانتشار أو سلوك vendor بعينه أو هوية الإنسان أو الإرادة القانونية أو non-repudiation أو صحة القرار التجاري.