التوقيع الإلكتروني المؤهل - مشاكل معرفات الكائن لنظم المعلومات. توقيع خاطئ فشل التحقق من صحة التوقيع معرّف كائن مفقود فك تشفير OID OID

عند إدخال حسابك الشخصي لطلب QEP ، يتم عرض رسالة « الكمبيوتر غير مهيأ . للمتابعة ، انتقل إلى صفحة إعدادات الكمبيوتر واتبع الخطوات المقترحة » . بعد الانتقال إلى صفحة الإعدادات وتثبيت جميع المكونات الضرورية في ملف حساب شخصيتظهر الرسالة التي تفيد بأن الكمبيوتر لم يتم تكوينه مرة أخرى.

لإصلاح الخطأ ، يجب عليك:

1. أضف عنوان حسابك الشخصي https://i.kontur-ca.ru إلى المواقع الموثوقة. لهذا:

حدد القائمة "ابدأ"> "لوحة التحكم"> "خيارات الإنترنت" ؛
انتقل إلى علامة التبويب "الأمان" ، وحدد العنصر "المواقع الموثوقة" (أو "المواقع الموثوقة") وانقر على زر "العقد" ؛
حدد عنوان العقدة التالي https://i.kontur-ca.ru في حقل Add to zone وانقر فوق الزر Add.

إذا كان هذا العنوان موجودًا بالفعل في قائمة المواقع الموثوقة ، فانتقل إلى الخطوة التالية.

2. تأكد من تحديد عنوان الحساب الشخصي https://i.kontur-ca.ru على أنه موثوق:

إذا تم استخدام الإصدار 8 من Internet Explorer ، فحينئذٍ ، يجب عليك التحقق مما إذا كان مربع اختيار المواقع الموثوقة في أسفل الصفحة ، كونك في صفحة التفويض. إذا لم يكن هناك مربع اختيار ، ولكن هناك نقش « الإنترنت "، فإن العنوان https://i.kontur-ca.ru لم تتم إضافته إلى المواقع الموثوقة.

إذا تم استخدام الإصدار 9 من Internet Explorer والإصدارات الأحدث ، فعند وجودك في صفحة التفويض ، يجب النقر بزر الماوس الأيمن في أي مكان على الصفحة وتحديد "خصائص". في النافذة التي تفتح ، يجب أن يحتوي سطر "المنطقة" على النقش "مواقع موثوق بها". بخلاف ذلك ، لم تتم إضافة العنوان https://i.kontur-ca.ru إلى المواقع الموثوقة.

إذا لم يتم تحديد عنوان الحساب الشخصي على أنه موثوق ، فيجب عليك الاتصال بمسؤول النظام لطلب إضافة العنوان https://i.kontur-ca.ru إلى العقد الموثوقة.

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

4. تحقق من أن الكمبيوتر يستخدم حقوق المسؤول (للتحقق ، انتقل إلى ابدأ - لوحة التحكم - حسابات المستخدمين وأمان العائلة - حسابات المستخدمين). إذا لم تكن الحقوق كافية ، فأنت بحاجة إلى منح المستخدم الحقوق الكاملة ، لذلك اتصل بالمسؤول.

5. بعد الانتهاء من الخطوة 3 ، من الضروري إعادة تشغيل الكمبيوتر والتحقق من مدخل الحساب الشخصي.

إذا لم تساعد أي من التعليمات ، فعليك الاتصال دعم فنيبالعنوان [البريد الإلكتروني محمي]يجب أن تشير الرسالة إلى:

1. رقم التشخيص.

للقيام بذلك ، يجب أن تذهب إلى بوابة التشخيص علىhttps://help.kontur.ru ، اضغط الزر "بدء التشخيص » . بمجرد اكتمال عملية التحقق ، سيتم عرض رقم التشخيص على الشاشة. حدد الرقم المرجعي المخصص في الحرف.

2. لقطة شاشة للنافذة بها الخطأ (عند استخدام الإصدار 9 من Internet Explorer والإصدارات الأحدث ، يجب أيضًا إرفاق لقطة شاشة لنافذة "الخصائص" - راجع النقطة 2).

3. تصدير وإرفاق فروع التسجيل التالية:

32 بت: HKLM \ SOFTWARE \ Microsoft \ Cryptography \ OID \ EncodingType 0 \ CryptDllFindOIDInfo
64 بت: HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ Cryptography \ OID \ EncodingType 0 \ CryptDllFindOIDInfo

الأحكام العامة.
يعتمد اختيار طريقة لتقديم بيانات معينة وقيود إضافية على تكوين حقول الشهادة على المبادئ التالية:
التوصيات الدولية. تم تطوير هذه الوثيقة مع مراعاة التوصيات الدولية:
- RFC 3280 (تحديث RFC 2459) Internet X.509 Public Key Infrastructure. ملف تعريف قائمة الشهادات والشهادات (CRL).
- RFC 3039 Internet X.509 Public Key Infrastructure. ملف تعريف الشهادة المؤهل - يقترح هذا RFC المتطلبات العامةإلى صيغة (تكوين) الشهادات ، التي يعتبر استخدامها مهمًا من الناحية القانونية.

تكوين حقول الشهادة والغرض منها.

