الخلاصة

  • أحالت مجموعة عمل ACME المسودة draft-ietf-acme-profiles-02 إلى IESG في 21 سبتمبر 2026. تعني حالة Publication Requested أن النشر طُلب، لا أن IESG وافق أو أن RFC صدر.
  • ينقل newOrder.profile اختيار خصائص الشهادة إلى الطلب، لكن الإعلان والأهلية وقبول الطلب والإصدار والنشر تبقى قرارات وأدلة منفصلة.

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

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

موضع الوثيقة في المسار المعياري

سجل Datatracker في 21 سبتمبر انتقال الوثيقة من Working Group Last Call إلى «Submitted to IESG for Publication». وتظهر حالة IESG بوصفها «Publication Requested»، مع Deb Cooley مديرة للمنطقة مسؤولة عن الملف ومن دون موعد telechat. أرسل Mike Ounsworth طلب النشر باسم المجموعة.

الوجهة المقصودة Proposed Standard، لكن النسخة 02 ما زالت Internet-Draft. ويصف تقرير الـshepherd التوافق بأنه ضعيف لأن الامتداد عُد بسيطا ولأن الردود المؤيدة بقوة كانت قليلة، من دون تسجيل خلاف أو استئناف. أما قائمة التطبيقات ونشر Let’s Encrypt للآلية فهما دليل خبرة محدودة، لا قياسا لاعتماد الصناعة كلها.

ماذا يتغير في الطلب

يفصل RFC 8555 إنشاء طلب ACME عن إرسال CSR لاحقا إلى finalize. تضيف المسودة كائنا اختياريا اسمه profiles إلى بيانات Directory. يكون المفتاح معرفا قصيرا وفريدا لدى الخادم، وتشير القيمة إلى وصف مقروء للبشر، ويمكن أن تكون data URL.

يستطيع العميل وضع الاسم في newOrder.profile. وعند القبول يعيده كائن Order. بذلك يسبق اختيار الخصائص CSR، بينما يبقى المفتاح العام وsubjectAltName داخله. وتقول المسودة إن هذا قد يقلل تحليل ASN.1 ونسخه في منطق سياسة سلطة التصديق.

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

الإعلان ليس إذنا

يجب على الخادم إرجاع invalidProfile عندما لا يلائم الملف الطلب. ومن أمثلة المسودة طلب معرف بريد إلكتروني ضمن ملف مصادقة خادم TLS، أو استخدام حساب غير مؤهل حسب allowlist. لذلك لا تمنح رؤية الاسم كل حساب حق استعماله.

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

إذا لم يرسل العميل الحقل، توصي المسودة بأن يختار الخادم ملفا ويربطه بالطلب. من ثم لا يكفي حفظ الطلب؛ ينبغي حفظ Order الذي يبين الاختيار الذي طبقه الخادم.

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

الاسم محلي ويتغير مع الزمن

تصف Let’s Encrypt الـDirectory الحالي بأنه القائمة المرجعية، وتوضح أن الملفات قد تختلف بين بيئة الاختبار والإنتاج أو تقتصر على حسابات مدرجة في allowlist. وتختلف classic وtlsserver وshortlived في مدة إعادة استخدام التفويض وعمر الطلب والشهادة وأنواع المعرفات وحقول الشهادة.

لم يعد tlsclient متاحا منذ 8 يوليو 2026. وانتقل tlsserver إلى شهادات مدتها 45 يوما في 13 مايو، مع خطة لاحقة لتقليص مدة classic. تثبت هذه الوقائع تغير سياسة مشغل واحد؛ ولا تثبت أن سلطة أخرى تستخدم الاسم أو المعنى نفسه.

سلسلة أدلة لكل قرار

تبدأ السلسلة بحفظ بايتات Directory وعنوانه ووقت الحصول عليه. ثم تحفظ رابط الوصف وبصمة المحتوى المقروء. وبعد ذلك تسجل نقطة CA والحساب والمعرفات والاسم المطلوب وقرار الأهلية وOrder الذي يعيد اسم الملف.

يحتاج finalize إلى سجل مستقل لبصمة CSR وحالة الرد وأي ACME problem type. وإذا صدرت الشهادة، تثبت بصمتها وخصائصها المحللة ما وقعته السلطة. أما تركيبها في خدمة فعلية فهو حدث آخر يحتاج وقت المراقبة وموقعها وبصمة الشهادة المعروضة.

لا يمنح Directory حقا، وليس Order شهادة، ولا تثبت الشهادة الصادرة أنها نُشرت. إبقاء هذه الطبقات منفصلة يجعل الاسم مفتاح ربط مفيدا من دون تحميله وعدا غير موجود.

المصادر

  1. الحالة الحالية في Datatracker
  2. سجل الوثيقة
  3. نص draft-ietf-acme-profiles-02
  4. طلب النشر
  5. تقرير document shepherd
  6. RFC 8555
  7. وثائق ملفات Let’s Encrypt
  8. إعلان ACME Profiles
  9. خطة مدد الشهادات
  10. إعلان الدعوة الأخيرة لمجموعة العمل
  11. اختتام الدعوة الأخيرة
  12. متابعة تطبيق Boulder
  13. محضر ACME في IETF 126