الخلاصة
- صدرت النسخة الخامسة من مسودة ملف CCF لإيصالات COSE في 23 سبتمبر، وفيها طلبا تسجيل لنوعي إثبات لم يردا في النسخة الرابعة.
- يطلب النص الرقم 2 لخوارزمية
CCF_LEDGER_SHA256، والوسم -1 لإثبات الإدراج والوسم -2 لإثبات الاتساق ضمن تلك البنية. - هذه أرقام مطلوبة لا مخصصة. سجل IANA المنشور يعرض البنية 1 وإثباتيها فقط، وحالة المسودة الجديدة تستدعي مراجعة أخرى.
يستطيع سجل عام أن يعطي بنية بيانات اسماً رقمياً، لكن الاسم وحده لا يخبر برنامج التحقق كيف يفك إثباتاً أُرسل معه. هذه هي الفجوة المحددة في النسخة السابقة من مسودة فريق SCITT التابع لـ IETF. فقد طلبت النسخة -04 إدراج خوارزمية للبنية التي يستخدمها دفتر CCF، من دون طلب إدراج أنواع الإثبات الخاصة بها. في 12 سبتمبر لفت فحص IANA المختص إلى ذلك النقص. ثم حملت النسخة -05، المودعة في 23 سبتمبر، طلبين منفصلين يسدان الفجوة على مستوى الوصف المعياري.
ينقسم الطلب بين جدولين لا يجوز الخلط بينهما. الجدول الأول يسمي خوارزميات بنى البيانات القابلة للتحقق، وفيه يطلب المؤلفون القيمة 2 لـ CCF_LEDGER_SHA256. أما الثاني فيسمي أنواع الإثبات المرتبطة بكل بنية، وفيه يطلبون إدراج إثبات الإدراج عند -1 وإثبات الاتساق عند -2 تحت البنية المقترحة. تظهر القيمتان -1 و-2 أصلاً في جدول IANA، لكنهما تخصان البنية 1، المعروفة باسم RFC9162_SHA256. لذا لا يكفي قراءة الوسم السالب منفرداً: الزوج المكوّن من معرّف البنية ونوع الإثبات هو الذي يحدد المعنى الذي ينبغي للمدقق تطبيقه.
تعطي المسودة الجديدة أيضاً طريقاً واضحاً داخل إيصال COSE. يحمل الحقل المحمي vds معرّف البنية، وتضم خريطة vdp غير المحمية الإثباتات بحسب نوعها، اتساقاً مع إطار RFC 9942. ويشرح النص التحقق من الإدراج والاتساق. غير أن وصف طريقة تحقق مقترحة لا يثبت تشغيلها لدى جهة بعينها، ولا يحول وثيقة عمل إلى معيار نهائي.
يؤكد التسلسل الإداري ضرورة التريث. كان ملف النسخة -04 يحمل حالة IANA - Not OK. وعندما رُفعت -05 تغيّرت الحالة إلى Version Changed - Review Needed، بينما بقيت خانة مراجعة الخبراء تعرض Issues identified. لم يضف جدول IANA العام بنية CCF أو إثباتيها بعد. وتصف المسودة نفسها الرقم 2 بأنه قيمة مطلوبة، تستخدم بديلاً مؤقتاً إلى أن يحصل التخصيص. من غير الدقيق إذاً إعلان أن IANA أقرت المعرّف أو أن المسودة أصبحت RFC.
ويضع النص حداً آخر لقدرة الإثبات. عند فحص الاتساق، ينبغي مقارنة الجذر القديم المعاد حسابه بجذر سبق للمدقق أن تحقّق منه، لا بجذر يصل مع الإيصال نفسه. ولا يثبت إيصال الاتساق وحده محتويات الدفتر أو صحة تطبيق سياسة التسجيل. الإصلاح الموثق هنا هو استكمال مفردات الإثبات المشتركة، وليس منح مشغل السجل صكاً بصحة جميع قراراته.
المصادر
- https://datatracker.ietf.org/doc/draft-ietf-scitt-receipts-ccf-profile/05/
- https://datatracker.ietf.org/doc/draft-ietf-scitt-receipts-ccf-profile/04/
- https://datatracker.ietf.org/doc/draft-ietf-scitt-receipts-ccf-profile/history/
- https://www.iana.org/assignments/cose
- https://www.rfc-editor.org/rfc/rfc9942.html
- https://www.rfc-editor.org/rfc/rfc9943.html
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات

