حين تعيش بيانات الاعتماد أطول من قرار الإثبات

Summary

تقترح مسودة إنترنت فردية أن تحوّل خدمة وثائق هوية تفهم RATS نتيجة إثبات مقبولة إلى مفتاح أو رمز أو بيانات اعتماد مألوفة للأطراف المعتمدة التي لا تفهم RATS.
ينشأ بعد الإصدار فاصل زمني: قد تظل بيانات الاعتماد مقبولة وفق قواعدها الأصلية رغم تغير الدليل أو سياسة التقييم أو موقع عبء العمل أو ادعاء جوهري استند إليه الإصدار.
يقترح Daniel Kade «عقد صلاحية بين الإثبات وبيانات الاعتماد» يربط العمر والإلغاء الأصلي بحقبات الأدلة وإصدارات السياسات وفئات الادعاءات ومفتاح عبء العمل وأحداث التغير. هذا مقترح تحريري للحَوْكمة، لا موقف متفقاً عليه في IETF.

انتقال عادي يكشف حكمين مختلفين

لا يحتاج الاختبار إلى مهاجم. يقدم عبء العمل Evidence، ويقيّمها Verifier، ثم تقبل خدمة وثائق الهوية النتيجة وتصدر بيانات اعتماد. يمكن أن تكون القناة محمية، وأن يبقى المفتاح الخاص داخل عبء العمل، وأن تكون كل التواقيع صحيحة. بعد ذلك ينقل نظام التنسيق عبء العمل ضمن عملية تشغيل عادية.

تورد draft-bdnr-rats-trustworthy-credentials-02 فرقاً دقيقاً: قد يجعل الانتقال الحي من ألمانيا إلى فرنسا الادعاء Country=Germany غير صحيح، بينما يظل Region=Europe صحيحاً. لا تفرض الحركة أثراً واحداً على كل سلطة. قد تبقى صلاحية أوروبية سليمة، في حين تتطلب صلاحية مشروطة بالوجود في ألمانيا إعادة تقييم أو تضييقاً أو إلغاء.

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

تقليل نطاق التغيير هدف مشروع

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

تضع المسودة Credential Broker أو Key Broker أو Credential Authority في المنتصف، ليعمل بوصفه RATS Relying Party وIdentity Document Service معاً. يثبت عبء العمل حالته أمام هذا الوسيط، فإذا قبل السياسة النتيجة، أعاده إليه Identity Document تعرفه الخدمات المتعاونة. وقد يكون هذا المستند مفتاحاً أو رمزاً أو بيانات اعتماد قصيرة أو طويلة العمر. وتناقش المسودة وساطة المفاتيح، وبيانات اعتماد لإثبات الحيازة مجهزة سلفاً، وإصدار بيانات اعتماد جديدة لإثبات الحيازة أو رمز حامل قصير العمر.

فائدة «نطاق الأثر الصغير» حقيقية. تستمر مسارات TLS والشهادات والرموز القائمة، ويمكن أن يبقى المفتاح الخاص لدى عبء العمل، ولا يلزم توزيع Evidence الحساسة على كل مستهلك.

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

ثلاثة أزمنة لقرار وصول واحد

يفصل RFC 9334 بين Appraisal Policy for Evidence التي يستخدمها Verifier وبين Appraisal Policy for Attestation Results لدى Relying Party. تفسر الأولى الدليل وتنتج نتيجة، ثم تقرر الثانية ما إذا كانت النتيجة تكفي لغرض محدد. صحة نتيجة الإثبات ليست تفويضاً تلقائياً.

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

عندما تصدر خدمة الهوية بيانات اعتماد، تبدأ ساعة ثالثة. للشهادة notBefore وnotAfter، وللرمز موعد انتهاء، ولخدمة الحالة إيقاع تحديث. هذه هي الساعة التي تقرؤها الخدمة غير الواعية بـRATS، بينما لا ترى حقبة Evidence ولا نسختي سياسة التقييم. فإذا دامت بيانات الاعتماد ثماني ساعات وكان ادعاء جوهري موثوقاً لخمس دقائق، لم تحوّل عملية الإصدار الدقائق الخمس إلى ثماني ساعات؛ بل أخفت الفرق.

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

توقيع صحيح يحمل معنى قديماً