يقدم هذا القسم وصفًا للحقول الرئيسية لشهادة المفتاح العام التي تتوافق مع قانون "التوقيع الرقمي الإلكتروني" بتاريخ 10.01.2002.

تستند المفاهيم والترميزات والمصطلحات المستخدمة في هذا القسم إلى RFC 3280 و RFC 3039 ، والتي بدورها تستند إلى التوصية ITU-T X.509 الإصدار 3. محتوى القسم لا ينسخ محتوى هذه الوثائق ، ولكن يشير فقط إلى اختلافات وميزات استخدام شهادات الحقول التي تنفذ متطلبات تكوين شهادة EDS المنصوص عليها في المادة 6 من قانون EDS.

بالنسبة لجميع حقول الشهادة التي تتطلب قيم سلسلة باللغة الروسية ، يُفضل استخدام ترميز UTF-8 العالمي (نوع UTF8String).

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

إصدار
تم إصدار جميع الشهادات يجبلديك الإصدار 3.

رقم سري
الرقم التسلسلي الحقل يجبتحتوي على "... رقم تسجيل فريد لشهادة مفتاح التوقيع" (المادة 6 ، البند 1 ، الفقرة 1). يجب احترام الطابع الفريد لرقم الشهادة داخل مرجع مصدق معين (CA).

صلاحية
مجال الصلاحية يجبتحتوي على "... تواريخ بداية وانتهاء فترة صلاحية شهادة مفتاح التوقيع الموجودة في سجل مركز التصديق" (المادة 6 ، البند 1 ، الفقرة 1).

SubjectPublicKeyInfo
حقل subjectPublicKeyInfo يجبتحتوي على "... المفتاح العمومي للتوقيع الرقمي الإلكتروني" (المادة 6 ، البند 1 ، الفقرة 3).

المُصدر
يفترض القانون الاتحادي "بشأن EDS" إصدار الشهادات للأفراد فقط ، وينطبق هذا الحكم أيضًا على شهادات CA نفسها وشهادات الموارد. من أجل الامتثال للمتطلبات الرسمية للقانون الاتحادي ، يُقترح الإشارة في سمات شهادات CA والموارد في السمات إلى المعلومات الحقيقية للمنظمة ، مع الأخذ في الاعتبار أن هذه الشهادة قد تم إصدارها إلى مسؤول معتمد للفرديجب تفسير CA أو Resource والمعلومات المحددة وتسجيلها كشهادة لاسم مستعار ، مما يسمح للقانون الفيدرالي "On EDS".
المصدر يجبتحديد المنظمة التي أصدرت الشهادة بشكل فريد وتحتوي على الاسم المسجل رسميًا للمؤسسة.
يمكن استخدام السمات التالية لتحديد الهوية:

اسم الدولة	(معرف في 6)
اسم الولاية أو المقاطعة	(معرف في 8)
الاسم المحلي	(معرف في 7)
اسم المنظمة	(معرف في 10)
التنظيمي اسم وحدة	(معرف في 11)
العنوان البريدي	(معرف في 16)
رقم سري	(معرف في 5)

المصدر يجبتأكد من تضمين السمات التي تصف "اسم ومكان سلطة التصديق التي أصدرت شهادة مفتاح التوقيع" (المادة 6 ، البند 1 ، الفقرة 5).

اسم يجبالمحدد في سمة OrganizationName. عند استخدام سمة OrganizationName يمكن

موقع CA يمكنيتم تحديدها باستخدام مجموعة من سمات اسم البلد أو stateOrProvinceName أو localityName (كل منها اختياري) أو باستخدام سمة postalAddress واحدة. بأي من الطرق المذكورة أعلاه ، موقع CA يجب أن يكون حاضرفي الشهادة.

يجبتحتوي على العنوان القانوني للمرجع المصدق. يجب استخدام مسافة (الحرف "0x20") كمحدد.

سمة الحقل الموضوع serialNumber يجبتستخدم في تضارب الأسماء.

موضوعات
لتمثيل DN (الاسم المميز) لمالك الشهادة مايويتم استخدام السمات التالية:

اسم الدولة	(معرف في 6)
اسم الولاية أو المقاطعة	(معرف في 8)
الاسم المحلي	(معرف في 7)
اسم المنظمة	(معرف في 10)
التنظيمي اسم وحدة	(معرف في 11)
لقب	(معرف في 12)
اسم شائع	(معرف في 3)
اسم مستعار	(معرف في 65)
رقم سري	(معرف في 5)
العنوان البريدي	(معرف في 16)

للامتثال للمتطلبات الرسمية للقانون الفيدرالي ، يُقترح الإشارة في سمات CA وشهادات الموارد إلى المعلومات الحقيقية للمؤسسة ، مع الأخذ في الاعتبار أن هذه الشهادة تم إصدارها إلى فرد مرخص له من CA أو المورد و يجب تفسير المعلومات المحددة وتسجيلها كشهادة لاسم مستعار ، وهو ما يسمح به القانون الفيدرالي "في EDS".

حقل الموضوع يجبمن الضروري احتواء المعلومات التالية: "الاسم الأخير والاسم الأول واسم العائلة لمالك شهادة مفتاح التوقيع أو الاسم المستعار للمالك" (المادة 6 ، البند 1 ، الفقرة 2).

