العنونة التشفيرية بالمفاتيح: IP وDNS وDID وIPvX

العنونة التشفيرية بالمفاتيح عبارة مريحة، لكن قد تختبئ خلفها نماذج معمارية مختلفة: المفتاح العام بوصفه معرّفًا للمضيف، أو تجزئة المفتاح العام، أو مستند DID يضم verification methods، أو تجزئة محتوى كائن رقمي.¹³⁴ في هذه المقالة لا ننسب إلى IPvX خصائص لا ترد في المصادر المذكورة: فالمصادر أدناه تصف HIP وDID وdid:drn والأسماء القائمة على التجزئات، لا مواصفة IPvX.¹²³⁴ لذلك نستخدمها كمعجم للنقاش الدقيق: أين يُثبت المعرّف بامتلاك المفتاح، وأين يكون محدِّدًا مكانيًا شبكيًا، وأين يظل إحالة إلى سجل خارجي.¹³⁴

لماذا من المهم الفصل بين الهوية والمحدِّد المكاني والاسم

يصف RFC 9063 فضاءين عالميين مهمين للأسماء على الإنترنت: عناوين IP وأسماء DNS.⁴ وتقول الوثيقة نفسها صراحة إن هذين الفضاءين حُمِّلا دلالات أكثر من اللازم، لأنهما اضطرا إلى أداء وظائف كثيرة جدًا.⁴ ردًا على ذلك، تُدخل معمارية HIP فضاء Host Identity، الذي يُفترض أن يسد الفجوة بين فضاءَي IP وDNS.⁴

في HIP، تشير Host Identity إلى منصة حوسبة، أما Host Identifier فهو التمثيل البِتّي المحدد لهذه الهوية.⁴ وتشدد الوثيقة أيضًا على الفرق بين identity بوصفها كيانًا مجردًا وidentifier بوصفه نمطًا بِتّيًا محددًا يُستخدم عند التعريف.⁴ هذا تمييز مفيد لمهندسي الشبكات: مصطلح يجيب عن سؤال «من يشارك في التفاعل»، وآخر يجيب عن «ما المادة البِتّية المستخدمة للتحقق»، بينما يظل فضاء IP فضاء أسماء مستقلًا في معمارية HIP.⁴

لذلك، عندما نناقش IPvX، نحاول صياغة الخصائص صياغة مشروطة: إذا كان العنوان مفتاحًا عامًا أو قيمة مشتقة منه، فهذا نموذج تحقق معيّن؛ وإذا كان العنوان يُحل عبر مستند أو فهرس، فهذا نموذج ثقة آخر؛ وإذا كانت القيمة تجزئة بيانات، فهذه بالفعل نموذج content addressing.¹³⁴

نموذج HIP: المعرّف بوصفه مفتاحًا عامًا

في التركيز التشفيري لـ HIP، يكون Host Identifier مفتاحًا عامًا لزوج مفاتيح غير متماثل.⁴ ووفق مصطلحات RFC 9063، يُفترض أن المفتاح الخاص معروف فقط للطرف المعرَّف بالمفتاح العام المقابل، ويستخدمه هذا الطرف لمصادقة هويته أمام أطراف أخرى.⁴ لذلك، في هذه المعمارية تحديدًا، لا يرتبط التحقق فقط بوجود سلسلة نصية أو قيمة ثنائية، بل بقدرة المشارك على اجتياز تبادل تشفيري باستخدام المفتاح الخاص المقابل.⁴

كما يعرّف HIP أيضًا Host Identity Tag بوصفه قيمة من 128 بت تُنشأ عبر تجزئة تشفيرية لـ Host Identifier وبِتّات تشير إلى التجزئة المستخدمة.⁴ وهذا مهم للعنونة بقيمة مشتقة: فالوسم المدمج لا يساوي المفتاح العام نفسه، لكن معناه يتحدد من كونه محسوبًا من Host Identifier وفق قواعد HIP.⁴ وتشير الوثيقة أيضًا إلى أنه عند استبدال المفتاح قد تكون هناك فترات انتقالية ينشط فيها أكثر من معرّف واحد لـ Host Identity واحدة.⁴

لا يمكن من هذا النموذج استنتاج خصائص أي نظام تظهر فيه كلمة «مفتاح» تلقائيًا.⁴ والصياغة الدقيقة هي: في HIP، يكون Host Identifier مفتاحًا عامًا، وتعتمد المصادقة على زوج المفاتيح العام والخاص المقابل.⁴

