ลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง - ปัญหาของ OID ของระบบสารสนเทศ ลายเซ็นไม่ถูกต้อง การตรวจสอบลายเซ็นล้มเหลว ตัวระบุอ็อบเจ็กต์หายไป OID การถอดรหัส Oid

เมื่อคุณเข้าสู่บัญชีส่วนตัวของคุณเพื่อขอ QEP ข้อความจะปรากฏขึ้น « ไม่ได้กำหนดค่าคอมพิวเตอร์ . ไปที่หน้าการตั้งค่าคอมพิวเตอร์และทำตามขั้นตอนที่แนะนำ » . หลังจากไปที่หน้าการตั้งค่าและติดตั้งส่วนประกอบที่จำเป็นทั้งหมดใน บัญชีส่วนตัวข้อความแจ้งว่าคอมพิวเตอร์ไม่ได้รับการกำหนดค่าอีกปรากฏขึ้น

เพื่อแก้ไขข้อผิดพลาด คุณต้อง:

1. เพิ่มที่อยู่ของบัญชีส่วนตัวของคุณ https://i.kontur-ca.ru ไปยังไซต์ที่เชื่อถือได้ สำหรับสิ่งนี้:

• เลือกเมนู "เริ่ม" > "แผงควบคุม" > "ตัวเลือกอินเทอร์เน็ต";
• ไปที่แท็บ "ความปลอดภัย" เลือกองค์ประกอบ "ไซต์ที่เชื่อถือได้" (หรือ "ไซต์ที่เชื่อถือได้") และคลิกที่ปุ่ม "โหนด"
• ระบุที่อยู่โหนดต่อไปนี้ https://i.kontur-ca.ru ในช่อง Add to zone และคลิกปุ่ม Add

หากที่อยู่นี้อยู่ในรายการไซต์ที่เชื่อถือได้แล้ว ให้ไปที่ขั้นตอนถัดไป

2. ตรวจสอบว่าที่อยู่ของบัญชีส่วนตัว https://i.kontur-ca.ru ถูกกำหนดว่าเชื่อถือได้:

• หากใช้ Internet Explorer เวอร์ชัน 8 เมื่ออยู่ในหน้าการให้สิทธิ์ คุณควรตรวจสอบว่าช่องทำเครื่องหมาย Trusted Sites อยู่ที่ด้านล่างของหน้าหรือไม่ หากไม่มีช่องทำเครื่องหมาย แต่มีจารึก « อินเทอร์เน็ต” ดังนั้นที่อยู่ https://i.kontur-ca.ru ไม่ได้ถูกเพิ่มลงในไซต์ที่เชื่อถือได้

• หากใช้ Internet Explorer เวอร์ชัน 9 ขึ้นไป เมื่ออยู่ในหน้าการให้สิทธิ์ คุณควรคลิกขวาที่ใดก็ได้บนหน้า เลือก "คุณสมบัติ" ในหน้าต่างที่เปิดขึ้น บรรทัด "โซน" ควรมีข้อความว่า "ไซต์ที่เชื่อถือได้" มิฉะนั้น ที่อยู่ https://i.kontur-ca.ru จะไม่ถูกเพิ่มไปยังไซต์ที่เชื่อถือได้

หากที่อยู่บัญชีส่วนตัวไม่ได้กำหนดว่าเชื่อถือได้ คุณควรติดต่อผู้ดูแลระบบเพื่อขอให้เพิ่มที่อยู่ https://i.kontur-ca.ru ไปยังโหนดที่เชื่อถือได้

3. ตรวจสอบว่าคุณสามารถเข้าสู่ระบบบัญชีส่วนตัวของคุณได้หรือไม่ หากข้อผิดพลาดเกิดขึ้นซ้ำ คุณควรเรียกใช้ยูทิลิตี้ RegOids จากลิงก์ ยูทิลิตีนี้จะกำหนดการตั้งค่า OID ในรีจิสทรีของคอมพิวเตอร์โดยอัตโนมัติ คุณยังสามารถนำเข้าหนึ่งในสาขาของรีจิสทรีได้ด้วยตนเอง ขึ้นอยู่กับจำนวนบิตของระบบปฏิบัติการที่ติดตั้ง:

4. ตรวจสอบว่าคอมพิวเตอร์ใช้สิทธิ์ของผู้ดูแลระบบ (เพื่อตรวจสอบ ให้ไปที่ เริ่ม - แผงควบคุม - บัญชีผู้ใช้และความปลอดภัยของครอบครัว - บัญชีผู้ใช้). หากสิทธิ์ไม่เพียงพอ คุณต้องให้สิทธิ์แก่ผู้ใช้ทั้งหมด สำหรับสิ่งนี้ โปรดติดต่อผู้ดูแลระบบของคุณ

5. หลังจากเสร็จสิ้นขั้นตอนที่ 3 จำเป็นต้องรีสตาร์ทคอมพิวเตอร์และตรวจสอบการเข้าสู่บัญชีส่วนบุคคล

หากไม่มีคำแนะนำใดที่ช่วย คุณควรติดต่อ การสนับสนุนทางเทคนิคตามที่อยู่ [ป้องกันอีเมล]จดหมายต้องระบุว่า:

1. หมายเลขวินิจฉัย

ในการดำเนินการนี้ คุณต้องไปที่พอร์ทัลการวินิจฉัยที่https://help.kontur.ru , กดปุ่ม "เริ่มการวินิจฉัย » . เมื่อกระบวนการตรวจสอบเสร็จสิ้น หมายเลขการวินิจฉัยจะแสดงบนหน้าจอ ระบุหมายเลขอ้างอิงที่กำหนดในจดหมาย

2. ภาพหน้าจอของหน้าต่างที่มีข้อผิดพลาด (เมื่อใช้ Internet Explorer เวอร์ชัน 9 ขึ้นไป คุณต้องแนบภาพหน้าจอของหน้าต่าง "คุณสมบัติ" ด้วย - ดูจุดที่ 2)

3. ส่งออกและแนบสาขารีจิสทรีต่อไปนี้:

32 บิต: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo
64 บิต: HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo

1. ข้อกำหนดทั่วไป

   ทางเลือกของวิธีการนำเสนอข้อมูลบางอย่างและข้อจำกัดเพิ่มเติมเกี่ยวกับองค์ประกอบของฟิลด์ใบรับรองขึ้นอยู่กับหลักการต่อไปนี้:

   การนำเสนอข้อมูลในใบรับรองควรเรียบง่ายและชัดเจนอย่างยิ่งเพื่อแยกออก ตัวเลือกต่างๆการตีความเอกสารอยู่ในขั้นตอนของการพัฒนาแอปพลิเคชันแล้ว

   ข้อกำหนดที่ร่างขึ้นในลักษณะนี้ควรปล่อยให้มีอิสระที่จำเป็นในการรวมข้อมูลเพิ่มเติมของประเภทที่กำหนดเองในใบรับรอง เฉพาะสำหรับพื้นที่เฉพาะของแอปพลิเคชันของใบรับรองคีย์ EDS

   องค์ประกอบของเขตข้อมูลและรูปแบบการนำเสนอข้อมูลในใบรับรองต้องเป็นไปตามคำแนะนำระหว่างประเทศ (ดูข้อ 2) โดยที่ไม่ขัดต่อข้อกำหนดของกฎหมาย EC

   ใบรับรองที่ออกให้จะใช้ใน Internet PKI และระยะเวลาที่ใช้งานได้ของคีย์สาธารณะและคีย์ส่วนตัวสำหรับระบบดังกล่าวจะถือว่าเหมือนกันตาม RFC 3280 (4.2.1.4) และไม่ควรรวมแอตทริบิวต์ระยะเวลาการใช้งานคีย์ส่วนตัวไว้ในใบรับรอง