اسم المالك واسمه واسمه يجبأن تكون متضمنة في سمة CommonName وتتطابق مع تلك المحددة في جواز السفر. يجب استخدام مسافة (الحرف "0x20") كمحدد.

الاسم المستعار للمالك يجبالواردة في سمة الاسم المستعار.

يحول استخدام إحدى هذه السمات دون استخدام الأخرى.

باقي السمات اختيارية.

"إذا لزم الأمر ، تشير شهادة مفتاح التوقيع ، على أساس المستندات الداعمة ، إلى الموقف (مع اسم وموقع المنظمة التي تم إنشاء هذا المنصب فيها) ..." (المادة 6 ، البند 2).

لقب حامل الشهادة يجبالمحدد في سمة العنوان. قيمة السمة يجبتتوافق مع الإدخال في المستندات التي تؤكد الوظيفة المحددة لحامل الشهادة.

سمة العنوان ، وفقًا لـ RFC 3039 ، يجبيتم تضمينها في ملحق subjectDirectoryAttributes. ومع ذلك ، يسمح هذا المستند (و RFC 3280) بتضمينه في حقل الموضوع.

مطلوب عند استخدام سمة العنوان يجبتشمل السمات التي تصف اسم وموقع المنظمة التي تم إنشاء المنصب فيها.

اسم الشركة يجبالمحدد في سمة OrganizationName. قيمة السمة يجبيتطابق مع اسم المنظمة في التأسيس أو المستندات المماثلة الأخرى. عند استخدام سمة OrganizationName يمكنيتم أيضًا استخدام السمة organizationUnitName.

موقع المنظمة يمكنيتم تحديدها باستخدام مجموعة من سمات اسم البلد أو stateOrProvinceName أو localityName (كل منها اختياري) أو باستخدام سمة postalAddress واحدة.

السمة postalAddress ، إذا تم استخدامها ، يجبتحتوي على العنوان القانوني للمنظمة أو عنوان إقامة صاحب شهادة مفتاح التوقيع (للفرد).

إذا كانت السمة OrganizationName موجودة ، فإن سمات countryName و stateOrProvinceName و localityName و postalAddress يجبيتم تفسيره على أنه موقع المنظمة.

السمات الاختيارية لحقل الموضوع (countryName ، stateOrProvinceName ، localityName ، OrganizationName ، organizationUnitName ، العنوان ، postalAddress) مايويتم تضمينها ، إذا تم تحديدها من قبل لوائح CA ، بدلاً من حقل الموضوع في ملحق subjectDirectoryAttributes (انظر الفقرة 3.8.1). في هذه الحالة هم لا يجبأن تدرج في الموضوع و لا تستطيعتستخدم للتمييز بين مالكي شهادات مفتاح التوقيع.

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

سمة serialNumber يمكن:

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

الإضافات المطلوبة
يجبتشمل الامتدادات التالية:
- KeyUsage (معرف CE 15)
- سياسات الشهادات (id-ce 32)
1. KeyUsage
  من أجل استخدام الشهادة للتحقق من التوقيع الرقمي ، في keyUsage extension يجبيجب تعيين بت التوقيع الرقمي (0) و nonRepuduation (1).
  سياسات الشهادات
  يهدف ملحق CertificatePolicies إلى تحديد نطاق التطبيق القانوني ذي الصلة للشهادة.
  "... اسم أدوات EDS التي يتم من خلالها استخدام هذا المفتاح العمومي ..." (المادة 6 ، البند 1 ، الفقرة 4) ، "... معلومات حول العلاقة في تنفيذ وثيقة إلكترونية مع الكتروني توقيع إلكترونيسيكون لها أهمية قانونية ... "(المادة 6 ، البند 1 ، الفقرة 6) والبيانات الأخرى التي تنظم إجراءات الحصول على شهادات مفتاح التوقيع واستخدامها ، يمكن ان يكونمتاح في CPSuri (بيان ممارسة الشهادة URI) المحدد في هذا الامتداد.

ملحقات اختيارية
كجزء من شهادة مفتاح التوقيع مايوتشمل أي ملحقات أخرى. عند تضمين ملحقات في شهادة مفتاح EDS ، من الضروري ضمان اتساق وعدم غموض المعلومات المقدمة في الشهادة.
لا تحدد هذه الوثيقة استخدام امتدادات أخرى غير ملحق subjectDirectoryAttributes (id-ce 9).

SubjectDirectoryAttributes. موضوع_الدليل_السمات
ملحق subjectDirectoryAttributes يمكنتحتوي على سمات تكمل المعلومات المقدمة في حقل الموضوع.
بالإضافة إلى السمات المدرجة في RFC 3039 ، يوصى بدعم السمات التالية في ملحق subjectDirectoryAttributes:

المؤهل	{-}
اسم الدولة	(معرف في 6)
اسم الولاية أو المقاطعة	(معرف في 8)
الاسم المحلي	(معرف في 7)
اسم المنظمة	(معرف في 10)
التنظيمي اسم وحدة	(معرف في 11)
لقب	(معرف في 12)
العنوان البريدي	(معرف في 16)

"إذا لزم الأمر ، تشير شهادة مفتاح التوقيع ، على أساس المستندات الداعمة ، إلى ... مؤهلات مالك شهادة مفتاح التوقيع" (المادة 6 ، البند 2).

