الخلاصة

  • وافقت IESG على draft-ietf-acme-device-attest بصفته Proposed Standard في 30 يوليو 2026. وما زالت المراجعة 10 لدى RFC Editor؛ فلا يفترض المقال رقماً نهائياً أو تنفيذاً منشوراً.
  • يستطيع device-attest-01 أن يربط معرّف Order بالمفتاح المثبت ومفتاح CSR. وتبقى قوة الربط رهينة الصيغة وجهة الإثبات وما إذا كان التوقيع يغطي token وحده أو key authorization المرتبطة بالحساب.
  • يجيز هذا الدليل عملية إصدار واحدة. ولا يجدد حالة الجهاز، كما قد تخلو الشهادة المحافِظة على الخصوصية من أي معرّف عتادي.

كلمة واحدة تخفي سلسلة كاملة

يسهل وصف شهادة صحيحة بأنها صادرة عن «جهاز مثبت». لكن العبارة لا تقول أي challenge اكتمل، ولا من وثق الادعاء، ولا أي مفتاح طابق CSR، ولا متى قيس firmware أو وضع الإقلاع.

يضيف الامتداد permanent-identifier لهوية يعيّنها المصنع عادة، وhardware-module لنوع وحدة التشفير ورقمها التسلسلي، ثم device-attest-01 لإجراء التحدي. وتعرض IANA هذه القيود الآن بمرجع RFC-to-be. هذا سجل تنسيق، وليس دليلاً على أن منتجاً معيناً نفذها.

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

لكن بعض الجهات الخارجية توقع قبل توفر مفتاح حساب ACME، فتغطي token وحده. يوفر ذلك حداثة للطلب، ولا يربطه بمفتاح الحساب. ولا يجوز لعلم واحد اسمه attested أن يمحو الفرق.

ما عُرض ليس بالضرورة ما نُفذ

يجوز لـ authorization واحدة أن تعرض device-attest-01 مع challenge آخر، ويكفي إتمام أي واحد منهما. تساعد المرونة أساطيل الأجهزة المختلطة، لكنها تجعل تسجيل المسار الفعلي واجباً.

دعم الخادم للإثبات لا يعني أن Order هذه استخدمته. كما أن External Account Binding يضبط قبول حساب المؤسسة، لكنه لا يثبت أن مفتاح CSR داخل العتاد المعلن. والإثبات الناجح لا يجعل صلاحية الحساب أبدية.

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

قد تبقى هوية العتاد داخل جهة الإصدار

تسمح المراجعة 10 بحذف المعرّفين من CSR، وقد يرفض الخادم المهتم بالخصوصية CSR يكشفهما. وهكذا تستطيع CA استعمال الدليل العتادي للقرار الداخلي، ثم إصدار شهادة تحمل هوية منطقية للعمل فقط.

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

أما الطرف المعتمد فلا يحق له استنتاج إثبات غير موجود في الشهادة. من دون إيصال إصدار مستقل لا يعرف الصيغة أو الجهة أو challenge أو خصائص النظام التي فحصتها CA.

قد يحمل الإثبات firmware وحالة الإقلاع ونظام التشغيل ومستوى الحماية. ويمكن للـCA رفض الطلب بسببها، لكن المسودة لا توحد طرق التحقق، فضمان TPM ليس ضمان TEE أو مخزن مفاتيح يحميه نظام التشغيل. ولكل خاصية وقت رصد؛ مدة الشهادة ليست حداثة القياس.

وفق طبقات الواقع عند Heng Lu، موافقة IESG، وقيد IANA، ونجاح challenge، وإصدار الشهادة، والحالة الحالية، وقرار الوصول، إيصالات منفصلة. إبقاء الحدود يجعل الدليل قابلاً للتدقيق.

المصادر