2. คำแนะนำระหว่างประเทศ เอกสารนี้ได้รับการพัฒนาโดยคำนึงถึงข้อเสนอแนะระหว่างประเทศ:
   • RFC 3280 (กำลังอัปเดต RFC 2459) Internet X.509 Public Key Infrastructure โปรไฟล์ใบรับรองและรายการเพิกถอนใบรับรอง (CRL)
   • โครงสร้างพื้นฐานคีย์สาธารณะ RFC 3039 Internet X.509 โปรไฟล์ใบรับรองที่ผ่านการรับรอง - RFC นี้เสนอ ข้อกำหนดทั่วไปกับไวยากรณ์ (องค์ประกอบ) ของใบรับรองซึ่งการใช้งานมีความสำคัญทางกฎหมาย
3. องค์ประกอบและวัตถุประสงค์ของฟิลด์ใบรับรอง

   ส่วนนี้ให้คำอธิบายของฟิลด์หลักของใบรับรองคีย์สาธารณะที่สอดคล้องกับกฎหมาย "ในลายเซ็นดิจิทัลอิเล็กทรอนิกส์" ลงวันที่ 10.01.2002

   แนวคิด สัญกรณ์ และคำศัพท์ที่ใช้ในส่วนนี้อ้างอิงจาก RFC 3280 และ RFC 3039 ซึ่งในทางกลับกัน เป็นไปตามคำแนะนำของ ITU-T X.509 เวอร์ชัน 3 เนื้อหาของส่วนนี้ไม่ได้คัดลอกเนื้อหาของเอกสารเหล่านี้ แต่ระบุเฉพาะความแตกต่างและคุณสมบัติของการใช้ใบรับรองภาคสนามที่ใช้ข้อกำหนดสำหรับองค์ประกอบของใบรับรอง EDS ที่กำหนดไว้ในมาตรา 6 ของกฎหมาย EDS

   สำหรับฟิลด์ใบรับรองทั้งหมดที่ต้องใช้ค่าสตริงภาษารัสเซีย ควรใช้การเข้ารหัสแบบสากล UTF-8 (ประเภท UTF8String)

   จุดประสงค์ของส่วนนี้คือเพื่อกำหนดองค์ประกอบและวัตถุประสงค์ของฟิลด์ใบรับรองโดยไม่คำนึงถึงข้อกำหนดของผู้ออกใบรับรองโดยเฉพาะ เอกสารที่ควบคุมการทำงานของผู้ออกใบรับรองอาจจำกัดองค์ประกอบของฟิลด์ใบรับรองและชุดของแอตทริบิวต์ที่ใช้ในการระบุ CA และผู้ถือใบรับรอง คีย์ลายเซ็น.

   รุ่น
   ใบรับรองที่ออกทั้งหมด ต้องมีรุ่น 3

   หมายเลขซีเรียล
   ฟิลด์ SerialNumber ต้องมี "... หมายเลขการลงทะเบียนที่ไม่ซ้ำกันของใบรับรองคีย์ลายเซ็น" (มาตรา 6 ข้อ 1 วรรค 1) ต้องเคารพเอกลักษณ์ของหมายเลขใบรับรองภายในหน่วยงานออกใบรับรอง (CA) ที่กำหนด

   ความถูกต้อง
   ฟิลด์ความถูกต้อง ต้องมี "... วันที่เริ่มต้นและหมดอายุของระยะเวลาที่ถูกต้องของใบรับรองคีย์ลายเซ็นที่อยู่ในทะเบียนของศูนย์รับรอง" (มาตรา 6 ข้อ 1 วรรค 1)

   SubjectPublicKeyInfo
   ฟิลด์ subjectPublicKeyInfo ต้องมี "... กุญแจสาธารณะของลายเซ็นดิจิทัลอิเล็กทรอนิกส์" (มาตรา 6 ข้อ 1 วรรค 3)

   ผู้ออก
   กฎหมายของรัฐบาลกลาง "ใน EDS" ถือว่าการออกใบรับรองสำหรับบุคคลเท่านั้น ข้อกำหนดนี้ยังใช้กับใบรับรองของ CA เองและใบรับรองทรัพยากร เพื่อให้เป็นไปตามข้อกำหนดอย่างเป็นทางการของกฎหมายของรัฐบาลกลาง เสนอให้ระบุข้อมูลที่แท้จริงขององค์กรในแอตทริบิวต์ของ CA และใบรับรองทรัพยากร โดยพิจารณาว่าใบรับรองดังกล่าวออกให้แก่บุคคลที่ได้รับอนุญาตของ CA หรือทรัพยากรและ ข้อมูลที่ระบุควรได้รับการตีความและลงทะเบียนเป็นใบรับรองสำหรับนามแฝงซึ่งได้รับอนุญาตโดยกฎหมายของรัฐบาลกลาง "ใน EDS"
   ช่องผู้ออก ต้องระบุองค์กรที่ออกใบรับรองโดยไม่ซ้ำกันและมีชื่อที่จดทะเบียนอย่างเป็นทางการขององค์กร
   สามารถใช้แอตทริบิวต์ต่อไปนี้เพื่อระบุได้:

   ชื่อประเทศ	(id-at 6)
   stateOrProvinceName	(id-at 8)
   localityName	(id-at 7)
   ชื่อองค์กร	(id-at 10)
   องค์กรชื่อหน่วย	(รหัส-ที่ 11)
   รหัสไปรษณีย์	(รหัส-ที่ 16)
   หมายเลขซีเรียล	(id-at 5)

   ช่องผู้ออก ต้องอย่าลืมรวมแอตทริบิวต์ที่อธิบาย "ชื่อและตำแหน่งของหน่วยงานออกใบรับรองที่ออกใบรับรองคีย์ลายเซ็น" (มาตรา 6 ข้อ 1 วรรค 5)

   ชื่อ ต้องระบุไว้ในแอตทริบิวต์ชื่อองค์กร เมื่อใช้แอตทริบิวต์ชื่อองค์กร อาจจะ

   ที่ตั้งของรัฐแคลิฟอร์เนีย อาจจะระบุโดยใช้ชุดของชื่อประเทศ, stateOrProvinceName, แอตทริบิวต์ localityName (ตัวเลือกแต่ละรายการเป็นทางเลือก) หรือใช้แอตทริบิวต์ postalAddress รายการเดียว โดยวิธีการใดวิธีหนึ่งข้างต้น ตำแหน่งของ CA ต้องมีในใบรับรอง

   ต้องมีที่อยู่ตามกฎหมายของผู้มีอำนาจรับรอง ต้องใช้ช่องว่าง (อักขระ "0x20") เป็นตัวคั่น

   ฟิลด์ แอตทริบิวต์ หัวเรื่อง serialNumber ต้องนำไปใช้ในการชนกันของชื่อ

   เรื่อง
   เพื่อเป็นตัวแทนของ DN (Distinguished Name) ของเจ้าของใบรับรอง พฤษภาคมใช้แอตทริบิวต์ต่อไปนี้:

   ชื่อประเทศ	(id-at 6)
   stateOrProvinceName	(id-at 8)
   localityName	(id-at 7)
   ชื่อองค์กร	(id-at 10)
   องค์กรชื่อหน่วย	(รหัส-ที่ 11)
   ชื่อ	(id-at 12)
   ชื่อสามัญ	(id-at 3)
   นามแฝง	(id-at 65)
   หมายเลขซีเรียล	(id-at 5)
   รหัสไปรษณีย์	(รหัส-ที่ 16)

   เพื่อให้เป็นไปตามข้อกำหนดอย่างเป็นทางการของกฎหมายของรัฐบาลกลาง เสนอให้ระบุข้อมูลที่แท้จริงขององค์กรในแอตทริบิวต์ของ CA และใบรับรองทรัพยากร โดยพิจารณาว่าใบรับรองดังกล่าวออกให้แก่บุคคลที่ได้รับอนุญาตของ CA หรือทรัพยากรและ ข้อมูลที่ระบุควรได้รับการตีความและลงทะเบียนเป็นใบรับรองสำหรับนามแฝงซึ่งได้รับอนุญาตโดยกฎหมายของรัฐบาลกลาง "ใน EDS"

   สาขาวิชา ต้องจำเป็นต้องมีข้อมูลต่อไปนี้: "นามสกุล ชื่อและนามสกุลของเจ้าของใบรับรองคีย์ลายเซ็นหรือนามแฝงของเจ้าของ" (มาตรา 6 ข้อ 1 วรรค 2)

   นามสกุล ชื่อและนามสกุลของเจ้าของ ต้องอยู่ในแอตทริบิวต์ commonName และตรงกับที่ระบุไว้ในหนังสือเดินทาง ต้องใช้ช่องว่าง (อักขระ "0x20") เป็นตัวคั่น

   นามแฝงเจ้าของ ต้องมีอยู่ในแอตทริบิวต์นามแฝง

   การใช้คุณลักษณะเหล่านี้อย่างใดอย่างหนึ่งจะขัดขวางการใช้คุณลักษณะอื่น ๆ

   แอ็ตทริบิวต์ที่เหลือเป็นทางเลือก

   "หากจำเป็น ใบรับรองคีย์ลายเซ็น บนพื้นฐานของเอกสารประกอบ ระบุตำแหน่ง (พร้อมชื่อและที่ตั้งขององค์กรที่ตั้งตำแหน่งนี้) ... " (มาตรา 6 ข้อ 2)

   ชื่อผู้ถือใบรับรอง ต้องระบุไว้ในแอตทริบิวต์ชื่อ ค่าแอตทริบิวต์ ต้องสอดคล้องกับรายการในเอกสารยืนยันตำแหน่งที่จัดตั้งขึ้นสำหรับผู้ถือใบรับรอง

   แอตทริบิวต์ชื่อตาม RFC 3039 ต้องรวมอยู่ในส่วนขยาย subjectDirectoryAttributes อย่างไรก็ตาม เอกสารนี้ (และ RFC 3280) อนุญาตให้รวมไว้ในฟิลด์หัวเรื่อง

   จำเป็นเมื่อใช้แอตทริบิวต์ชื่อ ต้องรวมถึงคุณลักษณะที่อธิบายชื่อและที่ตั้งขององค์กรที่ตั้งตำแหน่ง

   ชื่อบริษัท ต้องระบุไว้ในแอตทริบิวต์ชื่อองค์กร ค่าแอตทริบิวต์ ต้องตรงกับชื่อองค์กรในการก่อตั้งหรือเอกสารอื่นที่เทียบเท่า เมื่อใช้แอตทริบิวต์ชื่อองค์กร อาจจะนอกจากนี้ยังใช้แอตทริบิวต์ organizationalUnitName

   ที่ตั้งองค์กร อาจจะระบุโดยใช้ชุดของชื่อประเทศ, stateOrProvinceName, แอตทริบิวต์ localityName (ตัวเลือกแต่ละรายการเป็นทางเลือก) หรือใช้แอตทริบิวต์ postalAddress รายการเดียว

   แอตทริบิวต์ postalAddress หากใช้ ต้องมีที่อยู่ตามกฎหมายขององค์กรหรือที่อยู่ของเจ้าของใบรับรองคีย์ลายเซ็น (สำหรับบุคคล)

   ถ้ามีแอตทริบิวต์ organizationName แอตทริบิวต์ countryName, stateOrProvinceName, localityName และ postalAddress ต้องถูกตีความว่าเป็นที่ตั้งขององค์กร

   แอ็ตทริบิวต์ทางเลือกของฟิลด์หัวเรื่อง (countryName, stateOrProvinceName, localityName, organizationName, organizationalUnitName, title, postalAddress) พฤษภาคมจะถูกรวมไว้ด้วย หากกำหนดโดยข้อบังคับของ CA แทนที่จะเป็นฟิลด์หัวเรื่องในส่วนขยาย subjectDirectoryAttributes (ดูข้อ 3.8.1) ในกรณีนี้พวกเขา ไม่ควรรวมอยู่ในเรื่องและ ไม่ได้ใช้เพื่อแยกความแตกต่างระหว่างเจ้าของการลงนามในใบรับรองคีย์

   แอตทริบิวต์ serialNumber ต้องรวมอยู่ในฟิลด์หัวเรื่องของใบรับรองในกรณีที่ชื่อชนกัน เขายัง อาจจะให้รวมอยู่ด้วยหากกำหนดโดยข้อบังคับของศูนย์รับรอง

   แอตทริบิวต์ serialNumber อาจจะ:

   • เป็นไปตามอำเภอใจ (กำหนดโดยผู้มีอำนาจรับรองเอง);
   • มีตัวระบุ (หมายเลข) ที่กำหนดโดยองค์กรของรัฐ (หรืออื่น ๆ ) (เช่น TIN, ชุดและหมายเลขหนังสือเดินทาง, หมายเลขบัตรประจำตัว ฯลฯ)

   1. ส่วนขยายที่จำเป็น
      ต้องรวมส่วนขยายต่อไปนี้:

      • KeyUsage (id-ce 15)
      • นโยบายใบรับรอง (id-ce 32)

      1. การใช้งานคีย์
         เพื่อให้ใบรับรองใช้ตรวจสอบลายเซ็นดิจิทัลในส่วนขยาย keyUsage ต้องต้องตั้งค่าบิต digitalSignature(0) และ nonRepuduation (1)

         นโยบายใบรับรอง
         ส่วนขยายใบรับรองนโยบายมีวัตถุประสงค์เพื่อกำหนดขอบเขตของการประยุกต์ใช้ใบรับรองที่เกี่ยวข้องตามกฎหมาย
         "... ชื่อของเครื่องมือ EDS ที่ใช้คีย์สาธารณะนี้ ... " (มาตรา 6 วรรค 1 วรรค 4) "... ข้อมูลเกี่ยวกับความสัมพันธ์ในการใช้งานซึ่งเอกสารอิเล็กทรอนิกส์กับ อิเล็กทรอนิกส์ ลายเซ็นดิจิทัลจะมีความสำคัญทางกฎหมาย ... "(มาตรา 6 ข้อ 1 วรรค 6) และข้อมูลอื่น ๆ ที่ควบคุมขั้นตอนการรับและใช้ใบรับรองคีย์ลายเซ็น เป็นไปได้มีให้ที่ CPSuri (ใบรับรองการปฏิบัติ URI) ที่ระบุไว้ในส่วนขยายนี้

   ส่วนขยายเสริม
   เป็นส่วนหนึ่งของการรับรองคีย์การลงนาม พฤษภาคมรวมส่วนขยายอื่นๆ เมื่อรวมส่วนขยายในใบรับรองคีย์ EDS จำเป็นต้องตรวจสอบความสอดคล้องและความชัดเจนของข้อมูลที่นำเสนอในใบรับรอง
   เอกสารนี้ไม่ได้ระบุการใช้ส่วนขยายอื่นนอกเหนือจากส่วนขยาย subjectDirectoryAttributes (id-ce 9)

   1. SubjectDirectoryAttributes
      subjectDirectoryAttributes ส่วนขยาย อาจจะมีคุณลักษณะที่เสริมข้อมูลที่ให้ไว้ในฟิลด์หัวเรื่อง
      นอกเหนือจากแอตทริบิวต์ที่แสดงใน RFC 3039 แล้ว ขอแนะนำให้สนับสนุนแอตทริบิวต์ต่อไปนี้ในส่วนขยาย subjectDirectoryAttributes:

      คุณสมบัติ	{-}
      ชื่อประเทศ	(id-at 6)
      stateOrProvinceName	(id-at 8)
      localityName	(id-at 7)
      ชื่อองค์กร	(id-at 10)
      องค์กรชื่อหน่วย	(รหัส-ที่ 11)
      ชื่อ	(id-at 12)
      รหัสไปรษณีย์	(รหัส-ที่ 16)

      "หากจำเป็น ใบรับรองคีย์ลายเซ็น บนพื้นฐานของเอกสารประกอบ ระบุ ... คุณสมบัติของเจ้าของใบรับรองคีย์ลายเซ็น" (มาตรา 6 ข้อ 2)

      ข้อมูลเกี่ยวกับคุณสมบัติของเจ้าของใบรับรองคีย์ EDS ต้องระบุไว้ในแอตทริบิวต์คุณสมบัติ คุณลักษณะนี้ไม่ได้กำหนดไว้ในคำแนะนำระหว่างประเทศ (ดูข้อ 2) และต้องได้รับการจดทะเบียน

      หากชื่อประเทศ, stateOrProvinceName, localityName, organizationName, organizationalUnitName, title, postalAddress แอตทริบิวต์รวมอยู่ในส่วนขยาย subjectDirectoryAttributes ไม่ควรรวมอยู่ในสาขาวิชา

      เพื่อเก็บข้อมูลอื่น ๆ เกี่ยวกับเจ้าของใบรับรองคีย์ลายเซ็น พฤษภาคมใช้แอตทริบิวต์อื่น (ลงทะเบียนแล้วหรืออยู่ภายใต้การลงทะเบียน) ที่ไม่ขัดแย้งกับข้อจำกัดที่กำหนดโดยส่วนขยาย certificatePolicies และเอกสารอื่นๆ ที่ควบคุมการทำงานของ CA