يحمي JWS في RFC 7515 سلامة الكائن ويربط توقيعه بمفتاح. ويختبر RFC 5280 مسار الشهادة والجهات المصدرة والقيود والزمن وحالة الإلغاء بحسب إعداد الطرف المعتمد. ويثبت Proof of Possession السيطرة على المفتاح الخاص. لكن أياً من هذه الاختبارات لا يعيد تقييم Evidence التي بررت الإصدار.

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

لا تنتهي مهمة Identity Document Service عند الإصدار. لقد ربطت عالماً متغيراً من Evidence والقيم المرجعية وEndorsements وVerifiers والسياسات، بعالم انتهاء الصلاحية وتدوير المفاتيح والاستعلام عن الحالة والإلغاء. ويجب أن تبقى هذه الرابطة حالة تشغيلية قادرة على الفعل، لا مجرد سجل تاريخي يُراجع بعد وقوع الضرر.

الادعاءات لا تشيخ دفعة واحدة

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

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

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

هوية عبء العمل لا تأتي من حامل الطلب

تسمح المسودة بأن يعمل عميل EST في hypervisor أو orchestrator خارج trusted computing base لعبء العمل. وقد يصادق ذلك العميل هويته لأغراض القناة. لكن هذه المصادقة الاختيارية لا ينبغي أن تحدد هوية عبء العمل التي تستحق بيانات الاعتماد؛ Evidence والإثبات يحددانها، وينبغي أن يبقى المفتاح الخاص لدى عبء العمل.

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

توضح مسودة LAMPS الخاصة بإثبات CSR مسؤولية مجاورة. فإذا استخدمت CA أو RA الإثبات، فهي مسؤولة عن ربط بيانات الإثبات بعضها ببعض وربطها بالمفتاح العام في طلب الشهادة، وينبغي أن توثق متطلباتها في Certification Practice Statement. هذا يوضح موضع مسؤولية الربط، لكنه لا يثبت أن دورة ما بعد الإصدار حُسمت في مسودة trustworthy credentials.

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

عقد صلاحية بين الإثبات وبيانات الاعتماد

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

يسجل العقد أولاً معرف بيانات الاعتماد ونوعها، وهوية عبء العمل، والمفتاح العام الذي يحتفظ به، وربط Proof of Possession. ثم يسجل حقبة Evidence وحد حداثتها، وهوية Verifier ونسخة Appraisal Policy for Evidence، ونسخة السياسة التي استخدمتها الخدمة لقبول Attestation Result. عند تغير السياسة أو Verifier يمكن العثور على الكائنات المتأثرة بدلاً من انتظار تجديد عشوائي.

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

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

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

الإلغاء ليس خانة في قاعدة بيانات

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

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

وللاستثناء دورة أيضاً. عند تعطل Verifier، قد يسمح مسؤول بثلاثين دقيقة من الاستمرار المحدود. ينبغي تسجيل صاحب السلطة والنطاق والنهاية والمراقبة التعويضية والتصرف النهائي. والاستثناء الذي يُمدد مراراً بلا إغلاق يتحول إلى سلسلة ثقة ثانية.

حدود ما تثبته المصادر

تقر مسودة trustworthy credentials بأعمال غير مكتملة. يحتاج مسار bearer token إلى بروتوكول أو امتداد آخر، ويحتاج /serverkeygen إلى تفاصيل إضافية. وتطلب قنوات متبادلة المصادقة تحمي السرية والسلامة وتتناول حفظ المفاتيح، لكنها لا تضع حوكمة كاملة لما بعد الإصدار.

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

قد تبقى بيانات اعتماد عبء العمل بعد تغير قرار إثبات السلامة

لماذا هذا مهم

Summary

انتقال عادي يكشف حكمين مختلفين

تقليل نطاق التغيير هدف مشروع

ثلاثة أزمنة لقرار وصول واحد

توقيع صحيح يحمل معنى قديماً

الادعاءات لا تشيخ دفعة واحدة

هوية عبء العمل لا تأتي من حامل الطلب

عقد صلاحية بين الإثبات وبيانات الاعتماد

الإلغاء ليس خانة في قاعدة بيانات

حدود ما تثبته المصادر

Sources

سياق أعمق للملف الشخصي

الدائرة الاستراتيجية

تحالف القيادات

إحاطة الدائرة الاستراتيجية

إحاطة تحالف القيادات