ใช้ลายเซ็นดิจิทัล PAdES ผ่าน NextPDF Connect (Pro)

ภาพรวมโดยสรุป

ใช้ลายเซ็นดิจิทัลพื้นฐานแบบ PDF Advanced Electronic Signatures (PAdES) กับ PDF ผ่าน NextPDF Connect ด้วย sign_pdf ซึ่งได้รับการตรวจสอบซ้ำเทียบกับ Pro tool provider โดย provider ดังกล่าวลงทะเบียน new SignPdfTool() และใช้ชื่อโพรโทคอลเป็น sign_pdf sign_pdf เป็นเครื่องมือระดับ Pro เมื่อบูต เซิร์ฟเวอร์จะตรวจสอบด้วย class_exists() และลงทะเบียนเฉพาะเมื่อมีการติดตั้งแพ็กเกจ Pro เท่านั้น

โดยค่าเริ่มต้น เครื่องมือนี้จะสร้าง PAdES B-B และสามารถสร้าง PAdES B-T (B-B บวกกับ RFC 3161 signature-time-stamp หนึ่งรายการ) ได้ เฉพาะเมื่อโฮสต์ได้เชื่อมต่อผู้ให้บริการ timestamp เข้ากับเครื่องมือเท่านั้น คำขอไม่สามารถระบุ Time Stamp Authority (TSA) ได้ ระดับการเก็บรักษาระยะยาว (B-LT, B-LTA) และวัสดุสำหรับการตรวจสอบความถูกต้อง (DSS, VRI, LTV) ไม่ เป็นส่วนหนึ่งของเครื่องมือนี้และอยู่นอกขอบเขตนี้

ข้อควรระวัง U-1 NextPDF ไม่ยืนยันการรับรองอิสระใด ๆ ตาม ETSI EN 319 142-1 สำหรับ PAdES B-T นั้น EN 319 142-1 ไม่อยู่ในคอร์ปัสการตรวจสอบ ความถูกต้อง ข้อกำหนด B-T signature-time-stamp ได้รับการตรวจสอบเทียบกับ ETSI EN 319 122-1 §5.3 (พื้นฐาน CAdES ที่ EN 319 142-1/-2 นำเข้า โดยการอ้างอิง) ร่วมกับ RFC 3161, RFC 5652, RFC 5816 และ ISO 32000-2 §12.8 การรองรับโปรไฟล์ B-T ไม่ใช่การรับรองความสอดคล้องหรือความถูกต้องทางกฎหมาย ผู้ตรวจสอบความถูกต้องอิสระเป็นผู้วินิจฉัยข้อนั้น

การติดตั้ง

composer require nextpdf/server
composer require nextpdf/pro

ผูก transport จากนั้นยืนยันว่ามี sign_pdf อยู่ด้วย diagnostic.capabilities สำหรับ B-T โฮสต์ต้องสร้างเครื่องมือพร้อมผู้ให้บริการ timestamp หากไม่มี คำขอ pades_b_t: true จะล้มเหลวพร้อมข้อผิดพลาดชนิดกำหนดไว้ แทนที่จะลดระดับลงอย่างเงียบๆ

ภาพรวมเชิงแนวคิด

sign_pdf คำนวณ digest แบบ byte-range ครอบคลุมทั้งไฟล์ โดยยกเว้นตัวยึดตำแหน่งค่าลายเซ็น (ISO 32000-2 §12.8.1) จากนั้นจะเขียน Cryptographic Message Syntax (CMS) SignedData ที่เข้ารหัสแบบ Distinguished Encoding Rules (DER) ลงในพจนานุกรมลายเซ็น Contents (ISO 32000-2 §12.8.1) อัลกอริทึมที่รองรับคือ RSA-SHA256 (ค่าเริ่มต้น), RSA + SHA-3 (256/384/512), และ Ed25519 สำหรับ transport ที่ไม่เป็นความลับแบบ end-to-end สามารถห่อ payload private_key ขาเข้าไว้ในซอง AES-GCM ที่เป็นทางเลือกได้