แอปพลิเคชัน ASN1

รหัสที่:ค่า OID: 2.5.4
คำอธิบาย OID:ประเภทแอตทริบิวต์ X.500
id-ce:ค่า OID: 2.5.29
คำอธิบาย OID:ตัวระบุวัตถุสำหรับส่วนขยายใบรับรองเวอร์ชัน 3

2.5.4.5 id-at-serialNumber serialNumber ATTRIBUTE::= ( WITH SYNTAX PrintableString(SIZE (1..64)) EQUALITY MATCHING RULE caseIgnoreMatch SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch ID id-at-serialNumber )

(อาร์เอฟซี 3039)
แอตทริบิวต์ serialNumber ชนิดแอตทริบิวต์ SHALL เมื่อมี ใช้เพื่อแยกความแตกต่างระหว่างชื่อที่ฟิลด์หัวเรื่องจะเหมือนกัน คุณลักษณะนี้ไม่มีความหมายใด ๆ ที่กำหนดไว้นอกจากการรับรองความเป็นเอกลักษณ์ของชื่อหัวเรื่อง อาจมีตัวเลขหรือรหัสที่กำหนดโดย CA หรือตัวระบุที่ได้รับมอบหมายจากรัฐบาลหรือหน่วยงานพลเรือน เป็นความรับผิดชอบของ CA ที่จะต้องตรวจสอบให้แน่ใจว่าหมายเลขซีเรียลเพียงพอที่จะแก้ไขความขัดแย้งของชื่อเรื่อง

