#import "../PageTemplate.typ": *

== X.509 (รูปแบบใบรับรอง TLS/SSL) <x509>

#iii ในการเข้ารหัส X.509 เป็นมาตรฐานของสหภาพโทรคมนาคมระหว่างประเทศ (ITU)
ที่กำหนดรูปแบบของใบรับรองคีย์สาธารณะใบรับรอง X.509 ถูกใช้ในโปรโตคอลอินเทอร์เน็ตมากมายรวมถึง
TLS/SSL ซึ่งเป็นพื้นฐานของ HTTPS โปรโตคอลที่ปลอดภัยสำหรับการท่องเว็บ
นอกจากนี้ยังใช้ในแอปพลิเคชันออฟไลน์เช่น ลาย เซ็นอิเล็กทรอนิกส์ ใบรับรอง X.509
เชื่อมโยงข้อมูลประจำตัวกับคีย์สาธารณะโดยใช้ลายเซ็นดิจิทัล ใบรับรองประกอบด้วยข้อมูลประจำตัว
(ชื่อโฮสต์องค์กร หรือบุคคล) และคีย์สาธารณะ (RSA, DSA, ECDSA, ed25519 เป็นต้น)
ซึ่งลงนามโดยผู้ออกใบรับรองหรือลงนามด้วยตนเอง
เมื่อใบรับรองได้รับการลงนามโดยผู้ออกใบรับรองที่เชื่อถือได้หรือผ่านการตรวจสอบความถูกต้องด้วยวิธีอื่น
ผู้ถือใบรับรองนั้นสามารถใช้คีย์สาธารณะที่มีอยู่เพื่อสร้างการสื่อสารที่ปลอดภัยกับบุคคลอื่น
หรือตรวจสอบความถูกต้องของเอกสารที่ลงนามดิจิทัลด้วย คีย์ส่วนตัวที่เกี่ยวข้องได้

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

#iii X.509 ถูกกำหนดโดย "Standardization Sector" ของ ITU (SG17 ของ ITU-T) ใน ITU-T
Study Group 17 และมีพื้นฐานมาจาก Abstract Syntax Notation One (ASN.1)
ซึ่งเป็นมาตรฐานอีกประการหนึ่งของ ITU-T

=== โครงสร้างของใบรับรอง
#iiii โครงสร้างที่กำหนดไว้โดยมาตรฐานจะแสดงอยู่ในภาษาทางการที่เรียกว่า Abstract Syntax
Notation One (ASN.1)

#iiii โครงสร้างของใบรับรองดิจิทัล X.509 v3 มีดังนี้

#block(inset: (left: 9.25em))[
  + ใบรับรอง
    + หมายเลขเวอร์ชัน
    + หมายเลขซีเรียล
    + รหัสอัลกอริทึมลายเซ็น
    + ชื่อผู้ออก
    + ระยะเวลาใช้งาน โดยระบุเวลาไม่ก่อนและไม่หลังจากนั้น
    + ชื่อเรื่อง
    + ข้อมูลคีย์สาธารณะของเรื่อง ได้แก่ อัลกอริทึมคีย์สาธารณะ
      คีย์สาธารณะของเรื่องเช่นรหัสประจำตัวผู้ออก (ไม่จำเป็น) รหัสประจำตัวเฉพาะเรื่อง (ไม่จำเป็น)
      ส่วนขยาย (ไม่จำเป็น)
  + อัลกอริทึมลายเซ็นใบรับรอง
  + ลายเซ็นใบรับรอง
]

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

#iiii โครงสร้างของเวอร์ชัน 1 มีอยู่ ใน RFC 1422

#iiii รูปแบบภายในของตัวระบุเฉพาะของผู้เผยแพร่และเรื่องที่ระบุไว้ใน X.520 ไดเร็กทอรี:คำแนะนำ
ประเภทแอตทริบิวต์ที่เลือก

#iiii ITU-T ได้นำตัวระบุเฉพาะของผู้ออกหลักทรัพย์และบุคคลมาใช้ในเวอร์ชัน 2
เพื่ออนุญาตให้นำชื่อผู้ออกหลักทรัพย์หรือบุคคลมาใช้ซ้ำได้หลังจากระยะเวลาหนึ่ง
ตัวอย่างหนึ่งของการนำกลับมาใช้ซ้ำคือเมื่อ CA ล้มละลายและชื่อถูกลบออกจากรายชื่อสาธารณะของประเทศ
หลังจากนั้น CA อื่นที่มีชื่อเดียวกันอาจลงทะเบียนตัวเองได้ แม้ว่าจะไม่เกี่ยวข้องกับ CA แรกก็ตาม
อย่างไรก็ตาม IETF แนะนำว่าไม่ควรนำชื่อผู้ออกหลักทรัพย์และบุคคลมาใช้ซ้ำ ดังนั้นเวอร์ชัน 2
จึงยังไม่แพร่หลายในอินเทอร์เน็ต

#iiii ส่วนขยายได้รับการแนะนำในเวอร์ชัน 3 CA
สามารถใช้ส่วนขยายเพื่อออกใบรับรองได้เฉพาะสำหรับจุดประสงค์เฉพาะ (เช่น
สำหรับการลงนามในวัตถุดิจิทัล เท่านั้น)

#iiii ในทุกเวอร์ชันหมายเลขซีเรียลจะต้องไม่ซ้ำกันสำหรับใบรับรองแต่ละใบที่ออกโดย CA เฉพาะ
(ดังที่กล่าวถึงใน RFC 5280)

=== นามสกุลไฟล์ใบรับรอง
#iiii นามสกุลไฟล์ที่ใช้กันทั่วไปสำหรับใบรับรอง X.509
มีหลายประเภทนามสกุลไฟล์เหล่านี้ยังใช้สำหรับข้อมูลอื่น ๆ เช่น คีย์ส่วนตัวด้วย

#[
  #set enum(indent: 9.25em)
  1. `.pem` -- (อีเมลอิเล็กทรอนิกส์ที่เพิ่มความเป็นส่วนตัว) ใบรับรอง DER ที่เข้ารหัส Base64
    แนบระหว่าง `-----BEGIN CERTIFICATE-----` และ `-----END CERTIFICATE-----`
  2. `.cer`, `.crt`, `.der` -- โดยปกติจะอยู่ในรูปแบบไบนารี DER แต่ใบรับรองที่เข้ารหัส
    Base64 ก็เป็นเรื่องปกติเช่นกัน (ดู `.pem` ด้านบน)
  3. `.p8`, `.p8e`, `.pk8` -- คีย์ส่วนตัวที่ส่งออกตามที่ระบุไว้ใน PKCS\#8 อาจอยู่ในรูปแบบ DER
    หรือ PEM ที่ขึ้นต้นด้วย `-----BEGIN PRIVATE KEY-----` คีย์ที่เข้ารหัสจะขึ้นต้นด้วย
    `-----BEGIN ENCRYPTED PRIVATE KEY-----` และอาจมี `.p8e` เป็นนามสกุลไฟล์
  4. `.p10`, `.csr` -- PKCS\#10 เป็นคำขอลงนามใบรับรอง (CSR) ในรูปแบบ PEM ขึ้นต้นด้วย
    `-----BEGIN CERTIFICATE REQUEST-----` แบบฟอร์มเหล่านี้สร้างขึ้นเพื่อส่งไปยังผู้ออกใบรับรอง
    (CA) แบบฟอร์มประกอบด้วยรายละเอียดสำคัญของใบรับรองที่ร้องขอ เช่น ชื่อสามัญ (/CN), หัวเรื่อง,
    องค์กร, รัฐ, ประเทศ รวมถึงคีย์สาธารณะของใบรับรองที่ต้องการให้ลงนาม
    คีย์เหล่านี้จะได้รับการลงนามโดย CA และใบรับรองจะถูกส่งกลับคืน ใบรับรองที่ส่งคืนคือใบรับรอง
    สาธารณะ (ซึ่งมีคีย์สาธารณะแต่ไม่มีคีย์ส่วนตัว) ซึ่งตัวใบรับรองเองสามารถอยู่ในรูปแบบต่างๆ
    ได้หลายรูปแบบ แต่โดยปกติจะเป็น `.p7r`
  5. `.p7r` -- คำตอบ ของ PKCS\#7 ต่อ CSR ประกอบด้วยใบรับรองที่เพิ่งลงนาม และใบรับรองของ
    CA เอง
  6. `.p7s` -- ลายเซ็นดิจิทัล PKCS\#7 อาจมีไฟล์หรือข้อความที่ลงนามต้นฉบับ ใช้ใน S/MIME
    สำหรับการลงนามในอีเมลกำหนดไว้ใน RFC 2311
  7. `.p7m` -- PKCS\#7 (SignedData, EnvelopedData) ข้อความ เช่น ไฟล์ที่เข้ารหัส
    ("enveloped") ข้อความ หรือจดหมายอีเมล MIME กำหนดไว้ใน RFC 2311
  8. `.p7c` -- โครงสร้าง SignedData แบบ "certs-only" ของ PKCS\#7 ที่เสื่อมลง
    โดยไม่มีข้อมูลใดๆ ให้ลงนาม กำหนดไว้ใน RFC 2311
  9. `.p7b` -- โครงสร้าง SignedData ของ PKCS\#7 ที่ไม่มีข้อมูล มีเพียงใบรับรองแบบบันเดิลหรือ
    CRL (ไม่ค่อยเกิดขึ้น) แต่ไม่มีคีย์ส่วนตัว ใช้รูปแบบ DER หรือ BER หรือ PEM ที่ขึ้นต้นด้วย
    `-----BEGIN PKCS7-----` รูปแบบที่ Windows ใช้สำหรับการแลกเปลี่ยนใบรับรอง รองรับโดย
    Java แต่มักใช้นามสกุล `.keystore` แทน ซึ่งแตกต่างจากใบรับรองแบบ `.pem`
    รูปแบบนี้มีวิธีที่กำหนดไว้สำหรับการรวมใบรับรองเส้นทางการรับรอง
  10. `.p12`, `.pfx`, `.pkcs12` -- PKCS\#12 อาจมีใบรับรอง (สาธารณะ) และคีย์ส่วนตัว
    (ป้องกันด้วยรหัสผ่าน) ในไฟล์เดียว `.pfx` - _Personal Information eXchange_ PFX
    ซึ่งเป็นรุ่นก่อนของ PKCS\#12 (โดยปกติจะมีข้อมูลในรูปแบบ PKCS\#12 เช่น ไฟล์ PFX ที่สร้างใน
    IIS)
  11. `.crl` -- รายการเพิกถอนใบรับรอง (CRL)
    หน่วยงานที่ออกใบรับรองจะจัดทำรายการเหล่านี้ขึ้นเพื่อใช้ในการเพิกถอนใบรับรองก่อนหมดอายุ
]

#iiii PKCS\#7 เป็นมาตรฐานสำหรับการลงนามหรือเข้ารหัสข้อมูล (เรียกอย่างเป็นทางการว่า
"enveloping")
เนื่องจากจำเป็นต้องใช้ใบรับรองเพื่อตรวจสอบข้อมูลที่ลงนามแล้วจึงสามารถรวมใบรับรองไว้ในโครงสร้าง
SignedData ได้