بيانات عن أهلية مالك شهادة مفتاح EDS يجبالمحدد في سمة التأهيل. هذه السمة غير معرّفة في التوصيات الدولية (انظر البند 2) وهي خاضعة للتسجيل.

إذا تم تضمين سمات countryName ، أو stateOrProvinceName ، أو localityName ، أو OrganizationName ، أو organizationUnitName ، أو العنوان ، أو postalAddress في ملحق subjectDirectoryAttributes ، لا يجبيتم تضمينها في مجال الموضوع.

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

تطبيق ASN1

معرف في:قيمة OID: 2.5.4
وصف معرف الكائن:أنواع سمات X.500.
معرف- م:قيمة OID: 2.5.29
وصف معرف الكائن:معرّف الكائن لملحقات شهادة الإصدار 3.

2.5.4.5 رقم التعريف في المسلسل SerialNumber ATTRIBUTE :: = (WITH SYNTAX PrintableString (SIZE (1..64)) EQUALITY MATCHING RULE caseIgnoreMatch SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch ID ID-at-serialNumber)

(RFC 3039)
يجب استخدام نوع سمة serialNumber ، عند وجوده ، للتمييز بين الأسماء حيث يكون حقل الموضوع متطابقًا. لا تحتوي هذه السمة على دلالات محددة بخلاف ضمان تفرد أسماء الموضوعات. قد يحتوي على رقم أو رمز تم تعيينه من قبل المرجع المصدق أو معرف معين من قبل الحكومة أو السلطة المدنية. تقع على عاتق المرجع المصدق مسؤولية التأكد من أن الرقم التسلسلي كافٍ لحل أي تضارب في اسم الموضوع.

2.5.4.3 - id-at-commonName

قيمة OID: 2.5.4.3

وصف معرف الكائن:يحدد نوع سمة الاسم الشائع معرفًا لكائن. الاسم الشائع ليس اسم دليل ؛ إنه اسم (ربما يكون غامضًا) يُعرف به الكائن بشكل عام في نطاق محدود (مثل منظمة) ويتوافق مع اصطلاحات التسمية للبلد أو الثقافة التي يرتبط بها.

CommonName ATTRIBUTE :: = (نوع فرعي من الاسم مع معرف سلسلة دليل SYNTAX (الاسم الشائع ub) (id-at-commonName))

(RFC 3039: ملف تعريف الشهادة المؤهل)
قيمة OID: 2.5.4.65

اسم مستعار ATTRIBUTE :: = (نوع فرعي من الاسم مع معرف سلسلة دليل SYNTAX (معرف في اسم مستعار))

قيمة معرف الكائن: 2.5.29.17

وصف معرف الكائن: id-ce-subjectAltName يحتوي هذا الامتداد على واحد أو أكثر من الأسماء البديلة ، باستخدام أي مجموعة متنوعة من نماذج الأسماء ، للكيان المرتبط من قبل المرجع المصدق بالمفتاح العام المعتمد.

ملحق SubjectAltName :: = (SYNTAX GeneralNames IDENTIFIED BY id-ce-subjectAltName) GeneralNames :: = SEQUENCE SIZE (1..MAX) Of GeneralName GeneralName :: = CHOICE (otherName INSTANCE OF OTHER-NAME، rfc822Name IA5String، dNSName IA5String، ( *) x400Address ORAddress ، اسم الدليل ، ediPartyName EDIPartyName ، uniformResourceIdentifier IA5String ، IPAddress OCTET STRING ، معرف الكائن المسجل معرف) (*) - سلسلة عشوائية. OTHER-NAME :: = SEQUENCE (type-id معرف الكائن قيمة توضح أي معرف بواسطة type-id)

قيمة OID: 2.5.4.16

وصف معرف الكائن:يحدد نوع سمة العنوان البريدي معلومات العنوان للتسليم الفعلي للرسائل البريدية بواسطة السلطة البريدية إلى الكائن المحدد. ستتكون قيمة سمة العنوان البريدي عادةً من السمات المحددة من الإصدار 1 لعنوان O / R البريدي غير المنسق من MHS وفقًا لـ CCITT Rec F.401 ومحدودة بـ 6 أسطر من 30 حرفًا لكل منها ، بما في ذلك اسم البلد البريدي. عادةً ما تتضمن المعلومات الواردة في هذا العنوان اسم المرسل إليه وعنوان الشارع والمدينة والولاية أو المقاطعة والرمز البريدي وربما رقم صندوق البريد اعتمادًا على المتطلبات المحددة للكائن المحدد.

PostalAddress ATTRIBUTE :: = (مع SYNTAX PostalAddress EQUALITY MATCHING RULE caseIgnoreListMatch SUBSTRINGS MATCHING RULE caseIgnoreListSubstringsMatch ID id-at-postalAddress) PostalAddress :: = SEQUENCE SIZE (1..ub-postal-string) OF Directory

قيمة OID: 2.5.4.12

وصف معرف الكائن:يحدد نوع سمة العنوان الموضع المعين أو وظيفة الكائن داخل المؤسسة. قيمة سمة العنوان هي سلسلة.