2.5.4.3 - id-at-commonName

ค่า OID: 2.5.4.3

คำอธิบาย OID:ประเภทแอตทริบิวต์ชื่อสามัญระบุตัวระบุของวัตถุ ชื่อสามัญไม่ใช่ชื่อไดเร็กทอรี เป็นชื่อ (อาจคลุมเครือ) โดยที่วัตถุเป็นที่รู้จักโดยทั่วไปในขอบเขตที่จำกัด (เช่น องค์กร) และสอดคล้องกับหลักการตั้งชื่อของประเทศหรือวัฒนธรรมที่เกี่ยวข้อง

CommonName ATTRIBUTE::= ( ประเภทย่อยของชื่อที่มี SYNTAX DirectoryString (ชื่อทั่วไปย่อย) ID (id-at-commonName) )

(RFC 3039 : โปรไฟล์ใบรับรองที่ผ่านการรับรอง)
ค่า OID: 2.5.4.65

นามแฝง ATTRIBUTE::= ( ประเภทย่อยของชื่อที่มี SYNTAX DirectoryString ID (id-at-นามแฝง) )

ค่า OID: 2.5.29.17

คำอธิบาย OID: id-ce-subjectAltName ส่วนขยายนี้มีชื่อทางเลือกตั้งแต่หนึ่งชื่อขึ้นไป โดยใช้รูปแบบชื่อต่างๆ สำหรับเอนทิตีที่ผูกไว้โดย CA กับคีย์สาธารณะที่ผ่านการรับรอง

SubjectAltName EXTENSION::= ( SYNTAX GeneralNames ระบุโดย id-ce-subjectAltName ) GeneralNames::= SEQUENCE SIZE (1..MAX) ของ GeneralName GeneralName::= CHOICE ( otherName INSTANCE OF OTHER-NAME, rfc822Name IA5String, dNSName IA5String, ( *) x400Address ORAddress, ชื่อไดเร็กทอรีName, ediPartyName EDIPartyName, uniformResourceIdentifier IA5String, IPAddress OCTET STRING, ID OBJECT IDENTIFIER ที่ลงทะเบียน ) (*) – สตริงที่กำหนดเอง OTHER-NAME::= SEQUENCE ( type-id OBJECT IDENTIFIER ค่า EXPLICIT ใด ๆ ที่กำหนดโดย type-id )

ค่า OID: 2.5.4.16

คำอธิบาย OID:ประเภทแอตทริบิวต์ที่อยู่ไปรษณีย์ระบุข้อมูลที่อยู่สำหรับการส่งข้อความทางไปรษณีย์โดยหน่วยงานไปรษณีย์ไปยังวัตถุที่มีชื่อ ค่าแอตทริบิวต์สำหรับที่อยู่ทางไปรษณีย์โดยทั่วไปจะประกอบด้วยแอตทริบิวต์ที่เลือกจากที่อยู่ O/R ไปรษณีย์ที่ไม่ได้จัดรูปแบบ MHS เวอร์ชัน 1 ตาม CCITT Rec F.401 และจำกัดไม่เกิน 6 บรรทัด โดยแต่ละอักขระมีอักขระ 30 ตัว รวมทั้งชื่อประเทศของไปรษณีย์ โดยปกติข้อมูลที่อยู่ในที่อยู่ดังกล่าวอาจรวมถึงชื่อผู้รับ ที่อยู่ ที่อยู่ เมือง รัฐ หรือจังหวัด รหัสไปรษณีย์ และอาจเป็นหมายเลขตู้ไปรษณีย์ ขึ้นอยู่กับข้อกำหนดเฉพาะของวัตถุที่มีชื่อ

PostalAddress ATTRIBUTE::= ( WITH SYNTAX PostalAddress EQUALITY MATCHING RULE caseIgnoreListMatch SUBSTRINGS MATCHING RULE caseIgnoreListSubstringsMatch ID id-at-postalAddress ) PostalAddress::= SEQUENCE SIZE (1..ub-postal-string-address) ไดเรกทอรี่ของ PostalAddress

ค่า OID: 2.5.4.12

คำอธิบาย OID:ประเภทแอตทริบิวต์ชื่อระบุตำแหน่งหรือหน้าที่ที่กำหนดของวัตถุภายในองค์กร ค่าแอตทริบิวต์สำหรับชื่อเรื่องคือสตริง

หัวข้อ ATTRIBUTE::= ( SUBTYPE OF name WITH SYNTAX DirectoryString (ub-title) ID id-at-title ) id-ce-certificatePolicies OBJECT IDENTIFIER::= ( id-ce 32 ) certificatePolicies::= SEQUENCE SIZE (1.. MAX) ของนโยบายข้อมูลนโยบายข้อมูลข้อมูล::= SEQUENCE ( policyIdentifier CertPolicyId นโยบายQualifiers SEQUENCE SIZE (1..MAX) ของ PolicyQualifierInfo OPTIONAL ) CertPolicyId::= OBJECT IDENTIFIER PolicyQualifierInfo::= SEQUENCE (นโยบายQualifierId PolicyIQuald นโยบายที่ผ่านการรับรอง) สำหรับตัวระบุนโยบายอินเทอร์เน็ต id-qt OBJECT IDENTIFIER::= ( id-pkix 2 ) id-qt-cps OBJECT IDENTIFIER::= ( id-qt 1 ) id-qt-unotice OBJECT IDENTIFIER::= ( id-qt 2 ) PolicyQualifierId::= OBJECT IDENTIFIER (id-qt-cps | id-qt-unotice) Qualifier::= CHOICE ( cPSuri CPSuri, userNotice UserNotice ) CPSuri::= IA5String UserNotice::= SEQUENCE (noticeRef NoticeReference OPTIONAL, การแสดงข้อความแสดงข้อความที่ชัดเจน) NoticeReference::= ลำดับ ( Organi zation DisplayText, NoticeNumbers SEQUENCE OF INTEGER ) DisplayText::= CHOICE ( visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) )

Vadim Malykh
02.10.2013

คราวที่แล้ว ในกลุ่ม Forum Rus บน Facebook ได้มีการพูดคุยกันเรื่องการใช้ ระบบข้อมูลอ่า เจ้าหน้าที่ (การสนทนานอกหัวข้อ คุณสามารถดูได้ในความคิดเห็นด้านล่าง) สาระสำคัญของข้อพิพาทคือเนื่องจาก OID (ตัวระบุวัตถุ - ตัวระบุวัตถุ) ​​ของระบบข้อมูลที่ต้องลงทะเบียนในใบรับรองลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง (ES) ของเจ้าหน้าที่ ES เดียวกันเหล่านี้จะต้องเปลี่ยนบ่อยกว่าหนึ่งครั้ง ปี (ซึ่งกำหนดโดยข้อกำหนดด้านความปลอดภัย) และสิ่งนี้จะนำไปสู่ความซับซ้อนและค่าใช้จ่ายเพิ่มเติม เนื่องจากหน่วยงานส่วนใหญ่ทำงานร่วมกับ CA เชิงพาณิชย์โดยไม่ต้องมีของตนเอง ปัญหาดังกล่าวรุนแรงขึ้นเนื่องจากขาดความเข้าใจทั่วไปเกี่ยวกับสิ่งเหล่านี้ OIDs มีให้และความจำเป็นและ / หรือจำเป็นเพียงใด

ในระหว่างการโต้เถียง คู่ต่อสู้ของฉันเตือนฉันว่าเนื่องจากความไม่รู้พื้นฐานบางประการของหัวข้อนั้น ฉันอาจประสบปัญหาทางกฎหมายบางอย่างในอนาคต ฉันไม่สามารถเพิกเฉยต่อคำเตือนดังกล่าวจากเพื่อนร่วมงานได้ ดังนั้นฉันจึงตัดสินใจศึกษาหัวข้อนี้อย่างรอบคอบอีกครั้ง และตรวจสอบให้แน่ใจว่าฉันเข้าใจทุกอย่างและดำเนินการอย่างถูกต้อง ด้านล่างนี้คือผลลัพธ์บางส่วนของการทัศนศึกษาครั้งนี้ใน สาขาวิชา. บางทีอาจมีคนสนใจ

เริ่มต้นด้วยแนวคิดพื้นฐาน การเซ็นชื่อแบบอิเล็กทรอนิกส์จะขึ้นอยู่กับอัลกอริธึมการเข้ารหัสแบบอสมมาตร คุณสมบัติหลักของอัลกอริธึมเหล่านี้คือมีการใช้คีย์ที่แตกต่างกันสองคีย์ในการเข้ารหัสและถอดรหัสข้อความ ประชาชนทั่วไปคุ้นเคยกับอัลกอริทึมแบบสมมาตรมากกว่า เมื่อเราเข้ารหัสและถอดรหัสข้อความด้วยคีย์เดียวกัน (หรือรหัสผ่าน) ตัวอย่างเช่น เราเก็บถาวรไฟล์ด้วยรหัสผ่านหรือป้องกันเอกสาร MS Word

หลายสิ่งหลายอย่างใช้อัลกอริธึมการเข้ารหัสแบบอสมมาตร แม้ว่าข้อเท็จจริงเพียงว่าคีย์ต่างๆ ที่ใช้สำหรับการเข้ารหัสและถอดรหัสจะยังไม่อนุญาตให้ใช้อัลกอริธึมที่เป็นประโยชน์ใดๆ ของอัลกอริธึมเหล่านี้ เมื่อต้องการทำเช่นนี้ พวกเขาจะต้องมีคุณสมบัติเพิ่มเติมบางอย่าง ประการแรก คีย์ต้องไม่สามารถคำนวณได้ นั่นคือ ถ้าคุณรู้หนึ่งคีย์ คุณจะไม่สามารถคำนวณคีย์ที่สองได้ นอกจากนี้ยังเป็นสิ่งสำคัญมากที่คีย์การเข้ารหัสต่างๆ จะสอดคล้องกับคีย์ถอดรหัสที่แตกต่างกัน และในทางกลับกัน - คีย์เข้ารหัสเพียงคีย์เดียวที่สอดคล้องกับคีย์ถอดรหัสหนึ่งคีย์

ลายเซ็นที่แท้จริงคืออะไร? ท้ายที่สุดเราจำเป็นต้องลงนามในเอกสารไม่ใช่เข้ารหัส ก่อนอื่นคุณต้องเข้าใจว่าลายเซ็นคืออะไรและทำไมจึงจำเป็น เมื่อคุณใส่ลายเซ็นที่เขียนด้วยลายมือลงในเอกสารที่เป็นกระดาษ คุณจึงมั่นใจได้ว่าเป็นคุณ (และไม่ใช่คนอื่น) ที่เห็น (และตกลงที่จะ) เอกสารนี้โดยเฉพาะ (และไม่ใช่คนอื่น) ทรัพย์สินที่สำคัญที่สุดลายเซ็น - ไม่ปฏิเสธ ซึ่งหมายความว่าเมื่อคุณลงนามในเอกสารแล้ว คุณจะไม่สามารถสละข้อเท็จจริงนั้นได้ในภายหลัง ในกรณีของลายเซ็นบนกระดาษ ความเชี่ยวชาญด้านการเขียนด้วยลายมือจะตัดสินลงโทษคุณ ในกรณีของลายเซ็นอิเล็กทรอนิกส์ วิธีการทางคณิตศาสตร์ที่อิงจากอัลกอริธึมการเข้ารหัสแบบอสมมาตร

มันทำงานอย่างไรโดยสรุป เราใช้อัลกอริธึมการเข้ารหัสแบบอสมมาตร สร้างคู่คีย์ (สำหรับการเข้ารหัสและถอดรหัส) เรามอบกุญแจเข้ารหัสให้กับผู้ที่จะลงนามในเอกสาร เขาต้องเก็บมันไว้กับเขาเสมอไม่ให้มันกับใคร ดังนั้นจึงเรียกว่าคีย์ "ส่วนตัว" เรามอบกุญแจอีกอัน (ถอดรหัส) ให้กับทุกคน ดังนั้นจึง "เปิด" เมื่อลงนามในเอกสาร บุคคลต้องเข้ารหัสด้วยคีย์ส่วนตัว ไม่ใช่ตัวเอกสารที่เข้ารหัสจริงๆ เนื่องจากอาจมีขนาดค่อนข้างใหญ่ และเราไม่จำเป็นต้องเข้ารหัสจริงๆ ดังนั้นจะได้รับแฮชสำหรับเอกสาร ซึ่งเป็นลำดับตัวเลขที่มีความน่าจะเป็นสูงที่แตกต่างกันสำหรับเอกสารต่างๆ เช่น "ลายนิ้วมือ" ของเอกสาร มันถูกเข้ารหัสด้วยคีย์ส่วนตัวของผู้ลงนาม แฮชที่เข้ารหัสนี้คือ ลายเซนต์อิเล็กทรอนิกส์เอกสาร. ตอนนี้ เมื่อมีเอกสาร ลายเซ็น และกุญแจสาธารณะ ใครๆ ก็สามารถตรวจสอบได้ง่ายๆ ว่าเอกสารนี้ลงนามด้วยคีย์ส่วนตัวนี้โดยเฉพาะ ในการทำเช่นนี้ เราได้รับแฮชของเอกสารอีกครั้ง ถอดรหัสลายเซ็นด้วยกุญแจสาธารณะ และเปรียบเทียบ ควรได้รับสองลำดับตัวเลขที่เหมือนกัน