كيف يختلف ذلك عن عناوين IP

يتعامل HIP مع عناوين IP بوصفها فضاء أسماء عالميًا مستقلًا على الإنترنت، مختلفًا عن Host Identity namespace.⁴ وتقع طبقة بروتوكول HIP بين طبقتَي internetworking وtransport، وتعلن المعمارية نفسها دعم تنقّل المضيفين الطرفيين، وmultihoming، واجتياز NAT.⁴ في هذه المعمارية، لا تكون هوية المضيف ومعلومات IP الحالية كيانًا واحدًا في النموذج.⁴

بالنسبة إلى مناقشة IPvX، يمنحنا ذلك إطارًا دقيقًا، لكنه لا يقدّم استنتاجًا جاهزًا حول تنفيذ IPvX.⁴ إذا كان العنوان في مشروع ما مشتقًا من مفتاح، فإن الخاصية القابلة للتحقق تتعلق بمادة المفتاح وبامتلاك المفتاح الخاص قياسًا على HI التشفيرية في HIP.⁴ أما إذا استُخدمت القيمة للتسليم عبر الشبكة، فيجب وصف كيفية ارتباطها بالتوجيه ونقطة قابلية الوصول الحالية على نحو مستقل، لأن RFC 9063 نفسه يفصل بين فضاء IP وHost Identity namespace.⁴

كيف يختلف ذلك عن أسماء DNS

يسمّي RFC 9063 أسماء DNS الفضاء العالمي المهم الثاني للأسماء على الإنترنت إلى جانب عناوين IP.⁴ في HIP يمكن نشر Host Identifier، على سبيل المثال، في DNS، أو يمكن أن يبقى غير منشور.⁴ وهذا لا يعني إلا أن DNS قد يظهر كمكان لنشر Host Identifier في المعمارية الموصوفة، لا أن اسم DNS نفسه يصبح Host Identifier.⁴

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

الفرق العملي هو الآتي: في HIP تُحدَّد الهوية التشفيرية للمضيف بواسطة Host Identifier، بينما ينتمي DNS إلى فضاء أسماء آخر.⁴ إذا كان عنوان IPvX في مواصفة محددة سيُشتق من مفتاح عام، فينبغي وصف التحقق منه بقواعد تلك المواصفة، لا بافتراض حول حلّ DNS.⁴

كيف يختلف ذلك عن DID

يعرّف DID Core 2022 الـ DID بوصفه URI يربط DID subject بـ DID document.¹ يمكن أن يعبّر DID document عن مادة تشفيرية أو verification methods أو خدمات توفّر آليات لإثبات السيطرة على DID.¹ وتقول المواصفة أيضًا إن التصميم يسمح لمتحكم DID بإثبات السيطرة من دون إذن طرف آخر، مع أن أطرافًا أخرى قد تساعد في اكتشاف المعلومات المرتبطة بـ DID.¹

لكن DID Core لا يفرض تقنية واحدة أو تشفيرًا واحدًا لتوليد DID أو ثباته أو حلّه أو تفسيره.¹ وتسمح المواصفة صراحة بأن ينشئ implementers معرّفات DIDs على أساس معرّفات مسجلة في أنظمة إدارة هوية اتحادية أو مركزية.¹ لذلك لا يمكن من الصيغة did:method:id وحدها الاستنتاج أن المعرّف يساوي مفتاحًا عامًا.¹

تؤكد قصة DID Core الطابع المعتمد على الطريقة في هذا النموذج.⁵ فقد وصفت مسودة العمل لعام 2020 DID methods بوصفها آلية لإنشاء DID وDID documents المرتبطة به وقراءتها وتحديثها وتعطيلها في DID registry محدد.⁵ وحذرت المسودة نفسها من أن DIDs الناتجة عن طرق مختلفة قد لا تكون قابلة للتشغيل البيني، وأن DID methods مختلفة قد تستخدم مخططات تشفيرية مختلفة.⁵