العنوان ATTRIBUTE :: = (نوع الاسم مع سلسلة دليل SYNTAX (العنوان الفرعي) ID-at-title) id-ce-CertificatePolicies OBJECT IDENTIFIER :: = (id-ce 32) CertificatePolicies :: = SEQUENCE SIZE (1 .. MAX) OF PolicyInformation PolicyInformation :: = SEQUENCE (policyIdentifier CertPolicyId ، policyQualifiers SEQUENCE SEQUENCE (1..MAX) OF PolicyQualifierInfo OPTIONAL) CertPolicyId :: = معرّف الهدف PolicyQualifierInfo :: = SEQUENCE (policyQualifierIfoED policy) لمؤهلات سياسة الإنترنت id-qt معرف الكائن :: = (id-pkix 2) id-qt-cps معرف الكائن :: = (id-qt 1) id-qt-unotice معرف الكائن :: = (id-qt 2) PolicyQualifierId :: = معرف الكائن (id-qt-cps | id-qt-unotice) المؤهل :: = الاختيار (cPSuri CPSuri ، userNotice UserNotice) CPSuri :: = IA5String UserNotice :: = SEQUENCE (إشعار نصي صريح عرض مرجعي اختياري) NoticeReference :: = SEQUENCE (organi zation DisplayText ، noteNumbers SEQUENCE OF INTEGER) DisplayText :: = CHOICE (visualString VisibleString (SIZE (1..200)) ، bmpString BMPString (SIZE (1..200)) ، utf8String UTF8String (SIZE (1..200)))

فاديم مليخ
02.10.2013

منذ بعض الوقت ، في مجموعة Forum Rus على Facebook ، كان هناك نقاش حول استخدام نظم المعلوماتأه السلطات (المناقشة كانت خارج الموضوع ، يمكنك رؤيتها في التعليقات أدناه). يرجع جوهر النزاع إلى معرفات الكائن (معرف الكائن - معرف الكائن) لأنظمة المعلومات التي يجب تسجيلها في شهادات التوقيع الإلكتروني المؤهلة (ES) المسؤولين، يجب تغيير هذه المعايير البيئية نفسها أكثر من مرة في السنة (وهو ما تمليه متطلبات الأمن) ، وهذا بدوره يؤدي إلى صعوبات وتكاليف إضافية ، حيث تعمل معظم السلطات مع CA التجارية دون أن يكون لديها سلطات خاصة بها. تتفاقم المشكلة بسبب عدم وجود فهم مشترك لما توفره معرفات الكائن بالضبط ومدى ضرورتها و / أو إلزامية.

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

بدءًا من المفاهيم الأساسية ، يعتمد التوقيع الإلكتروني على خوارزميات التشفير غير المتماثل. الميزة الرئيسية لهذه الخوارزميات هي استخدام مفتاحين مختلفين لتشفير وفك تشفير رسالة. عامة الناس أكثر دراية بالخوارزميات المتماثلة ، عندما نقوم بتشفير وفك تشفير رسالة بنفس المفتاح (أو كلمة المرور) ، على سبيل المثال ، نقوم بأرشفة ملف بكلمة مرور أو حماية مستند MS Word.

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

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

كيف يعمل كل شيء ، باختصار. نأخذ خوارزمية تشفير غير متماثل ، وننشئ زوج مفاتيح (للتشفير وفك التشفير). نعطي مفتاح التشفير للشخص الذي سيوقع المستندات. يجب عليه دائمًا الاحتفاظ بها معه وعدم إعطائها لأي شخص. لذلك ، يطلق عليه المفتاح "الخاص". نعطي مفتاحًا آخر (فك التشفير) للجميع ، لذا فهو "مفتوح". عند التوقيع على مستند ، يجب على الشخص تشفيره بمفتاحه الخاص. ليس المستند نفسه مشفرًا بالفعل ، نظرًا لأنه يمكن أن يكون كبيرًا جدًا ، ولا نحتاج في الواقع إلى تشفيره. لذلك ، يتم الحصول على تجزئة للمستند - وهذا تسلسل رقمي معين بدرجة عالية من الاحتمالية تختلف باختلاف المستندات ، مثل "بصمة" المستند. يتم تشفيرها بالمفتاح الخاص للموقِّع. هذه التجزئة المشفرة هي التوقيع الإلكترونيوثيقة. الآن ، بعد الحصول على مستند وتوقيع ومفتاح عام ، يمكن لأي شخص التحقق بسهولة من أن هذا المستند المعين قد تم توقيعه باستخدام هذا المفتاح الخاص المحدد. للقيام بذلك ، نحصل مرة أخرى على تجزئة المستند ، ونفك تشفير التوقيع بالمفتاح العام ونقارن. يجب الحصول على تسلسلين رقميين متطابقين.