ทั้งหมดนี้เป็นสิ่งที่ดี แต่จนถึงขณะนี้เราได้รับลายเซ็นสำหรับคีย์ส่วนตัวที่ไม่ปฏิเสธนั่นคือเราได้พิสูจน์แล้วว่าเอกสารนั้นลงนามโดยคีย์เฉพาะ เราจำเป็นต้องพิสูจน์ว่ามีการลงนามโดยบุคคลใดบุคคลหนึ่ง การทำเช่นนี้มีศูนย์รับรองและใบรับรองดิจิทัล สิ่งที่สำคัญที่สุดที่หน่วยงานออกใบรับรองทำคือการรับรองว่ารหัสส่วนตัวนั้นเป็นของบุคคลใดบุคคลหนึ่ง เพื่อรับประกันสิ่งนี้ ศูนย์รับรองที่สร้างคู่คีย์และออกให้กับเจ้าของเป็นการส่วนตัว (มีตัวเลือกโดยพร็อกซีจากระยะไกล แต่สิ่งเหล่านี้เป็นรายละเอียด) ใบรับรองดิจิทัลจะถูกสร้างขึ้นร่วมกับคีย์ ซึ่งเป็นเอกสารอิเล็กทรอนิกส์ (บางครั้งก็ใช้แทนกระดาษ) ซึ่งมีข้อมูลเกี่ยวกับเจ้าของคีย์ ตัวคีย์เอง หน่วยงานออกใบรับรอง และข้อมูลอื่นๆ ตามกฎแล้วเจ้าของจะได้รับความดีทั้งหมดนี้บนสื่อที่ปลอดภัย (สมาร์ทการ์ด ru-token และอื่น ๆ ) ซึ่งมีคีย์ส่วนตัวและใบรับรองพร้อมกุญแจสาธารณะที่ฝังอยู่ ผู้ให้บริการต้องอยู่กับคุณเสมอ และสามารถคัดลอกใบรับรองคีย์สาธารณะให้กับทุกคนได้ เพื่อให้พวกเขาตรวจสอบลายเซ็นอิเล็กทรอนิกส์ของคุณได้

ดังนั้น การเซ็นชื่อจะทำด้วยคีย์ส่วนตัว และการตรวจสอบลายเซ็นด้วยคีย์สาธารณะ ดังนั้นวลี "เอกสารถูกลงนามโดยชุด OID" (ฟังในข้อพิพาทข้างต้น) จึงไม่มีความหมาย มีเพียงสองคีย์เท่านั้นที่เกี่ยวข้องในกระบวนการลงนามและการยืนยัน ใน 63-FZ จะมีการตั้งชื่อตามนั้น - คีย์ลายเซ็นและคีย์การตรวจสอบลายเซ็น

และ OID ที่โด่งดังเหล่านี้คืออะไร? รูปแบบใบรับรองดิจิทัล X.509 ช่วยให้สามารถจัดเก็บส่วนขยายได้ นี่เป็นแอตทริบิวต์ทางเลือกบางส่วนที่สามารถใช้เพื่อเก็บข้อมูลเพิ่มเติม แต่ละแอตทริบิวต์ดังกล่าวเป็นอ็อบเจ็กต์ที่ระบุโดยตัวระบุจากไดเร็กทอรีแบบลำดับชั้น ดังนั้น OID - ตัวระบุวัตถุ มันไม่สมเหตุสมผลเลยที่จะเจาะลึกถึงธรรมชาติของ OID เอง อันที่จริง นี่คือข้อมูลเพิ่มเติมบางอย่างที่อาจอยู่ในใบรับรอง

คุณลักษณะเพิ่มเติมเหล่านี้สามารถนำมาใช้เพื่อวัตถุประสงค์ต่างๆ พวกเขาสามารถให้ข้อมูลเพิ่มเติมเกี่ยวกับเจ้าของ คีย์ CA หรือนำข้อมูลเพิ่มเติมสำหรับแอปพลิเคชันและบริการที่ใช้ใบรับรองนี้ การใช้งานทั่วไปส่วนใหญ่ใช้สำหรับการควบคุมการเข้าถึงตามบทบาท ตัวอย่างเช่น สามารถระบุได้ในใบรับรองว่าเจ้าของคีย์เป็นหัวหน้าองค์กร และสิ่งนี้จะทำให้เขามีโอกาสเข้าถึงฟังก์ชันและข้อมูลที่จำเป็นใน IS ทั้งหมดได้ทันที โดยไม่ต้องติดต่อผู้ดูแลระบบของแต่ละรายการ IS และเปลี่ยนการตั้งค่าการเข้าถึง ทั้งหมดนี้ แน่นอน โดยมีเงื่อนไขว่า IS ทั้งหมดเหล่านี้ใช้ใบรับรองของผู้ใช้สำหรับการอนุญาต และวิเคราะห์แอตทริบิวต์เดียวกันในลักษณะเดียวกัน (ด้วยเหตุนี้ แอตทริบิวต์จะถูกเลือกจากไดเร็กทอรีและไม่ได้ตั้งค่าโดยพลการ)

เนื่องจากแอปพลิเคชันต่างกัน เราได้รับใบรับรองสองใบที่มีลักษณะแตกต่างกันโดยสิ้นเชิง หนึ่ง - รับรองว่าฉันคือฉันและเป็นเช่นนี้เสมอ ในทางที่ดี มันสามารถออกได้อย่างน้อยหนึ่งครั้งในชีวิต เช่น หนังสือเดินทาง อย่างไรก็ตาม เนื่องจากความไม่สมบูรณ์แบบของอัลกอริธึมการเข้ารหัสที่มีอยู่ เพื่อความปลอดภัย ใบรับรองเหล่านี้จึงต้องออกใหม่ทุกปี ใบรับรองประเภทที่สองจัดการข้อมูลเพิ่มเติมและสามารถเปลี่ยนแปลงได้บ่อยกว่าปีละครั้ง เทียบได้กับ บัตรโทรศัพท์. เปลี่ยนตำแหน่ง, อีเมล, โทรศัพท์ - คุณต้องทำนามบัตรใหม่

ในโลก ใบรับรองทั้งสองประเภทนี้เรียกว่า Public Key Certificate (PKC) และ Attribute Certificate (หรือ Authorization Certificate - AC) ตามลำดับ ใบรับรองประเภทที่สองสามารถออกให้บ่อยกว่าใบรับรองแรกโดยองค์กรอื่น และควรเข้าถึงได้ง่ายกว่าและรับได้ง่ายกว่าใบรับรอง "กุญแจสาธารณะ" ส่วนบุคคล ไม่ว่าในกรณีใด นี่คือสิ่งที่ RFC 3281 แนะนำ สำหรับใบรับรองประเภทนี้โดยเฉพาะ ใบรับรองประเภทที่สองควรมีเฉพาะลิงก์ไปยังใบรับรองคีย์สาธารณะ เพื่อให้ระบบที่ใช้ใบรับรองดังกล่าวอนุญาตให้ผู้ใช้ระบุตัวบุคคลที่ใช้ PKC ได้ก่อน

ตอนนี้เราเข้าใกล้ความเป็นจริงมากขึ้น ในระดับนิติบัญญัติ ประเด็นที่เกี่ยวข้องกับการใช้ลายเซ็นอิเล็กทรอนิกส์ใน สหพันธรัฐรัสเซียถูกควบคุมโดยเอกสารหลักสองฉบับ - กฎหมายของสหพันธรัฐรัสเซียเมื่อวันที่ 04/06/2554 หมายเลข 63-FZ "บนลายเซ็นอิเล็กทรอนิกส์" และคำสั่งของ Federal Security Service ของสหพันธรัฐรัสเซียเมื่อวันที่ 27/12/2554 ฉบับที่ 795 "ในการอนุมัติข้อกำหนดสำหรับแบบฟอร์มใบรับรองที่ผ่านการรับรองของคีย์การตรวจสอบลายเซ็นอิเล็กทรอนิกส์" องค์ประกอบของใบรับรองที่ผ่านการรับรองได้อธิบายไว้ในลำดับที่ 795 (ส่วนที่ II "ข้อกำหนดสำหรับชุดของฟิลด์ของใบรับรองที่ผ่านการรับรอง") และไม่มีข้อกำหนดสำหรับแอตทริบิวต์ที่ควบคุมการอนุญาตในระบบข้อมูลใดๆ เนื่องจากเป็นแอตทริบิวต์บังคับเพิ่มเติม จะมีการระบุเฉพาะข้อมูลที่ช่วยให้คุณสามารถระบุบุคคลหรือนิติบุคคลในสหพันธรัฐรัสเซีย (TIN, SNILS ฯลฯ ) แม้ว่าทั้งกฎหมายและคำสั่งของ FSB จะห้ามไม่ให้รวมข้อมูลอื่น ๆ ไว้ในใบรับรองที่ผ่านการรับรอง