การอัปเกรด B-T เมื่อมี pades_b_t: true และ ผู้ให้บริการ timestamp ที่โฮสต์เชื่อมต่อไว้ ลายเซ็นจะถูกอัปเกรดเป็น PAdES B-T: แฮชแบบ byte-range จะถูกส่งไปยัง TSA และฝัง TimeStampToken (ISO 32000-2 §12.8.5) B-T คือ B-B บวกกับ RFC 3161 signature-time-stamp หนึ่งรายการที่บรรจุเป็นแอตทริบิวต์แบบไม่ลงนาม บน CMS SignerInfo โดยตรง (RFC 5652 §5.3) แอตทริบิวต์แบบไม่ลงนามไม่ได้อยู่ภายใต้การคุ้มครองของลายเซ็น ดังนั้น digest ที่ลงนามแบบ B-B และความถูกต้องของ digest ดังกล่าวจึงไม่เปลี่ยนแปลง (RFC 5652 §5.3) ค่าของแอตทริบิวต์คือ SignatureTimeStampToken (ETSI EN 319 122-1 §5.3) B-T ไม่เพิ่มพจนานุกรม Document Security Store (DSS) ไม่มี Validation Related Information (VRI) ไม่มีวัสดุสำหรับการตรวจสอบความถูกต้อง และไม่มีลูป archive-timestamp รายการเหล่านั้นเป็นส่วนเพิ่มระดับ Enterprise ของ B-LT/B-LTA และอยู่นอกขอบเขตของเครื่องมือนี้

ข้อควรระวัง U-1 (ทวนซ้ำที่ข้อกล่าวอ้าง B-T) การรองรับ B-T ในที่นี้ไม่ใช่ การรับรองความสอดคล้องตาม EN 319 142-1 หรือความถูกต้องทางกฎหมาย ผู้ตรวจสอบความถูกต้องอิสระ เป็นผู้วินิจฉัยข้อนั้น EN 319 142-1 ไม่อยู่ในคอร์ปัสการตรวจสอบ B-T อ้างอิง ตาม ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652, RFC 5816 และ ISO 32000-2 §12.8

ผังด้านล่างแสดงเส้นทาง TSA ที่ควบคุมโดยโฮสต์ (คำขอไม่สามารถระบุ TSA ได้) และสาขา B-T แบบ fail-closed (ไม่มีการลดระดับอย่างเงียบๆ)

Diagram

พื้นผิว API

เครื่องมือ	ระดับ	บทบาท	ระดับความเสี่ยง
create_pdf, add_text	Core	สร้างเนื้อหา	ปลอดภัย / ควรระวัง
sign_pdf	Pro	ใช้ PAdES B-B (หรือ B-T ที่ควบคุมโดยโฮสต์)	ต้องอนุมัติ
output_pdf	Core	เรนเดอร์และส่งคืน PDF	ต้องอนุมัติ / ตรวจทาน (base64)

ชื่อเครื่องมือเป็นชื่อโพรโทคอลในรีจิสทรี tool catalog ซึ่งเป็นแคตตาล็อกอ้างอิงหลัก เครื่องมือที่ใช้ได้ขึ้นอยู่กับระดับที่ติดตั้ง และเครื่องมือระดับการเก็บรักษาระยะยาวไม่มีอยู่ใน Pro

ตัวอย่างโค้ด — เริ่มต้นอย่างรวดเร็ว