كل هذا رائع ، لكن حتى الآن حصلنا على عدم التنصل من توقيع المفتاح الخاص ، أي أننا أثبتنا أن المستند موقّع بواسطة مفتاح محدد. نحتاج إلى إثبات أنه تم التوقيع عليه من قبل شخص معين. للقيام بذلك ، توجد مراكز شهادات وشهادات رقمية. أهم شيء تفعله المرجع المصدق هو أنه يشهد أن المفتاح الخاص ينتمي إلى شخص معين. ولضمان ذلك ، فإن مركز الشهادات هو الذي ينشئ أزواج المفاتيح ويصدرها شخصيًا للمالكين (هناك خيارات بالوكيل ، عن بُعد ، ولكن هذه تفاصيل). جنبًا إلى جنب مع المفاتيح ، يتم إنشاء شهادة رقمية - وهي وثيقة إلكترونية (أحيانًا تمثيلها الورقي) ، والتي تحتوي على معلومات حول مالك المفتاح ، والمفتاح نفسه ، والمرجع المصدق وبعض المعلومات الأخرى. يتلقى المالك ، كقاعدة عامة ، كل هذا الخير على وسيط آمن (البطاقة الذكية ، ru-token ، وما إلى ذلك) ، والذي يحتوي على مفتاح خاص وشهادة مع مفتاح عام مضمن. يجب دائمًا الاحتفاظ بالناقل نفسه معك ، ويمكن منح شهادة المفتاح العام المنسوخة منه للجميع حتى يتمكنوا من التحقق من توقيعك الإلكتروني.

لذلك ، يتم التوقيع باستخدام مفتاح خاص ، والتحقق من التوقيع باستخدام مفتاح عام. لذلك ، فإن عبارة "تم توقيع المستند بواسطة مجموعة معرفات الكائن" (التي ظهرت في النزاع أعلاه) لا معنى لها. يتم تضمين مفتاحين فقط في إجراء التوقيع والتحقق ، في 63-FZ يتم تسميتهما وفقًا لذلك - مفتاح التوقيع ومفتاح التحقق من التوقيع.

وما هي OIDs سيئة السمعة؟ يسمح تنسيق الشهادة الرقمية X.509 بتخزين الامتدادات فيه. هذه بعض السمات الاختيارية التي يمكن استخدامها لتخزين معلومات إضافية. كل سمة من هذا القبيل هي كائن يتم تحديده بواسطة معرف من الدليل الهرمي. ومن ثم OID - معرف الكائن. ليس من المنطقي الخوض في طبيعة معرّفات الكائن الحي نفسها. في الواقع ، هذه بعض المعلومات الإضافية التي قد تكون موجودة في الشهادة.

يمكن استخدام هذه السمات الإضافية لأغراض مختلفة. يمكنهم إما تقديم معلومات إضافية حول المالك أو المفاتيح أو CA أو حمل بعض المعلومات الإضافية للتطبيقات والخدمات التي تستخدم هذه الشهادة. الاستخدام الأكثر شيوعًا هو التحكم في الوصول المستند إلى الدور. على سبيل المثال ، يمكن أن يُذكر في الشهادة أن مالك المفتاح هو رئيس المنظمة ، وهذا سيمنحه الفرصة للوصول فورًا إلى الوظائف والمعلومات الضرورية في جميع أنظمة المعلومات ، دون الحاجة إلى الاتصال بمسؤولي كل منها هو وتغيير إعدادات الوصول. كل هذا ، بالطبع ، شريطة أن تستخدم جميع ISs شهادة المستخدم للترخيص وأن تحلل نفس السمة بنفس الطريقة (لهذا السبب ، يتم تحديد السمات من الدليل ، وليس تعيينها بشكل تعسفي).

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

في العالم ، يُطلق على هذين النوعين من الشهادات على التوالي شهادة المفتاح العام (PKC) وشهادة السمة (أو شهادة التفويض - AC). يمكن إصدار شهادة من النوع الثاني في كثير من الأحيان أكثر من الأولى ، من قبل منظمة أخرى ، وينبغي أن يكون الوصول إليها أسهل وأسهل في الحصول عليها من شهادة "المفتاح العام" الشخصية. على أي حال ، هذا ما يوصي به RFC 3281 ، المخصص لهذا النوع من الشهادات. يجب أن تحتوي الشهادة من النوع الثاني فقط على رابط لشهادة المفتاح العام بحيث يمكن للنظام الذي يستخدمها لتفويض المستخدم التعرف أولاً على الشخص الذي يستخدم PKC.

الآن دعنا نقترب من واقعنا. على المستوى التشريعي ، القضايا المتعلقة باستخدام التوقيعات الإلكترونية في الاتحاد الروسي، ينظمها وثيقتان رئيسيتان - قانون الاتحاد الروسي بتاريخ 04/06/2011 رقم 63-FZ "بشأن التوقيع الإلكتروني" وأمر دائرة الأمن الفيدرالي للاتحاد الروسي بتاريخ 27/12/2011 رقم. 795 "عند الموافقة على متطلبات النموذج شهادة مؤهلةمفتاح التحقق من التوقيع الإلكتروني. يتم وصف تكوين الشهادة المؤهلة بالترتيب 795 (الجزء الثاني "متطلبات مجموعة حقول الشهادة المؤهلة") ولا تحتوي على متطلبات للسمات التي تتحكم في التفويض في أي أنظمة معلومات. كسمات إلزامية إضافية ، يتم تحديد المعلومات فقط التي تسمح لك بتحديد ملف كيانفي الاتحاد الروسي (TIN ، SNILS ، إلخ). على الرغم من أن لا القانون ولا نظام FSB يحظران إدراج معلومات أخرى في شهادة مؤهلة.