อย่างที่คุณเห็น ไม่มีบรรทัดฐานทางกฎหมายใดกำหนดการแสดงตนที่จำเป็นในใบรับรองคุณสมบัติที่มีคุณสมบัติที่เกี่ยวข้องกับการอนุญาตในระบบข้อมูลใดๆ ข้อกำหนดเหล่านี้มาจากไหน? และมาจากนักพัฒนา (หรือ "เจ้าของ") ระบบเฉพาะ. ยกตัวอย่าง "แนวทางสำหรับการใช้ลายเซ็นอิเล็กทรอนิกส์ในการโต้ตอบทางอิเล็กทรอนิกส์ระหว่างแผนก (เวอร์ชัน 4.3)" ที่โพสต์บนพอร์ทัลเทคโนโลยี SMEV อันที่จริงในย่อหน้าที่ 6 ของเอกสารนี้เราอ่านว่า: "เมื่อเตรียมข้อมูลสำหรับการสร้างใบรับรอง EP-SP จำเป็นต้องพิจารณาความจำเป็นในการขอข้อมูลจาก Rosreestr (สารสกัดจาก USRR) หากจำเป็นต้องมีการร้องขอ OID จะต้องระบุไว้ในฟิลด์ "คีย์ที่ได้รับการปรับปรุง" (OID=2.5.29.37) ในใบรับรอง ES-SP ตามข้อกำหนดของ Rosreestr" นั่นคือระบบข้อมูล Rosreestr ใช้แอตทริบิวต์นี้เพื่อกำหนดข้อมูลที่สามารถออกให้กับเจ้าของใบรับรองได้ อย่างไรก็ตาม เอกสารฉบับเดียวกันนี้มีหมายเหตุสำคัญ กล่าวคือ ข้อกำหนดนี้ใช้ได้จนกว่า ESIA (บริการอนุญาตเดียวในระบบของรัฐ) จะเปิดตัวอย่างสมบูรณ์ และระบบ Rosreestr เชื่อมต่อกับเอกสารดังกล่าว นี่เป็นบันทึกสำคัญ โปรดจำไว้

ฉันจะไม่จัดการกับ IP อื่น ๆ ที่ใช้ในรัฐ อวัยวะ ฉันสงสัยว่าสถานการณ์จะคล้ายกัน พอร์ทัลการจัดซื้อจัดจ้างสาธารณะ แพลตฟอร์มการซื้อขายทางอิเล็กทรอนิกส์ แอปพลิเคชันการบัญชีและการเงินต่างๆ อาจต้องมี OID เพิ่มเติมบางอย่างในใบรับรองผู้ใช้ ในเวลาเดียวกัน ข้อความที่ว่าโดยการเขียน OID ของระบบข้อมูลในใบรับรอง ฉันได้มอบหมายความรับผิดชอบไปยังศูนย์รับรองโดยกล่าวอย่างสุภาพว่าไม่ถูกต้อง CA ป้อนข้อมูลนี้ลงในใบรับรองตามใบสมัครของฉัน หากตำแหน่งของฉันเปลี่ยนไป และฉันลืมยื่นขอเพิกถอนใบเก่าและการออกใบรับรองใหม่ CA จะไม่รับผิดชอบต่อการหลงลืมของฉัน นอกจากนี้กฎหมาย 63-FZ ยังกำหนดความรับผิดชอบโดยตรงสำหรับการใช้ใบรับรองอย่างไม่ถูกต้องให้กับเจ้าของ ในวรรค 6 ของบทความ 17 เราอ่าน:
ผู้ถือใบรับรองที่ผ่านการรับรองจะต้อง:
1) อย่าใช้คีย์ลายเซ็นอิเล็กทรอนิกส์และติดต่อศูนย์รับรองที่ได้รับการรับรองซึ่งออกใบรับรองที่ผ่านการรับรองทันทีเพื่อยุติใบรับรองนี้หากมีเหตุผลที่เชื่อว่ามีการละเมิดความลับของคีย์ลายเซ็นอิเล็กทรอนิกส์
2) ใช้ลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรองตามข้อจำกัดที่มีอยู่ในใบรับรองที่ผ่านการรับรอง (หากมีการกำหนดข้อจำกัดดังกล่าว)

ความจำเป็นในการเก็บข้อมูลใบรับรองเกี่ยวกับบทบาทของผู้ใช้และการเข้าถึงในระบบข้อมูลเฉพาะทำให้เกิดปัญหาที่ทำให้เกิดข้อพิพาทบน Facebook กล่าวคือต้องออกใบรับรองใหม่บ่อยกว่าข้อกำหนดด้านความปลอดภัยสำหรับลายเซ็นอิเล็กทรอนิกส์ส่วนบุคคล . ตำแหน่งมีการเปลี่ยนแปลง - เราออกใบรับรองใหม่ IS ใหม่ปรากฏขึ้น - เราออกใบรับรองใหม่ มีความจำเป็นต้องขอข้อมูลจาก IS ขององค์กรใหม่ (Rosreestr) - เราออกใบรับรองใหม่

มีการตี 100% ในแนวคิดที่เรียกว่าในโลก Attribute Certificate (หรือ Authorization Certificate) ซึ่งถูกกล่าวถึงข้างต้นและแนะนำให้ออกใบรับรองเหล่านี้โดยหน่วยงานออกใบรับรองอื่น (Attribute Autority ตรงกันข้ามกับ Certificate Authority - CA ปกติที่ออกใบรับรอง ES ที่ผ่านการรับรอง) และด้วยวิธีที่เรียบง่าย ใบรับรองนี้ไม่ควรมีคีย์ลายเซ็นอิเล็กทรอนิกส์และข้อมูลเกี่ยวกับเจ้าของ แต่มีลิงก์ไปยังใบรับรองคีย์สาธารณะของเจ้าของ ซึ่งคุณสามารถรับข้อมูลที่จำเป็นที่เหลือเกี่ยวกับบุคคลนั้นได้

ควรสังเกตว่ารูปแบบนี้มีแอปพลิเคชันที่ จำกัด มากและไม่สามารถแก้ปัญหาทั้งหมดได้ จะเกิดอะไรขึ้นหากระบบข้อมูลถัดไปตัดสินใจที่จะใช้ฟิลด์ใบรับรองเดียวกัน “คีย์ที่ปรับปรุงแล้ว” (OID=2.5.29.37) ซึ่งถูกครอบครองโดยค่า Rosreestr แล้วสำหรับความต้องการ การป้อนค่าที่แตกต่างกันสองค่าในฟิลด์เดียวจะไม่ทำงาน ดังนั้นเราจะต้องปล่อย AC ออกไปอีก! อีกปัญหาหนึ่งเกี่ยวข้องกับอายุสั้นของ PKC (หนึ่งปี) หากเรามี AC หลายตัว (ซึ่งมีลิงก์ไปยังใบรับรองส่วนบุคคล) จะต้องออกใบรับรองใหม่ทั้งหมดหลังจาก PKC หมดอายุ เพื่อการใช้ AC อย่างมีประสิทธิภาพ จำเป็นต้องมีศูนย์อนุญาตผู้ใช้รายเดียวในระบบข้อมูลทั้งหมด และแอปพลิเคชันทั้งหมดต้องใช้แอตทริบิวต์ของใบรับรองในลักษณะที่สม่ำเสมอและสม่ำเสมอ