1. create_pdf → สร้างเนื้อหาด้วย add_text
2. sign_pdf พร้อม certificate (PEM), private_key (PKCS#8 PEM), signer_name, reason, และ algorithm ที่เป็นทางเลือก เว้น pades_b_t ไว้ (หรือกำหนดเป็น false) สำหรับ B-B
3. output_pdf

เครื่องมือนี้ส่งคืนซองผลลัพธ์ดังนี้:

{
  "pdf": "<base64 of the signed PDF>",
  "signature_count": 1,
  "is_complete": true,
  "algorithm": "RSA_SHA256",
  "oid": "<algorithm OID>",
  "digest": "<digest algorithm>",
  "level": "PAdES-B-B",
  "timestamped": false
}

สำหรับลายเซ็น B-T ที่ควบคุมโดยโฮสต์ ให้ส่ง pades_b_t: true โดย level จะกลายเป็น "PAdES-B-T" และ timestamped จะกลายเป็น true

ตัวอย่างโค้ด — การใช้งานจริง

ให้การลงนามเป็นการดำเนินการกับเนื้อหาลำดับสุดท้าย add_text/add_image ใดๆ หลังจาก sign_pdf จะทำให้ลายเซ็นใช้ไม่ได้ บน transport ที่ไม่เป็นความลับ ให้ห่อ private_key ไว้ในซอง AES-GCM transport_encryption (nonce 12 ไบต์; คีย์ 16/24/32 ไบต์) ตรวจสอบว่า level ของผลลัพธ์ตรงกับคำขอ คำขอ pades_b_t: true ที่ส่งไปยังเครื่องมือซึ่งไม่มีผู้ให้บริการจะล้มเหลวอย่างชัดเจน จัดการข้อผิดพลาดนั้น และอย่าลองใหม่เป็น B-B อย่างเงียบๆ

กรณีขอบและข้อควรระวัง

• ใบรับรอง/คีย์ไม่ตรงกัน เครื่องมือจะปฏิเสธคำขอพร้อมข้อผิดพลาดที่ชัดเจน คีย์ส่วนตัวต้องตรงกับคีย์สาธารณะของใบรับรอง
• PEM รูปแบบไม่ถูกต้อง / ใบรับรองหมดอายุ เครื่องมือจะปฏิเสธคำขอ โดยค่าเริ่มต้นจะไม่ลงนามด้วยใบรับรองที่ไม่สามารถแยกวิเคราะห์ได้หรือหมดอายุ
• เนื้อหาหลังการลงนาม เครื่องมือจะปฏิเสธคำขอ — ให้ลงนามเป็นขั้นตอนสุดท้าย
• ร้องขอ B-T แต่ไม่มีผู้ให้บริการ เครื่องมือจะส่งคืนข้อผิดพลาดชนิดกำหนดไว้: ลายเซ็นจะไม่ถูกสร้างขึ้น และจะไม่ถูกลดระดับเป็น B-B อย่างเงียบๆ
• ใบรับรองแบบ self-signed ลายเซ็นจะถูกใช้ แต่โปรแกรมอ่านจะแสดงว่าสถานะความเชื่อถือไม่ทราบ นั่นเป็นพฤติกรรมที่คาดไว้ ไม่ใช่ข้อบกพร่องของเครื่องมือ
• ไม่มี Pro เมื่อมีเฉพาะ Core เซิร์ฟเวอร์จะไม่ลงทะเบียน sign_pdf

ประสิทธิภาพ

การลงนามจะเพิ่มการสร้าง CMS และสำหรับ B-T จะเพิ่มการรับส่งข้อมูลไป-กลับกับ TSA หนึ่งครั้ง งบประมาณครอบคลุมทั้งสองส่วน โปรไฟล์คือ semantic: โทเค็น RFC 3161 โดยธรรมชาติแล้วไม่สามารถทำซ้ำได้ และ digest แบบ byte-range ตาม §12.8.1 จะยกเว้นค่าลายเซ็น ให้ใช้การเปรียบเทียบ AST + ข้อมูลเมตาของลายเซ็นเท่านั้น

หมายเหตุด้านความปลอดภัย

ลายเซ็นให้ความครบถ้วนสมบูรณ์และการพิสูจน์ตัวตนเทียบกับคีย์ที่ใช้ลงนาม ลายเซ็นเพียงอย่างเดียวไม่ทำให้เอกสาร “ปลอดภัย” หรือ “ถูกต้องตามกฎหมาย” หรือรับประกันการห้ามปฏิเสธความรับผิด ผลลัพธ์เหล่านั้นขึ้นอยู่กับ trust anchor ของใบรับรอง การเก็บรักษาคีย์ และนโยบายของผู้ตรวจสอบ ซึ่งทั้งหมดอยู่นอกเครื่องมือนี้ การเข้ารหัสลับ payload ของคีย์ด้วยซอง AES-GCM ปกป้องความลับระหว่างทาง ไม่ใช่ความครบถ้วนสมบูรณ์ ให้ปฏิบัติต่อคีย์ส่วนตัวเสมือนเป็นความลับ และควรใช้ซอง transport-encryption บนช่องทางใดๆ ที่ไม่เป็นความลับ

ความสอดคล้อง

ข้อความ	ข้อกำหนด	ข้อ	รหัสอ้างอิง (reference_id)
digest แบบ byte-range ครอบคลุมทั้งไฟล์และยกเว้นค่าลายเซ็น	ISO 32000-2	§12.8.1
Contents บรรจุ CMS SignedData ที่เข้ารหัสแบบ DER	ISO 32000-2	§12.8.1
สำหรับ timestamp แฮชแบบ byte-range จะไปยัง TSA และวางโทเค็นไว้ใน Contents	ISO 32000-2	§12.8.5
time-stamp แบบ B-T เป็นแอตทริบิวต์แบบไม่ลงนามบน SignerInfo	RFC 5652	§5.3
แอตทริบิวต์แบบไม่ลงนามไม่เปลี่ยนแปลง B-B signed digest/validity	RFC 5652	§5.3
ค่า signature-time-stamp เป็น SignatureTimeStampToken	ETSI EN 319 122-1	§5.3

NextPDF สร้างโครงสร้างลายเซ็น แต่ไม่ยืนยันว่าลายเซ็นที่ได้สอดคล้องหรือถูกต้องตามกฎหมาย ผู้ตรวจสอบความถูกต้องอิสระเป็นผู้วินิจฉัย เครื่องมือนี้ไม่สร้าง B-LT/B-LTA

บริบทเชิงพาณิชย์

sign_pdf เป็นเครื่องมือระดับ Pro เซิร์ฟเวอร์จะลงทะเบียนเครื่องมือนี้เฉพาะเมื่อแพ็กเกจ Pro resolve สำเร็จขณะบูตเซิร์ฟเวอร์เท่านั้น ระดับการเก็บรักษาระยะยาวของ PAdES (B-LT, B-LTA) และวัสดุสำหรับการตรวจสอบความถูกต้อง (DSS, VRI, LTV) เป็น Enterprise เท่านั้น และไม่ได้เปิดเผยผ่านเครื่องมือนี้หรือสูตรนี้

ที่ตั้งของข้อมูลและการลดความเสี่ยง PII

ใบรับรองและคีย์ส่วนตัวเดินทางผ่านคำขอ ใช้ซอง AES-GCM transport_encryption บนช่องทางใดๆ ที่ไม่เป็นความลับแบบ end-to-end PDF ที่ลงนามและข้อมูลระบุตัวตนของผู้ลงนาม (signer_name, reason) เป็นเนื้อหาของเอกสาร ดังนั้นจึงควรเก็บไว้ภายในขอบเขตที่ตั้งข้อมูลของการปรับใช้ ผู้ผสานรวมเป็นผู้รับผิดชอบที่ตั้งข้อมูลในระดับการปรับใช้

การวัดและส่งข้อมูลอย่างปลอดภัยและการล้างบันทึก

อย่าบันทึก payload private_key คีย์/nonce ของ AES-GCM (key/nonce) หรือโทเค็นยืนยัน ให้บันทึกอัลกอริทึม level ที่ได้ และ signature_count ไม่ใช่วัสดุคีย์ เครื่องมือนี้ไม่ปล่อยไบต์ของคีย์ออกมาในผลลัพธ์

แบบจำลองภัยคุกคาม

ภัยคุกคามที่พิจารณา: การเปิดเผยคีย์ระหว่างทาง (ลดความเสี่ยงด้วยซอง AES-GCM และผู้ให้บริการ TSA ที่โฮสต์ฉีดเข้าและไม่สามารถกำหนดค่าผ่านคำขอได้); ผู้เรียก MCP ระบุ timestamp ไปยังปลายทางใดๆ (ป้องกันได้เพราะผู้ให้บริการถูกฉีดโดยโฮสต์ ไม่สามารถกำหนดค่าผ่านคำขอได้); และการดัดแปลงหลังการลงนาม (digest แบบ byte-range ตรวจจับการแก้ไข) แบบจำลองภัยคุกคามนี้บันทึกภัยคุกคามที่พิจารณาและการลดความเสี่ยง ไม่ได้ยืนยันว่าไม่มีช่องโหว่

พฤติกรรมในโหมด FIPS

การเลือกอัลกอริทึม (RSA-SHA256, RSA + SHA-3, Ed25519) ขับเคลื่อนโดยคำขอ OpenSSL ของโฮสต์เป็นผู้จัดเตรียมพื้นฐานทางการเข้ารหัสลับ ในการปรับใช้ที่ถูกจำกัดด้วย FIPS ให้จำกัดอัลกอริทึมที่ชั้นนโยบายและพึ่งพาโมดูลที่ผ่านการตรวจรับรองของโฮสต์ เครื่องมือนี้ไม่ได้ยืนยันการตรวจรับรอง Federal Information Processing Standards (FIPS) ด้วยตนเอง

ความพร้อมใช้งานของ transport

การรับส่งข้อมูล (Transport)	ใช้ได้	หมายเหตุ
MCP (stdio)	ใช่ (Pro)	ใช้ซองจดหมายคีย์ AES-GCM บน stdio
REST	ใช่ (Pro)	ควรใช้ TLS ร่วมกับซองจดหมายคีย์
gRPC	ใช่ (Pro)	ควรใช้ TLS ร่วมกับซองจดหมายคีย์

ระดับความเสี่ยง HITL

sign_pdf จัดอยู่ในระดับต้องอนุมัติเพราะเป็นการดำเนินการที่ทำลายล้างและย้อนกลับไม่ได้ เครื่องมือนี้ประกาศ hint ว่าเป็นการทำลายล้าง เกตการยืนยันมีผลเช่นเดียวกับเครื่องมือระดับต้องอนุมัติอื่นๆ output_pdf ไปยังไฟล์ก็อยู่ในระดับต้องอนุมัติเช่นกัน ส่วนโหมด base64 อยู่ในระดับตรวจทาน (HITL risk tiers)

ซอง JSON ของเกตการยืนยัน

sign_pdf ที่ไม่มีโทเค็นที่ถูกต้องจะส่งคืนซองคำท้า:

{
  "allowed": false,
  "challenge": "⚠️ CONFIRMATION REQUIRED\n\nOperation: sign_pdf\nDescription: <tool description>\n\nTo proceed, call sign_pdf again with parameter _confirmation_token: \"confirm_<single-use-hex>\"\nExpires in 300 seconds.",
  "token": "confirm_<single-use-hex>"
}

เรียกอีกครั้งโดยกำหนด _confirmation_token เป็นโทเค็น → { "allowed": true } ขั้นตอนแบบเต็ม: output-approval

ดูเพิ่มเติม

• ดึงเนื้อหาข้อความ
• ตรวจสอบการเข้าถึง
• ระดับความเสี่ยง HITL
• แคตตาล็อกเครื่องมือ