إثبات المفتاح لا يثبت اسم النطاق

الخلاصة

• تنقل draft-ietf-acme-pop-00 مفتاح الشهادة إلى newOrder في الحقل popKey، وتنشئ تفويض pop وتحدي pop-01 خاصين بذلك الطلب.
• يثبت pop-01 امتلاك المفتاح فقط؛ أما DNS والبريد وغيرهما من معرّفات الشهادة فتظل لها تحديات ACME مستقلة.
• يرتبط الإثبات بتجزئة البايتات الأصلية لـ newOrder، لا بكائن JSON أعيد بناؤه بعد التحليل.
• في نمط ML-KEM يستطيع الخادم أيضاً حساب MAC المتوقع، لذلك يصلح الرد لقرار الخادم ولا يصبح دليلاً مستقلاً غير قابل للإنكار.
• الإصدار 00 هو Internet-Draft لمسار المعايير، وليس RFC أو تقرير تنفيذ أو دليلاً على نشر فعلي.

سؤالان لا سؤال واحد

يطلب العميل شهادة لمعرّف، ويقترح مفتاحاً عاماً يوضع فيها. قد يبدو ذلك عملية واحدة، لكنه يتضمن سؤالين مختلفين: هل يملك هذا الطرف المفتاح الخاص؟ وهل أثبت السيطرة التي تقبلها سلطة الشهادات على اسم DNS أو المعرّف الآخر؟

تجعل المسودة الفصل صريحاً. يرسل العميل popKey ومعرّفاً واحداً من نوع pop وقيمته سلسلة فارغة، إضافة إلى معرّف شهادة واحد على الأقل. ينشئ الخادم تفويضاً مخصصاً لإثبات المفتاح، بينما تستمر معرّفات الشهادة في تفويضاتها المعتادة.

لا يصبح الطلب جاهزاً إلا عندما تكون جميع التفويضات صالحة. امتلاك مفتاح من دون السيطرة على الاسم لا يكفي. والسيطرة على الاسم من دون المفتاح المعلن لا تكفي. ويمكن أن تنضم شهادة جهاز أو RATS أو Profile إلى الطلب، لكن كل آلية تظل مسؤولة عن القضية التي اختبرتها فقط.

السلسلة الفارغة لا تحمل هوية

القيمة الفارغة لمعرّف pop ليست اسماً ولا بصمة مفتاح. ولا تُكتب في subject أو Subject Alternative Name. وظيفتها الوحيدة أن تطلب تفويضاً مستقلاً لإثبات الامتلاك.

المفتاح نفسه ينتقل في popKey بصيغة DER SubjectPublicKeyInfo. ويجب أن يختلف عن مفتاح حساب ACME بعد المقارنة بالصيغة القانونية. مفتاح الحساب يصدّق رسائل البروتوكول؛ أما مفتاح الشهادة فسيستخدمه التطبيق. جمع الدورين في مفتاح واحد يخلط سلطة إدارة الحساب مع سرّ الخدمة التي ستستعمل الشهادة.

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

الإثبات يخص بايتات طلب محددة

تعرّف المسودة raw_newOrder بأنه البايتات الناتجة عن فك payload في JWS قبل تحليل JSON. وتُحسب newOrder_hash باستخدام SHA-256 فوق تلك البايتات نفسها. لا يجوز للخادم إعادة إنشاء JSON ثم تجزئته.

في نمط التوقيع، يوقّع العميل بادئة فصل نطاق ثابتة وpopNonce جديداً من 32 بايت وتجزئة الطلب. وفي نمط ML-KEM ينفذ الخادم Encaps نحو المفتاح، وينشر challenge_ciphertext جديداً، ويشتق mac_key عبر HKDF-SHA-256؛ ثم يعيد العميل HMAC لتجزئة الطلب بعد Decaps.

أي تغيير في المفتاح أو المعرّفات أو الحقول الأخرى يغيّر سياق الإثبات. كما لا يمكن إعادة استخدام تفويض pop من طلب سابق أو الحصول عليه عبر pre-authorization. لكل طلب مادة تحدٍّ جديدة.

إثبات KEM ليس توقيعاً منقولاً

العميل الذي لا يملك المفتاح الخاص لا يستطيع فك ciphertext واستخراج MAC الصحيح. لذلك يملك الخادم أساساً لاتخاذ قرار الإصدار.

لكن الخادم أنشأ encapsulation ويعرف السر المشتق، ويستطيع إنتاج MAC نفسه. إذا عُرض السجل لاحقاً على طرف ثالث، فلا يمكنه إثبات أن العميل وحده أنشأ الرد. توضح المسودة أن نمط KEM لا يقدم عدم إنكار.

يمكن حفظ ciphertext والرد وتجزئة الطلب والوقت كأثر تدقيق داخلي، بشرط وصف حدوده. ويجب ألا يُحفظ shared secret الخام، وأن يُدمّر mac_key عند انتهاء التحدي، وألا يعاد استخدام ciphertext بين الطلبات.

الإلغاء يكشف مركز السلطة

يسمح RFC 8555 بإلغاء شهادة باستخدام مفتاح الحساب أو المفتاح الخاص للشهادة. مفتاح KEM لا يوقّع، ولذلك لا يتوفر المسار الثاني.

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

مع STAR يبقى popKey الأول خلال دورة التجديد الآلي ولا يعاد pop-01 لكل شهادة. وشهادات STAR لا تُلغى منفردة عبر هذا المسار؛ مفتاح الحساب يلغي الطلب ويوقف الإصدار المقبل. إذا فُقد المفتاح، فقد يستمر التجديد حتى التدخل أو تاريخ نهاية الطلب.

{} لا يعني غياب السياسة

بعد صلاحية كل التفويضات يرسل العميل طلب finalization محتواه كائن JSON فارغ. تضع سلطة الشهادات مفتاحاً مكافئاً لـ popKey ومعرّفات سبق تفويضها. وتظل مدة الصلاحية وKey Usage وبقية الحقول تحت سياسة السلطة أو Profile مناسب.

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

نُشر الإصدار 00 في 1 سبتمبر 2026 ويمكن أن يتغير أو ينتهي. لا يدّعي هذا المقال دعم سلطة شهادات أو عميل معيّن، ولا إصداراً أو تشغيلاً بينياً أو حادثاً أو انتشاراً.