ศูนย์อนุญาตเดียวสำหรับรัฐดังกล่าว หน่วยงานที่มีอยู่แล้ว - นี่คือ ESIA เรียกคืนหมายเหตุเกี่ยวกับ OID ของ Rosreestr ในอนาคต พวกเขาจะถูกแทนที่ด้วยข้อมูลจาก ESIA ระบบข้อมูลอื่น ๆ ที่ข้าราชการทำงานควรทำเช่นเดียวกัน แทนที่จะใช้ AC สำหรับการอนุญาต จำเป็นต้องรวมเข้ากับ ESIA และรับข้อมูลที่จำเป็นจากที่นั่น ESIA ควรจะสามารถผูกใบรับรอง ES ที่ผ่านการรับรองเข้ากับบัญชีได้ ดังนั้นระบบข้อมูลจะสามารถตรวจสอบสิทธิ์ผู้ใช้โดยใช้คีย์ส่วนตัว และอนุญาตเขา (ให้สิทธิ์ในการเข้าถึงแอปพลิเคชัน) ผ่าน ESIA ระบบดังกล่าวดูเหมือนจะเป็นสากลและเชื่อถือได้มากกว่าการใช้ฟิลด์ใบรับรองและในอนาคตจะทำให้การจัดการการเข้าถึงเป็นไปโดยอัตโนมัติหากมีการสร้างระบบรวมของบันทึกบุคลากรของข้าราชการ ESIA จะสามารถรับข้อมูลเกี่ยวกับ พลังของบุคคลโดยตรงจากที่นั่นบุคคลหนึ่งย้ายไปยังตำแหน่งอื่น - สูญเสียการเข้าถึงระบบหนึ่งโดยอัตโนมัติและได้รับอีกระบบหนึ่ง เกี่ยวกับ เขายังคงใช้คีย์ ES เพื่อลงนามในเอกสาร ไม่จำเป็นต้องออกใหม่

ตามข้อกำหนดทางเทคนิคสำหรับ CJSC AEI PRIME ในการเปิดเผยข้อมูลเกี่ยวกับหลักทรัพย์และเครื่องมือทางการเงินอื่น ๆ ที่ได้รับอนุมัติจากธนาคารแห่งรัสเซีย () เอกสารอิเล็กทรอนิกส์ที่มีข้อมูลสาธารณะต้องลงนามโดยหัวข้อการเปิดเผยข้อมูลด้วยลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง (ดูข้อ 1.7 ของเงื่อนไขทางเทคนิค) ข้อกำหนดนี้มีผลตั้งแต่วันที่ 1 กุมภาพันธ์ 2017

ในปัจจุบัน ระยะเวลาทดสอบสำหรับการใช้ลายเซ็นอิเล็กทรอนิกส์ได้เริ่มต้นขึ้นบนเซิร์ฟเวอร์การเปิดเผยข้อมูล PRIME ซึ่งจะคงอยู่จนถึงวันที่ 31 มกราคม 2017

เพื่อทดสอบการทำงาน ลูกค้า PRIME สามารถใช้ ใบรับรองคีย์ ES ใด ๆ ที่ได้รับก่อนหน้านี้สำหรับนิติบุคคลนี้

ตั้งแต่วันที่ 1 กุมภาพันธ์ 2017 ตามคำร้องขอของเงื่อนไขทางเทคนิค (ดูข้อ 1.7 และ 9.6.) ใบรับรองที่ผ่านการรับรองของคีย์การตรวจสอบลายเซ็นอิเล็กทรอนิกส์ของผู้ใช้จะต้องเป็นไปตามข้อกำหนดสำหรับแบบฟอร์มใบรับรองที่ผ่านการรับรองซึ่งกำหนดโดยคำสั่งของ Federal Security Service of Russia ลงวันที่ 27 ธันวาคม 2011 หมายเลข 795 "ในข้อกำหนดการอนุมัติสำหรับแบบฟอร์มใบรับรองที่ผ่านการรับรองของคีย์การตรวจสอบลายเซ็นอิเล็กทรอนิกส์ ส่วนขยายใบรับรองผู้ใช้คีย์ขั้นสูง ( ตัวระบุวัตถุ 2.5.29.37) ต้องมีการเปิดเผยตัวระบุวัตถุ PRIME - OID 1.2.643.6.42.5.5.5

การเข้าสู่ระบบบัญชีส่วนตัวของผู้ใช้การเปิดเผยข้อมูล "PRIME" จะดำเนินการโดยใช้ LOGIN และ PASSWORD ที่ลูกค้าได้รับก่อนหน้านี้

การดำเนินการของลูกค้าในการเผยแพร่ข้อความในฟีดการเปิดเผยข้อมูล โพสต์เอกสารบนหน้าเว็บบนอินเทอร์เน็ต เปลี่ยนแปลงบัตรลงทะเบียนของผู้ออกในระบบการเปิดเผยข้อมูลจะต้องได้รับการยืนยันด้วยลายเซ็นอิเล็กทรอนิกส์

ในการใช้ ES บนเซิร์ฟเวอร์การเปิดเผยข้อมูล PRIME ไคลเอนต์ต้องติดตั้งปลั๊กอินก่อน (การติดตั้งนั้นฟรีสำหรับผู้ใช้และใช้เวลาไม่นาน) ดูคำแนะนำในการติดตั้งปลั๊กอินด้านล่าง

ในบัญชีส่วนตัวของผู้ใช้เปิดเผยข้อมูลหลังจากที่ลูกค้าติดตั้งปลั๊กอินเมื่อกรอกแบบฟอร์มสำหรับเผยแพร่ข้อความในฟีดการเปิดเผยข้อมูลหรือวางเอกสารบนอินเทอร์เน็ตตลอดจนเมื่อเปลี่ยนข้อมูลบัตรลงทะเบียน ฟิลด์เพิ่มเติม "ลายเซ็นอิเล็กทรอนิกส์ของเอกสาร" จะปรากฏขึ้น ซึ่งจำเป็นต้องเลือกฟิลด์ที่แสดงในใบรับรองคีย์การลงนามของฟิลด์บริการที่เกี่ยวข้อง และคลิกปุ่ม "ลงชื่อ" ด้วยวิธีนี้ ลูกค้าจะยืนยันการกระทำของเขาเพื่อเปิดเผยข้อมูลหรือเปลี่ยนแปลงบัตรลงทะเบียนของเขา

• หลังจากเซ็นข้อความด้วยลายเซ็นอิเล็กทรอนิกส์แล้ว ลูกค้าต้องคลิกปุ่ม "เผยแพร่"
• หลังจากลงนามในเอกสารด้วยลายเซ็นอิเล็กทรอนิกส์แล้ว ลูกค้าจะต้องคลิกปุ่ม "เพิ่มเอกสาร"
• หลังจากลงนามการเปลี่ยนแปลงในบัตรลงทะเบียนด้วยลายเซ็นอิเล็กทรอนิกส์แล้ว ลูกค้าต้องคลิกปุ่ม "ส่งแบบฟอร์มระบุตัวตน"

โปรดทราบว่าข้อความทั้งหมดที่ส่งโดยลูกค้าผ่านบัญชีส่วนตัวของพวกเขาผ่านการอนุญาต "ทดสอบการเข้าสู่ระบบ (ทำงานกับ ES)" จะถูกเผยแพร่ในฟีดการเปิดเผยข้อมูลในโหมดการทำงาน เอกสารทั้งหมดที่วางโดยลูกค้าผ่านบัญชีส่วนตัวของพวกเขาผ่านการอนุญาต "รายการทดสอบ (ทำงานกับ ES)" จะถูกโพสต์โดยอัตโนมัติบนหน้าของผู้ออกในโหมดการทำงาน

มิฉะนั้น ขั้นตอนของผู้ออกในบัญชีส่วนตัวบนเซิร์ฟเวอร์การเปิดเผยข้อมูล PRIME จะไม่เปลี่ยนแปลง