كما ترى ، لا توجد قواعد تشريعية تملي الوجود الإلزامي في شهادة مؤهلة للسمات المتعلقة بالتفويض في أي أنظمة معلومات. من أين تأتي هذه المتطلبات؟ وهم يأتون من مطورين (أو "مالكين") أنظمة محددة. لنأخذ على سبيل المثال "إرشادات لاستخدام التوقيع الإلكتروني في التفاعل الإلكتروني بين الإدارات (الإصدار 4.3)" ، المنشورة على بوابة التكنولوجيا SMEV. في الواقع ، في الفقرة 6 من هذه الوثيقة نقرأ: "عند إعداد المعلومات لتشكيل شهادة EP-SP ، من الضروري تحديد الحاجة إلى طلب معلومات من Rosreestr (مقتطف من USRR). إذا كان هذا الطلب ضروريًا ، فيجب الإشارة إلى معرف الكائن في حقل "المفتاح المحسن" (OID = 2.5.29.37) في شهادة ES-SP وفقًا لمتطلبات Rosreestr. ". أي أن نظام معلومات Rosreestr يستخدم هذه السمة لتحديد المعلومات التي يمكن إصدارها لمالك الشهادة. ومع ذلك ، تحتوي الوثيقة نفسها على ملاحظة مهمة ، وهي أن هذا المطلب ساري المفعول حتى الإطلاق الكامل لـ ESIA (خدمة التفويض الفردي في أنظمة الدولة) وربط نظام Rosreestr بها. هذه ملاحظة مهمة ، ضعها في اعتبارك.

لن أتعامل مع عناوين IP الأخرى المستخدمة في الدولة. الأعضاء. أظن أن الوضع مشابه. بوابة المشتريات العامة الإلكترونية منصات التداول، قد تتطلب التطبيقات المحاسبية والمالية المختلفة أيضًا وجود بعض معرفات الكائن الإضافية في شهادة المستخدم. في الوقت نفسه ، فإن البيان القائل بأنه من خلال كتابة معرف الكائن لنظام المعلومات في الشهادة ، فإنني أفوض المسؤولية بطريقة ما إلى مركز الشهادات ، بعبارة ملطفة ، غير صحيح. يقوم المرجع المصدق (CA) بإدخال هذه البيانات في الشهادة وفقًا لطلبي. إذا تغير موقفي ، ونسيت التقدم بطلب لإلغاء القديم وإصدار شهادة جديدة ، لا يمكن تحميل CA مسؤولية نسياني. بالإضافة إلى ذلك ، يعهد القانون 63-FZ مباشرة بمسؤولية الاستخدام غير الصحيح للشهادة إلى مالكها. في الفقرة 6 من المادة 17 نقرأ:
يجب على حامل الشهادة المؤهلة:
1) لا تستخدم مفتاح التوقيع الإلكتروني واتصل على الفور بمركز التصديق المعتمد الذي أصدر الشهادة المؤهلة لإنهاء هذه الشهادة إذا كان هناك سبب للاعتقاد بانتهاك سرية مفتاح التوقيع الإلكتروني ؛
2) استخدم توقيعًا إلكترونيًا مؤهلًا وفقًا للقيود الواردة في الشهادة المؤهلة (إذا تم وضع هذه القيود).

تؤدي الحاجة إلى تخزين معلومات في الشهادة حول أدوار المستخدم ووصوله في أنظمة معلومات محددة إلى مشكلة تسببت في نزاع على Facebook ، وهي أنه يجب إعادة إصدار الشهادة في كثير من الأحيان أكثر مما تمليه متطلبات الأمان للتوقيع الإلكتروني الشخصي. . لقد تغير الموقف - نعيد إصدار الشهادة. ظهر IS جديد - نعيد إصدار الشهادة. كانت هناك حاجة لطلب معلومات من IS لمنظمة جديدة (Rosreestr) - نعيد إصدار الشهادة.

هناك نسبة 100٪ في المفهوم المسمى في شهادة السمة العالمية (أو شهادة التفويض) ، والتي تم ذكرها أعلاه والتي يوصى فيها بإصدار هذه الشهادات من قبل مرجع مصدق آخر (Attribute Autority ، على عكس المرجع المصدق - مرجع مصدق (CA) عادي يصدر شهادات ES مؤهلة) وبطريقة مبسطة. يجب ألا تحتوي هذه الشهادة نفسها على مفتاح توقيع إلكتروني ومعلومات عن المالك. بدلاً من ذلك ، يحتوي على رابط إلى شهادة المفتاح العام للمالك ، والتي يمكنك من خلالها الحصول على بقية المعلومات الضرورية حول الشخص.

تجدر الإشارة إلى أن هذا المخطط له أيضًا تطبيق محدود للغاية ولا يحل جميع المشكلات. ماذا لو قرر نظام المعلومات التالي استخدام نفس حقل الشهادة "المفتاح المحسن" (OID = 2.5.29.37) ، المشغول بالفعل بواسطة قيمة Rosreestr ، لاحتياجاته الخاصة؟ لن يعمل إدخال قيمتين مختلفتين في حقل واحد. لذلك ، سيتعين علينا إطلاق تيار متردد آخر! هناك مشكلة أخرى تتعلق بالعمر القصير لـ PKC (سنة واحدة). إذا كان لدينا العديد من ACs (التي تحتوي على رابط لشهادة شخصية) ، فسيتعين إعادة إصدارها جميعًا بعد انتهاء صلاحية PKC. من أجل الاستخدام الفعال للتيار المتردد ، يلزم وجود مركز ترخيص مستخدم واحد في جميع أنظمة المعلومات ، ويجب أن تستخدم جميع التطبيقات سمات الشهادة بطريقة متسقة وموحدة.

