الخلاصة

  • kid في COSE قيمة غير منظمة وغير فريدة تساعد في تضييق مجموعة المفاتيح المرشحة، وليست بصمة مفتاح أو هوية جهاز أو تفويضاً.
  • السجل القابل للمراجعة يحفظ نطاق البحث وكل المرشحين وبصمة المفتاح الذي نجح فعلاً والبايتات الموقعة وربط الهوية وسياسة التفويض ونتيجة التطبيق كأدلة منفصلة.

تصل رسالة COSE_Sign1 إلى متحقق صغير، وتحمل ترويستها غير المحمية kid = 0x19. يعيد المخزن مفتاحين: مفتاحاً قديماً ما زال موجوداً أثناء التدوير، وآخر أُعد في نطاق عميل مختلف. يفشل الأول وينجح الثاني.

إن كتب السجل «نجح 0x19»، فقد حذف السؤال الذي أجابت عنه العملية. لا يظهر أي مخزن استُخدم، ولا مجموعة المفاتيح المتاحة، ولا المفتاح الناجح، ولا السياسة التي سمحت بالتصرف بعد التحقق. تحولت إشارة بحث إلى اسم للفاعل.

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

القيمة القصيرة ترشح ولا تحكم

تحدد RFC 9052 البنية الحالية لـCOSE وخطوات معالجتها. تمنح جدولتها الحقل kid الوسم الصحيح 4 ونوع سلسلة بايتات. ويمكن مطابقة قيمته مع عضو kid في COSE_Key أو مع حقل مماثل تحدده طريقة توزيع أخرى للعثور على المفتاح المطلوب.

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

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

يحافظ سجل IANA الخاص بـCOSE على المعنى الضيق: kid هو معرّف مفتاح من نوع bstr عند الوسم 4. ويسجل أيضاً kid context كحقل مستقل. لا يلزم كل تطبيق باستخدام السياق، لكن الفصل يبين أن القيمة ومجال تفسيرها ليسا شيئاً واحداً.

السماح بعدم الحماية يرسم الحد

يحمل كائن COSE مجموعة ترويسات محمية وأخرى غير محمية. تدخل الأولى في البناء الموثق تشفيرياً. تنتقل الثانية مع الكائن من دون أن تكتسب تلك الحماية لمجرد وجودها. وعلى الواجهة أن تبقي الفرق مرئياً.

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

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

للتوقيع موضوع محدد بالبايت

تبني COSE للتوقيع Sig_structure من سياق التوقيع، ومعاملات الجسم المحمية، ومعاملات الموقّع المحمية عند وجودها، والبيانات الموثقة الخارجية التي يزودها التطبيق، والحمولة كاملة. ويصبح ترميز هذه العناصر ToBeSigned الذي يمر إلى الخوارزمية مع المفتاح والتوقيع.

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

عبارة «التوقيع صحيح» تخص هذه المجموعة الدقيقة. ولا تمد مظلتها إلى كل حقل تعرضه الشاشة بجوارها. إذا جاء kid من الترويسة غير المحمية، فلا يجوز أن يوحي لون واحد بأنه كان ضمن التوقيع.

بعد نجاح الرياضيات تبدأ الهوية والصلاحية

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

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

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

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

حتى ACE لا يحول الفهرس إلى إذن

تترك RFC 9052 لملف التطبيق اختيار أنواع الرسائل والخدمات والمعاملات والخوارزميات ووسيلة التفاوض. توفر COSE آلة تشفير مشتركة، فيما يحدد البروتوكول المستخدم قواعد الهوية والتفويض.

تطبق RFC 9200 OAuth في البيئات المقيدة. وفي مثال لاستجابة خادم تفويض تحتوي COSE_Key لإثبات الحيازة، تقول إن kid لا يستخدم إلا لتبسيط فهرسة المفتاح واسترجاعه، ولا ينبغي افتراض تفرده في نطاق العميل أو Resource Server.

حتى في بروتوكول تفويض يظل الحقل أداة بحث. ويجب أن يضيف السجل اسم الملف وإصداره، وخادم التفويض أو المصدر، والعميل، والجمهور، وResource Server، وقيود المفتاح، ونتيجة السياسة.

مكان Schaad في الوثيقة محدود بالدليل

ألّف Jim Schaad مواصفة COSE الأصلية المنشورة سنة 2017، RFC 8152. وحلت RFC 9052 لاحقاً محل قسم البنية والمعالجة، بينما فصلت الخوارزميات في RFC 9053؛ كما يسمي ترويس RFC 9052 المؤلف J. Schaad. ويضع ملف Jim Schaad في IETF Datatracker هذه الوثائق ضمن سجل أوسع.

هذه وثائق توافقية لـIETF وليست أوامر شخصية. ولا تثبت صفة المؤلف نشر أي تنفيذ أو سلامته. وتوفر مادة Oregon Wine Press التذكارية الصورة العامة المنسوبة التي استُخدمت لضبط هوية الرسم التحريري المرافق؛ مشهد مصنع النبيذ ليس دليلاً تقنياً.

المرشح الخاسر جزء من التفسير

يبدأ السجل بهاش كائن COSE المستلم ونوعه وترويساته المحمية وغير المحمية وبياناته الخارجية ومرجع حمولته. ويسجل البحث منفصلاً مع نطاقه وإصدار المخزن ووقته وقيمة kid الأصلية وكل المرشحين.

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

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

المصادر