بالنسبة إلى IPvX، يعني ذلك أنه لا يمكن استخدام DID في نقاش الهوية إلا مع تحديد DID method وقواعد الحل.¹⁵ إذا كانت الخاصية التي نريد مناقشتها هي تحديدًا «العنوان يُثبت بالمفتاح»، فإن DID Core وحده غير كافٍ: يجب النظر إلى DID document وverification methods والطريقة التي تحدد العمليات على هذا DID.¹⁵

Content addressing: تجزئة البيانات لا تساوي هوية الذات

يعرّف RFC 6920 طرقًا لتعريف كائن رقمي عبر ناتج دالة تجزئة.³ وتعرض الوثيقة Named Information identifiers، بما في ذلك URI من نوع ni، وكذلك الصيغ الثنائية والصيغ القابلة للنطق البشري لهذه الأسماء.³ وتهدف هذه الصيغ إلى دعم ارتباط قوي بالكائن، لا اشتراطه، بحيث يمكن مصادقة الكائن إلى الدرجة نفسها التي تُصادَق بها الإحالة إليه.³

التحقق الأساسي في هذا النموذج هو تكامل الاسم والبيانات: إذ تُقارَن التمثيلة المستلمة للمورد بالاسم الذي طُلب المورد من خلاله.³ كما يشير RFC 6920 إلى أن Named Identifier يسمّي موردًا، وأن آلية فك الإحالة والعثور على المورد يجب أن تكون معروفة للطرف الذي يفك الإحالة.³ وهذا يفصل «الاسم القائم على التجزئة» عن «المسار إلى مكان التخزين».³

يناقش RFC 6920 بشكل مستقل الحالة التي يكون فيها مُدخل دالة التجزئة مفتاحًا عامًا، ويوصي بحساب التجزئة على المفتاح العام ضمن بنية X.509 SubjectPublicKeyInfo.³ لكن الوثيقة نفسها تقول إنه، باستثناء هذه الحالة الخاصة، لا يحدد RFC 6920 مُدخل دالة التجزئة، ويجب أن تحدده مواصفات أخرى.³ لذلك فإن تجزئة ملف، وتجزئة رسالة، وتجزئة مفتاح عام تحمل معاني مختلفة، حتى لو كانت كلها تقنيًا نواتج لدالة تجزئة.³

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

did:drn كمثال على اسم خارجي بلا متحكم مضمّن

يُعد مشروع did:drn مفيدًا كمثال حدّي، لكن يجب أخذ وضعه في الاعتبار: Internet-Drafts هي وثائق عمل تابعة لـ IETF، يمكن تحديثها أو استبدالها أو أن تصبح متقادمة، ولا ينبغي الاستشهاد بها إلا بوصفها work in progress.² في هذا المشروع، يعرّف did:drn تحويلًا حتميًا من URN إلى صيغة Decentralized Resource Name متوافقة مع DID.²

يجب أن يكون الحل الأساسي لـ did:drn قادرًا على بناء DID Document أدنى من سلسلة DID نفسها، من دون رجوع إلزامي إلى سجل مركزي أو دفتر موزع أو خدمة شبكية.² ومع ذلك، يقول المشروع صراحة إن did:drn identifier لا يؤكد وجود متحكم ولا يلمّح إليه افتراضيًا.² وتوصف verification methods وservice endpoints في did:drn بأنها خصائص اختيارية في DID Document.²

يوضح هذا المثال جانبًا مهمًا: فالاسم الحتمي وغياب الاعتماد الشبكي الإلزامي في baseline resolution لا يساويان إثبات امتلاك المفتاح الخاص.² لإثبات السيطرة نحتاج إلى قواعد وverification methods، لا مجرد تحويل قابل للعكس من URN إلى سلسلة DID.²

كيف نتحدث بدقة عن عنوان IPvX

نقترح في نصوص IPvX الفصل صراحة بين ثلاثة أسئلة، من دون تقديم ذلك كخاصية مثبتة سلفًا لتنفيذ عالمي: ما المادة التي تمثل المعرّف، وكيف تُتحقق السيطرة عليه، وبأي آلية يُعثر على مسار التسليم.¹³⁴ إذا كان المعرّف مفتاحًا عامًا أو قيمة مشتقة منه، فإن أقرب نموذج في المصادر المذكورة هو HIP، حيث يكون Host Identifier مفتاحًا عامًا، ويُستخدم المفتاح الخاص لمصادقة الهوية المقابلة.⁴ وإذا كان المعرّف DID، فيجب تحديد DID method، لأن DID Core لا يثبت تقنية واحدة أو تشفيرًا واحدًا لجميع DIDs.¹ وإذا كانت القيمة تجزئة كائن رقمي، فالأدق الحديث عن التحقق من الصلة بين الاسم والبيانات وفق نموذج RFC 6920.³