مثل هذا مركز تفويض واحد للدولة. السلطات موجودة بالفعل - هذا هو تقييم الأثر البيئي والاجتماعي. أذكر المذكرة المتعلقة بمعرفات OID الخاصة بـ Rosreestr. في المستقبل ، سيتم استبدالها بمعلومات من ESIA. يجب أيضًا أن تفعل أنظمة المعلومات الأخرى التي يعمل فيها موظفو الخدمة المدنية نفس الشيء. بدلاً من استخدام AC للحصول على إذن ، من الضروري التكامل مع ESIA وتلقي المعلومات اللازمة من هناك ، يجب أن يكون تقييم الأثر البيئي والاجتماعي قادرًا على ربط شهادة ES مؤهلة بحساب ما ، بحيث تكون أنظمة المعلومات قادرة على مصادقة المستخدم باستخدام مفتاح شخصي ، وتفويضه (توفير الوصول إلى التطبيق) من خلال ESIA. يبدو أن مثل هذا النظام أكثر شمولية وموثوقية من استخدام حقول الشهادات ، وفي المستقبل ، سوف يعمل على أتمتة إدارة الوصول ، إذا تم إنشاء نظام موحد لسجلات الموظفين لموظفي الخدمة المدنية ، فسيكون تقييم الأثر البيئي والاجتماعي (ESIA) قادرًا على الحصول على معلومات حول صلاحيات شخص ما مباشرة من هناك. نقل شخص إلى منصب آخر - فقد الوصول تلقائيًا إلى نظام واكتسب نظامًا آخر استمر في استخدام مفتاح ES الخاص به لتوقيع المستندات ، فلا داعي لإعادة إصدار أي شيء.

وفقًا للشروط الفنية لـ CJSC AEI PRIME للإفصاح عن المعلومات المتعلقة بالأوراق المالية والأدوات المالية الأخرى المعتمدة من قبل بنك روسيا () ، المستندات الإلكترونيةالتي تحتوي على معلومات عامة يجب أن يتم توقيعها بواسطة موضوع الكشف عن المعلومات بتوقيع إلكتروني مؤهل محسن (انظر الفقرة 1.7 من الشروط الفنية). يسري هذا المطلب اعتبارًا من 1 فبراير 2017.

حاليًا ، بدأت فترة اختبار لاستخدام التوقيع الإلكتروني على خادم الإفصاح PRIME ، والتي ستستمر حتى 31 يناير 2017 ضمناً.

لاختبار الوظيفة ، يمكن لعملاء PRIME استخدام أي شهادة مفتاح ES تم استلامها مسبقًا لهذا الكيان القانوني.

اعتبارًا من 1 فبراير 2017 ، بناءً على طلب الشروط الفنية (انظر البندين 1.7. و 9.6.) ، يجب أن تتوافق الشهادة المؤهلة لمفتاح التحقق من التوقيع الإلكتروني للمستخدم مع متطلبات نموذج الشهادة المؤهلة التي تم إنشاؤها بأمر من خدمة الأمن الفيدرالية لروسيا بتاريخ 27 ديسمبر 2011 برقم 795 "بشأن متطلبات الموافقة على نموذج الشهادة المؤهلة لمفتاح التحقق من التوقيع الإلكتروني. يجب أن يحتوي ملحق شهادة المستخدم "المفتاح المحسن" (معرف الكائن 2.5.29.37) على معرف كائن للكشف عن المعلومات PRIME - معرف الكائن 1.2.643.6.42.5.5.5

تسجيل الدخول إلى الحساب الشخصي لمستخدم الإفصاح عن المعلومات "PRIME" سيتم تنفيذه باستخدام LOGIN و PASSWORD الذي استلمه العميل مسبقًا.

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

لاستخدام ES على خادم الكشف عن معلومات PRIME ، يجب على العميل أولاً تثبيت المكون الإضافي (التثبيت مجاني للمستخدمين ولا يستغرق الكثير من الوقت). انظر تعليمات تثبيت البرنامج المساعد أدناه.

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

بعد توقيع الرسالة بتوقيع إلكتروني ، يجب على العميل النقر فوق الزر "نشر"
بعد توقيع المستند بتوقيع إلكتروني ، يجب على العميل النقر فوق الزر "إضافة مستند".
بعد التوقيع على التغييرات في بطاقة التسجيل بتوقيع إلكتروني ، يجب على العميل النقر فوق الزر "إرسال نموذج التعريف".

يرجى ملاحظة أن جميع الرسائل المرسلة من قبل العملاء من خلال حساباتهم الشخصية من خلال ترخيص "تسجيل الدخول التجريبي (العمل مع ES)" سيتم نشرها في موجز الكشف عن المعلومات في وضع العمل. سيتم نشر جميع المستندات التي يضعها العملاء من خلال حساباتهم الشخصية من خلال إذن "إدخال الاختبار (العمل مع ES)" تلقائيًا على صفحات المصدرين في وضع العمل.

خلافًا لذلك ، لن يتغير الإجراء الخاص بإجراءات المُصدر في الحساب الشخصي على خادم الكشف عن معلومات PRIME.