تساعد هذه اللغة على عدم الخلط بين التوجيه والهوية والاكتشاف.¹³⁴ يبيّن HIP الفصل بين Host Identity namespace وIP/DNS namespaces.⁴ ويبيّن DID Core نموذج URI وDID document وverification methods والبنية التحتية المعتمدة على الطريقة.¹⁵ ويبيّن RFC 6920 نموذج الاسم القائم على التجزئة، حيث يبقى العثور على المورد منفصلًا عن الاسم نفسه.³

مقارنة موجزة

النموذج	ما الذي يحدده المعرّف	أين تُتحقق الصلة
IP في سياق HIP	فضاء عالمي مستقل لعناوين IP	يفصل HIP فضاء IP عن Host Identity namespace.4
DNS في سياق HIP	فضاء عالمي مستقل لأسماء DNS	يمكن نشر Host Identifier في DNS، لكن HIP يظل يُدخل فضاء Host Identity مستقلًا.4
HIP Host Identifier	مفتاح عام لزوج غير متماثل	يستخدم الطرف المفتاح الخاص لمصادقة الهوية أمام أطراف أخرى.4
DID	URI يربط subject بـ DID document	يمكن أن يحتوي DID document على verification methods، أما التقنية المحددة فتعتمد على DID method.15
RFC 6920 / ni	تجزئة كائن رقمي أو، في حالة خاصة، تجزئة مفتاح عام	يُتحقق من مطابقة البيانات للاسم؛ ويجب أن تكون طريقة العثور على المورد معروفة للطرف الذي يفك الإحالة.3
did:drn draft	تحويل حتمي من URN إلى صيغة متوافقة مع DID	لا يفترض did:drn الأساسي وجود متحكم، وتكون verification methods اختيارية.2

الخلاصة

تتطلب العنونة التشفيرية بالمفاتيح، بالمعنى الدقيق، مواصفة يكون فيها المعرّف مرتبطًا بمفتاح عام أو بقيمة مشتقة منه، وتُتحقق السيطرة عبر امتلاك المفتاح الخاص المقابل؛ وهذا بالضبط هو النموذج الذي يصفه HIP لـ Host Identifier.⁴ تُعامل عناوين IP وأسماء DNS في RFC 9063 بوصفها فضاءات أسماء مستقلة لا ينبغي مساواتها تلقائيًا بـ Host Identity التشفيرية.⁴ يقدّم DID صيغة URI عامة وDID Document مع verification methods، لكنه لا يفرض تشفيرًا موحدًا أو بنية تحتية موحدة للحل.¹ أما content addressing وفق RFC 6920 فيتحقق من صلة الاسم بالكائن الرقمي، لكن معنى التجزئة يعتمد على ما قُدّم مُدخلًا إلى دالة التجزئة.³

بالنسبة إلى IPvX، لا يمثل ذلك إثباتًا لخاصية بروتوكول محددة، بل انضباطًا في وصف المعمارية.¹³⁴ إذا قلنا «عنوان قائم على المفتاح»، فيجب أن نحدد على نحو مستقل ما مادة المفتاح تحديدًا، وكيف يُتحقق امتلاك المفتاح الخاص، وكيف تتم عملية التسليم، وما السجلات الخارجية التي تشارك في الاكتشاف.¹³⁴

المصادر

1. Decentralized Identifiers (DIDs) v1.0, w3.org, 19‏/07‏/2022
2. Decentralized Resource Name (DRN) DID Method, ietf.org, 24‏/03‏/2026
3. RFC 6920: Naming Things with Hashes, datatracker.ietf.org
4. RFC 9063: Host Identity Protocol Architecture, datatracker.ietf.org
5. Decentralized Identifiers (DIDs) v1.0, w3.org, 03‏/04‏/2020
6. Decentralized Identifiers (DIDs) v1.0, w3.org, 15‏/06‏/2021
7. Decentralized Identifiers (DIDs) v1.0, w3.org, 08‏/04‏/2020
8. RFC 6920: Naming Things with Hashes, datatracker.ietf.org