Security — เอกสารอ้างอิงเชิงลึก

โดยสรุป

นี่คือเอกสารอ้างอิงเชิงลึกสำหรับพื้นผิวความปลอดภัยของ NextPDF Pro ได้แก่ การปิดบังในเวลาสร้าง การตรวจจับ PII ในชั้นข้อความ เซสชันการลงนามแบบ remote และ cloud-KMS การลงนามตามลำดับแบบหลายฝ่าย เส้นทาง ingest แบบ CAdES และ XAdES ระดับพื้นฐาน PAdES B-B และการรองรับการลงนาม PAdES B-T (ลายเซ็น B-B พร้อม RFC 3161 signature-time-stamp หนึ่งรายการบนค่าลายเซ็น) หน้านี้ระบุสัญญา public-API พฤติกรรมที่สังเกตได้จากภายนอก และขอบเขต B-LT/B-LTA ของ Enterprise เนื้อหาอยู่ในระดับพฤติกรรมและไม่อ้างอิงเส้นทางการนำไปใช้จริงภายในใด ๆ

ความพร้อมใช้งานและการอนุญาตใช้สิทธิ์

ความสามารถนี้จัดส่งมาใน NextPDF Pro (nextpdf/pro) และเปิดใช้งานด้วยซองใบอนุญาตระดับ Pro การปรับใช้ที่ไม่มีสิทธิ์นั้นจะไม่โหลดคลาสของความสามารถนี้ เปรียบเทียบรุ่นและรับใบอนุญาต

Core มาพร้อมตัวลงนาม CMS แบบซอฟต์แวร์ ไคลเอนต์การประทับเวลา RFC 3161 การตรวจสอบเส้นทาง RFC 5280 และการตรวจสอบการเพิกถอนด้วย OCSP และ CRL Pro เพิ่มการปิดบัง การตรวจจับ PII พื้นผิวการลงนามแบบ remote และ cloud-KMS และการรองรับการลงนาม PAdES B-T (โดยประกอบ stack RFC 3161 ของ Core เพื่อเพิ่ม signature-time-stamp) ตามที่อธิบายไว้ที่นี่ แฟล็กความสามารถสำหรับพื้นผิวนี้คือ pro การปรับใช้ที่ไม่มีสิทธิ์ Pro ที่ใช้งานอยู่จะไม่โหลดคลาสเหล่านี้ สัญญาการลงนามของ Core ยังคงทำงานได้โดยไม่เปลี่ยนแปลง และโค้ดที่ขึ้นอยู่กับสัญญาของ Core จะไม่เสียหายเมื่อไม่มีสิทธิ์

การติดตั้ง

composer require nextpdf/pro:^3

สัญญาพฤติกรรม

เอนจินการปิดบังใช้รายการกฎที่มีลำดับกับข้อความก่อนที่หน้าจะถูกเขียน กฎจะ match รูปแบบ PCRE และแทนที่ match ในหนึ่งในสามโหมด:

• BlackBox ลบข้อความที่ match ออกจาก content stream และจองบริเวณเติม โหมดนี้ลบ text object ที่อยู่เบื้องล่างตามที่ได้ทดสอบไว้
• Asterisks แทนที่อักขระที่ match แต่ละตัวด้วยเครื่องหมายดอกจัน โดยรักษาจำนวนอักขระไว้
• FixedLabel แทนที่ match ทั้งหมดด้วยป้ายกำกับที่กำหนดค่าได้ ค่าเริ่มต้นคือ [REDACTED]

กฎถูกสร้างจาก literal ที่แน่นอนผ่าน MaskingRule::exactMatch (literal ถูก regex-escape) หรือจากรูปแบบ PCRE ที่กำหนดเองผ่าน MaskingRule::regex MaskingConfig เก็บรายการกฎที่มีลำดับ โหมดเริ่มต้น และสีเติม MaskingConfig::fromArray แจง configuration map และตัดรายการกฎที่ไม่มีรูปแบบสตริงที่ใช้งานได้ทิ้งอย่างเงียบ ๆ แทนที่จะทำให้การ import ทั้งหมดล้มเหลว

พื้นผิว PII สกัดชั้นข้อความของ PDF แล้วใช้รูปแบบในตัวสำหรับที่อยู่อีเมล หมายเลขโทรศัพท์ หมายเลขประกันสังคมของสหรัฐอเมริกา และหมายเลขบัตรเครดิต โดยคืนผลลัพธ์ที่มีโครงสร้าง ได้แก่ boolean ว่าพบ match ใดหรือไม่ จำนวน match มุมมองข้อความที่ปิดบังแล้ว และรายการชนิดที่สแกน ผู้เรียกใช้อาจจำกัดการสแกนให้เป็นชุดย่อยของทั้งสี่ชนิด พื้นผิวนี้ไม่เขียนทับ glyph ที่เรนเดอร์บนหน้า หน้าที่สแกนแล้วซึ่งไม่มีชั้นข้อความจะไม่ให้ match ใด ให้ถือผลลัพธ์เป็นการตรวจจับรูปแบบในชั้นข้อความของชนิดที่กำหนดค่าไว้ ไม่ใช่การลบข้อมูลส่วนบุคคลอย่างสมบูรณ์ และไม่ใช่คำแถลงด้านการปฏิบัติตามกฎระเบียบ

เซสชันการลงนามมีสองเฟส RemoteSigningSession::create เปิดเซสชัน prepare คำนวณ digest ของเอกสารบนสองบริเวณ ByteRange แล้วสร้างแอตทริบิวต์ที่ลงนามแล้วของ CMS complete เรียกใช้กลยุทธ์และฝังผลลัพธ์ ส่วน suspend ทำการ serialize เซสชันเพื่อให้ worker กลับมาทำต่อภายหลังด้วย resume และ completeWithRawSignature เซสชันประกอบ CMS SignedData และจัดเก็บแบบเข้ารหัส DER ในรายการ Contents ของพจนานุกรมลายเซ็น — ISO 32000-2 §12.8.1 เมื่อมีการให้ใบรับรอง X.509 ที่แจงได้ เซสชันจะ emit ชุดแอตทริบิวต์ที่ลงนามแล้วที่บังคับของ PAdES B-B ครบถ้วน ได้แก่ content-type, message-digest, signing-time, signing-certificate-v2 และแอตทริบิวต์การป้องกันอัลกอริทึม — RFC 5652 §5.3 และ RFC 5652 §5 ผู้ตรวจสอบคำนวณ digest ของเนื้อหาใหม่และเปรียบเทียบกับแอตทริบิวต์ message-digest การเปรียบเทียบต้องตรงกันลายเซ็นจึงจะถูกต้อง — RFC 5652 §5.4

เมื่อระดับ PAdES ที่กำหนดค่าไว้เป็น B-T (RemoteSigningConfig::default->withLevel(SignatureLevel::PAdES_B_T) หรือผ่าน SequentialSigner::withTimestamping) และมีการต่อสายผู้ให้บริการการประทับเวลา เซสชันจะฝัง RFC 3161 signature-time-stamp เพิ่มเข้ามาหนึ่งรายการพอดีเป็นแอตทริบิวต์ CMS แบบ unsigned บน SignerInfo แรก signature-time-stamp เป็นแอตทริบิวต์ที่ไม่ลงนามซึ่งบรรจุโทเค็นการประทับเวลาหนึ่งรายการที่คำนวณบนค่าลายเซ็นดิจิทัลสำหรับผู้ลงนาม — ETSI EN 319 122-1 §5.3 ส่วน MessageImprint ของมันคือ hash ของค่าฟิลด์ลายเซ็นใน SignerInfo โดยไม่รวม ASN.1 tag และ length — ETSI EN 319 122-1 §5.3 และ RFC 3161 Appendix A (OID id-aa-timeStampToken = 1.2.840.113549.1.9.16.2.14) เนื่องจากการประทับเวลาเป็นแอตทริบิวต์แบบ unsigned แอตทริบิวต์ที่ลงนามแล้วของ B-B, message-digest, ค่าลายเซ็นของ SignerInfo และ /ByteRange ของ PDF จึงเหมือนกันในระดับไบต์กับผลลัพธ์ B-B มีเพียง CMS ที่ขยายขึ้นด้วยแอตทริบิวต์ที่ไม่ลงนาม และพื้นที่ /Contents ที่จองไว้สำหรับ B-T ถูกเพิ่มขึ้นเพื่อให้พอดี โทเค็นถูกร้องขอจากผู้ให้บริการการประทับเวลาที่กำหนดค่าไว้ (ไคลเอนต์ RFC 3161 ของ Core ที่เป็นค่าเริ่มต้น หรือผู้ให้บริการที่ผู้เรียกใช้จัดหา) ในเส้นทางผู้ให้บริการเริ่มต้น imprint digest คือ SHA-256 รูปแบบ ESSCertID v1 แบบเดิมที่ผูกกับ SHA-1 ถูกปฏิเสธ และต้องใช้ ESSCertIDv2 — RFC 5816 §1 ความผิดพลาดของ TSA คำขอที่ถูกปฏิเสธ nonce หรือ message-imprint echo ที่ผิด โทเค็นที่ผิดรูปแบบหรือใช้อัลกอริทึมที่ไม่รองรับ หรือโทเค็นที่ไม่ผ่านการตรวจสอบเชิงการเข้ารหัสลับ จะปรากฏเป็น PadesBt exception ที่มีชนิด โดย exception ของ Core ต้นทางถูกเก็บรักษาไว้เป็น previous throwable NextPDF Pro นำการรองรับการลงนาม PAdES B-T มาใช้ตาม ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 และ RFC 5816 และได้รับการตรวจสอบด้วย fixture แต่ ไม่ อ้างการรับรอง ETSI EN 319 142-1 อิสระและไม่อ้างความถูกต้องทางกฎหมายของเอกสาร

SequentialSigner ประสานงานการลงนามแบบหลายฝ่าย ผู้ลงนามแต่ละรายเป็น revision แบบ incremental-update แยกกัน ผู้ลงนามรายแรกอาจเป็นลายเซ็นรับรองที่มีข้อจำกัด DocMDP ที่ตั้งผ่าน certifyFirst PadesWrapper รับ ingest ลายเซ็นที่มีอยู่แล้ว fromCades ฝังโครงสร้าง CMS โดยตรง fromXades แจงเอกสาร XAdES และนำวัสดุลายเซ็นหลักของมันมาใช้ซ้ำ ส่วน detect เลือกอัตโนมัติตามรูปแบบ เส้นทาง XAdES นำใบรับรอง ห่วงโซ่ ค่าลายเซ็น และอัลกอริทึมมาใช้ซ้ำ แต่ไม่ถ่ายโอน qualifying property ของ XAdES

พื้นผิว public API

composer require nextpdf/pro:^3

Type	Kind	Role	Stability	Since
RemoteSigningSession	class	เซสชันการลงนามแบบ remote หรือ asynchronous สองเฟส	stable	1.9.0
RemoteSigningConfig	class	การกำหนดค่าเซสชันแบบ immutable รวมถึงระดับ PAdES และอัลกอริทึม	stable	1.9.0
SequentialSigner	class	การลงนามตามลำดับแบบหลายฝ่ายพร้อมการรองรับ DocMDP	stable	1.9.0
SequentialSigningResult	class	ผลลัพธ์ของการรันตามลำดับ ได้แก่ ไบต์ PDF ห่วงโซ่ จำนวน ความครบถ้วน	stable	1.9.0
SigningStrategy	interface	สัญญากลไกการลงนามที่เซสชันเรียกใช้	stable	1.9.0
PadesWrapper	class	ห่อหุ้มลายเซ็น CAdES หรือ XAdES ที่มีอยู่แล้วเพื่อฝังแบบ PAdES	stable	1.9.0
KmsSignerInterface	interface (SPI)	สัญญา driver ของ HSM และ KMS จากบุคคลที่สาม ต่อยอดจากสัญญาตัวลงนาม HSM ของ Core	stable	2.1.0
SignatureAlgorithm	enum	OID อัลกอริทึมลายเซ็นและชื่อ digest ของ Pro	stable	2.1.0
GenerationTimeMasker	class	การปิดบังที่ขับเคลื่อนด้วยกฎ ใช้ก่อนที่หน้าจะถูกเขียน	stable	1.9.0
MaskingConfig	class	การกำหนดค่าการปิดบังแบบ immutable	stable	1.9.0
MaskingRule	class	กฎการปิดบังหนึ่งกฎ (literal หรือ PCRE)	stable	1.9.0
MaskingMode	enum	BlackBox, Asterisks, FixedLabel	stable	1.9.0

สัญญา SigningStrategy

กลยุทธ์ทำงานบนแอตทริบิวต์ที่ลงนามแล้วซึ่งเข้ารหัส DER และคืนไบต์ลายเซ็นดิบ เซสชัน ไม่ใช่กลยุทธ์ เป็นผู้ประกอบ CMS SignedData กลยุทธ์เปิดเผย DER ของใบรับรองผู้ลงนาม DER ของห่วงโซ่ที่เรียงจาก leaf ไป root, OID อัลกอริทึมลายเซ็น ชื่ออัลกอริทึม digest และแฟล็ก isAsync ที่ระบุกลยุทธ์ซึ่งเซสชันสามารถถูก serialize และกลับมาทำต่อได้

SPI KmsSignerInterface

KmsSignerInterface ต่อยอดจากสัญญาตัวลงนาม HSM ของ Core โดยเพิ่ม providerId ที่เสถียรสำหรับการค้นหาใน registry เมธอด signWithVersion ที่มีพารามิเตอร์ key-version แบบชัดเจนต่อการเรียก และ supportsAlgorithm กับ supportedAlgorithms เพื่อให้ผู้เรียกใช้ค้นพบความเข้ากันได้ของอัลกอริทึมก่อนการเรียกลงนาม ตัวระบุผู้ให้บริการในตัวที่สงวนไว้ ได้แก่ aws-kms, azure-keyvault, gcp-kms, pkcs11, openssl-cli และ openssl-engine driver จากบุคคลที่สามต้องใส่ namespace ให้ตัวระบุของตนเพื่อเลี่ยงการชนกัน ความหมายของ key-version เริ่มต้นแตกต่างกันตามผู้ให้บริการ ผู้ให้บริการที่ resolve alias จะ resolve คีย์ที่ใช้งานอยู่จาก alias เมื่อ version เป็น null ผู้ให้บริการที่เลือก version ที่เปิดใช้งานล่าสุดจะทำเช่นนั้นผ่าน transport ของตน ผู้ให้บริการที่ไม่มีแนวคิด active-version ฝั่งเซิร์ฟเวอร์ต้องใช้ version ที่ปักหมุดไว้ในการกำหนดค่าของตน และต้องยกข้อผิดพลาดด้านการจัดการคีย์เมื่อทั้งการเรียกและการกำหนดค่าไม่ได้ปักหมุด version version ที่ไม่ว่างจะปักหมุด version นั้น และผู้ให้บริการต้องยกข้อผิดพลาดด้านการจัดการคีย์เมื่อ version นั้นไม่รู้จัก ถูกปิดใช้งาน หรือถูกเพิกถอน

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

• ลายเซ็นที่ผลิตขึ้นไม่ใช่ลายเซ็นที่ผ่านการตรวจสอบ การตรวจสอบเส้นทางทำงานที่ฝ่ายตรวจสอบด้วย trust anchor และการตรวจสอบ basic-constraint ของฝ่ายตรวจสอบนั้น — RFC 5280 §6.1 ฝ่ายผู้ผลิตไม่สามารถยืนยันผลลัพธ์ได้
• เซสชันมีการถอยกลับแบบสามแอตทริบิวต์แบบเดิมสำหรับไบต์ใบรับรองสังเคราะห์ที่ไม่ใช่ X.509 กลยุทธ์การใช้งานจริงจะให้ DER ของ X.509 จริงเสมอ ดังนั้นชุดแอตทริบิวต์ B-B ครบถ้วนจึงเป็นเส้นทางการใช้งานจริง การถอยกลับมีไว้สำหรับพื้นผิวการทดสอบกลไก DER แบบเดิมเท่านั้น
• โครงสร้าง CMS ต้องพอดีกับพื้นที่ Contents ที่จองไว้ B-B SignedData ที่มีห่วงโซ่ใบรับรองครบถ้วนมีขนาดหนึ่ง เซสชันจะยกข้อผิดพลาด overflow เมื่อ CMS ที่ประกอบเกินพื้นที่ hex ที่จองไว้ ให้กำหนดขนาดพื้นที่ที่จองไว้ให้เหมาะสม สำหรับ B-T โทเค็น RFC 3161 ที่ฝัง (ซึ่งครอบงำด้วยห่วงโซ่ใบรับรองของ TSA) จะขยาย CMS พื้นที่ที่จองไว้สำหรับ B-T ถูกเพิ่มอัตโนมัติ และพื้นที่ที่กำหนดค่าไว้เล็กเกินไปจะ fail closed พร้อมข้อผิดพลาดการกำหนดค่าที่มีชนิดแทนที่จะตัดทอน
• MaskingConfig::fromArray ตัดรายการที่ไม่มีรูปแบบสตริงที่ใช้งานได้ทิ้งแทนที่จะทำให้การ import ล้มเหลว ให้ตรวจสอบแหล่งการกำหนดค่าหากการตัดทิ้งอย่างเงียบ ๆ ยอมรับไม่ได้
• โหมด black-box ของการปิดบัง emit การแทนที่ว่างสำหรับ run ที่ match และลบข้อความที่อยู่เบื้องล่าง กฎที่ไม่ match ค่าใดจะไม่ปิดบังค่านั้น เอนจินไม่ยืนยันว่าพบเนื้อหาอ่อนไหวทั้งหมด
• B-T ต้องมีผู้ให้บริการการประทับเวลาที่ต่อสายไว้ ในเส้นทางผู้ให้บริการ RFC 3161 ของ Core ที่เป็นค่าเริ่มต้น imprint digest คือ SHA-256 imprint digest ที่ไม่ใช่ SHA-256 บนเส้นทางนั้นจะถูกปฏิเสธพร้อมข้อผิดพลาดการกำหนดค่าที่มีชนิดแทนที่จะลดระดับอย่างเงียบ ๆ และผู้ให้บริการที่กำหนดเองซึ่งผู้เรียกใช้จัดหาอาจใช้ digest ที่ได้รับอนุมัติอื่นได้อย่างถูกต้อง serialNumber ของการประทับเวลาไม่ซ้ำกันต่อโทเค็นจาก Time-Stamping Authority หนึ่งราย และ genTime คือเวลา UTC ที่สร้างโทเค็น — RFC 3161 §2.4.1, §2.4.2 วัสดุการตรวจสอบความถูกต้องแบบระยะยาวของ B-LT/B-LTA ยังคงเป็นเรื่องของขอบเขต Enterprise Pro ไม่ผลิต DSS, VRI หรือการประทับเวลาเอกสารใด ๆ
• OCSP unknown ไม่ใช่ good และความใหม่ของสถานะถูกกำหนดขอบเขตด้วย thisUpdate และ nextUpdate — RFC 6960 §2.2, §4.2

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

Pro เลือกอัลกอริทึมจากอัลกอริทึมลายเซ็นที่กำหนดค่าไว้และจากกลยุทธ์ เมื่อกำหนดค่าให้ใช้ KMS หรือ HSM ที่ผ่านการตรวจรับรอง FIPS การดำเนินการเชิงการเข้ารหัสลับจะทำงานในขอบเขตที่ผ่านการตรวจรับรองนั้น และชุดอัลกอริทึมคือสิ่งที่ขอบเขตนั้นอนุญาต NextPDF Pro ทำการประกอบ CMS เชิงโครงสร้างและคำนวณ digest มันไม่ใช่โมดูลการเข้ารหัสลับที่ผ่านการตรวจรับรอง FIPS และไม่กล่าวอ้างการรับรอง FIPS การปรับใช้ที่ต้องการท่าที FIPS ต้องกำหนดค่าให้ใช้ KMS หรือ HSM ที่ผ่านการตรวจรับรอง FIPS และโปรไฟล์นโยบายการเข้ารหัส FIPS 140-3 เป็นความสามารถของ Enterprise

ท่าทีการควบคุมการส่งออก

โมดูลนี้เกี่ยวข้องกับฟังก์ชันการเข้ารหัสลับ ให้ถือว่าเป็นเรื่องอ่อนไหวด้านความปลอดภัยในการตรวจทานของคุณเอง

ขอบเขต Enterprise

NextPDF Pro ผลิตระดับพื้นฐาน B-B และระดับ B-T สำหรับ B-B เซสชันประกอบ CMS SignedData ด้วยชุดแอตทริบิวต์ที่ลงนามแล้วของ B-B และไม่ใช้การประทับเวลา สำหรับ B-T จะเพิ่ม RFC 3161 signature-time-stamp หนึ่งรายการพอดีเป็นแอตทริบิวต์ CMS แบบ unsigned ที่คำนวณบนค่าลายเซ็นดิจิทัลสำหรับผู้ลงนาม — ETSI EN 319 122-1 §5.3 NextPDF Pro นำสิ่งนี้มาใช้ตาม ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 และ RFC 5816 และได้รับการตรวจสอบด้วย fixture มัน ไม่ อ้างการรับรอง ความสอดคล้อง หรือการปฏิบัติตาม ETSI EN 319 142-1 อิสระ และไม่อ้างความถูกต้องทางกฎหมายของเอกสาร

ระดับ B-LT และ B-LTA เป็นความสามารถของ Enterprise และ ไม่ ถูกผลิตโดย Pro B-LT และ B-LTA เพิ่ม Document Security Store และการประทับเวลาเอกสารสำหรับการตรวจสอบความถูกต้องเพื่อการเก็บถาวรระยะยาว — ETSI EN 319 142-2 §5.5 ตัวจัดการลายเซ็นที่ผลิตระดับเหล่านั้นรองรับรายการ DSS และการประทับเวลาเอกสาร — ETSI EN 319 142-2 §6.3.3.3 RemoteSigningConfig ของ Pro สามารถพกระดับที่สูงกว่า B-T (B-LT หรือ B-LTA) ที่ร้องขอ Document Security Store แต่ Pro ไม่ได้จัดส่งตัวสร้างนั้นและไม่ดำเนินการกับมัน ระดับเช่นนั้นเป็นค่าที่ประกาศไว้ล่วงหน้า กระแสการลงนามของ Core resolve ตัวสร้างแบบระยะยาวในขณะรันไทม์ผ่านสัญญาของ Core และตัวสร้างนั้นจัดส่งมาในแพ็กเกจ nextpdf/enterprise ในการปรับใช้แบบ Pro เท่านั้น การร้องขอ B-LT หรือ B-LTA จะ fail closed พร้อมข้อความที่ระบุชื่อส่วนประกอบ Enterprise ที่ขาดหายไป Pro ไม่ผลิต DSS, พจนานุกรม VRI, การประทับเวลาเอกสาร หรือลูปการเก็บถาวรใด ๆ และไม่กล่าวอ้างการตรวจสอบความถูกต้องแบบระยะยาว (LTV) การเก็บรักษาคีย์ในฮาร์ดแวร์ผ่าน PKCS#11 และโปรไฟล์นโยบายการเข้ารหัส FIPS 140-3 ก็เป็นความสามารถของ Enterprise เช่นกัน หน้านี้ไม่ได้บันทึกการนำการตรวจสอบความถูกต้องแบบระยะยาวของ Enterprise ไปใช้จริง แต่ระบุเฉพาะขอบเขตและชื่อแพ็กเกจสาธารณะเท่านั้น

PAdES level	Adds	Producer edition
B-B	ลายเซ็น CMS พร้อมแอตทริบิวต์ที่ลงนามแล้ว	Core, Pro
B-T	แอตทริบิวต์ RFC 3161 signature-time-stamp แบบ unsigned หนึ่งรายการบนค่าลายเซ็น	Core, Pro
B-LT	Document Security Store พร้อมวัสดุการตรวจสอบความถูกต้อง	Enterprise (nextpdf/enterprise)
B-LTA	การประทับเวลาเอกสารสำหรับความถูกต้องเพื่อการเก็บถาวร	Enterprise (nextpdf/enterprise)

ขอบเขตการเผยแพร่

หน้านี้บันทึกเฉพาะพฤติกรรมที่สังเกตได้จากภายนอกและพื้นผิว public API ที่รองรับเท่านั้น เส้นทาง namespace ภายใน คลาส helper ตารางกลไก ชื่อไฟล์ runbook และคำนำหน้า ticket อยู่นอกขอบเขต

การถอยกลับไปใช้ Core

การปรับใช้ที่ไม่มีสิทธิ์ Pro ยังคงสัญญาการลงนามของ Core ไว้ โค้ดที่ขึ้นอยู่กับสัญญา SignerInterface ของ Core ยังคงลงนามด้วยตัวลงนาม CMS แบบซอฟต์แวร์ที่ระดับพื้นฐาน B-B การปิดบัง การตรวจจับ PII และกลยุทธ์การลงนามแบบ remote และ cloud-KMS จะไม่มีอยู่หากไม่มีแพ็กเกจ Pro และการเรียกเข้าไปยังชนิดเหล่านั้นเป็นข้อผิดพลาดด้าน dependency ที่เด็ดขาด ไม่ใช่ no-op แบบเงียบ ๆ

ถิ่นที่อยู่ของข้อมูลและมาตรการลด PII

พื้นผิวการปิดบังและ PII ทำงานในกระบวนการ ไม่มีเนื้อหาเอกสารออกจากโฮสต์สำหรับการปิดบังหรือการตรวจจับ PII กลยุทธ์ cloud-KMS ส่ง digest ของแอตทริบิวต์ที่ลงนามแล้ว ไม่ใช่เอกสาร ไปยังผู้ให้บริการสำหรับการดำเนินการลงนาม การตรวจจับ PII เป็นการ match รูปแบบบนชนิดที่กำหนดค่าไว้ และลบ text object ที่อยู่เบื้องล่างสำหรับโหมด black-box ตามที่ได้ทดสอบไว้ มันไม่ใช่การรับประกันการลบข้อมูลส่วนบุคคลอย่างสมบูรณ์และไม่ใช่คำแถลงด้านการปฏิบัติตามกฎระเบียบ

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

ไลบรารียกข้อยกเว้นที่มีชนิดพร้อมข้อความเชิงโครงสร้าง มันไม่เขียนเนื้อหาเอกสารหรือค่า PII ที่ตรวจพบลงในข้อความข้อยกเว้นหรือบันทึก การปรับใช้ที่บันทึกรอบ ๆ เส้นทางการลงนามควรบันทึกฟิลด์เชิงโครงสร้าง ไม่ใช่ไบต์ของเอกสาร

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

Claim	Standard	Clause
ลายเซ็น CMS ถูกจัดเก็บแบบเข้ารหัส DER ในรายการ Contents ของพจนานุกรมลายเซ็น	ISO 32000-2	§12.8.1
กระบวนการคำนวณ message digest แอตทริบิวต์ที่ลงนามแล้วพก content-type และ message-digest	RFC 5652	§5.4
ผู้ตรวจสอบต้องไม่พึ่งพา digest ที่ผู้สร้างคำนวณ แต่คำนวณใหม่อย่างอิสระและเปรียบเทียบ (กระบวนการตรวจสอบลายเซ็น)	RFC 5652	§5.6
SignerInfo พกตัวระบุอัลกอริทึม digest และบล็อกแอตทริบิวต์ที่ลงนามแล้ว	RFC 5652	§5
คำขอประทับเวลาคืนค่าโครงสร้าง TSTInfo	RFC 3161	§2.4.1
serialNumber ของการประทับเวลาไม่ซ้ำกันต่อโทเค็นจาก TSA หนึ่งราย	RFC 3161	§2.4.2
genTime ของการประทับเวลาคือเวลา UTC ที่สร้างโทเค็น	RFC 3161	§2.4.2
PAdES B-T signature-time-stamp เป็นแอตทริบิวต์ที่ไม่ลงนามซึ่งบรรจุโทเค็นการประทับเวลาหนึ่งรายการที่คำนวณบนค่าลายเซ็นดิจิทัลสำหรับผู้ลงนาม (Pro ผลิต B-T)	ETSI EN 319 122-1	§5.3
imprint ของ signature-time-stamp คือ hash ของค่าฟิลด์ลายเซ็นใน SignerInfo โดยไม่รวม ASN.1 tag และ length	ETSI EN 319 122-1	§5.3
โทเค็น signature-time-stamp ใช้ OID id-aa-timeStampToken ส่วน MessageImprint ของมันเป็น hash ของค่าฟิลด์ลายเซ็นใน SignerInfo	RFC 3161	Appendix A
ในฝั่งการตรวจสอบ NextPDF ผูก MessageImprint ของ signature-time-stamp เข้ากับค่าลายเซ็นของ SignerInfo และ fail closed เมื่อไม่ตรงกัน โทเค็นขาดหาย/ซ้ำซ้อน หรือ imprint แบบ SHA-1 (การตรวจสอบแบบเข้มงวด ไม่ใช่การรับรอง)	RFC 3161	Appendix A
ESSCertIDv2 แทนที่ ESSCertID แบบเดิมที่ผูกกับ SHA-1 เส้นทาง B-T แบบเข้มงวดต้องใช้ ESSCertIDv2	RFC 5816	§1
การตรวจสอบเส้นทางการรับรองตรวจสอบ basic constraint และอินพุตเส้นทางไปยัง trust anchor	RFC 5280	§6.1
OCSP รายงาน certStatus เป็น good, revoked หรือ unknown	RFC 6960	§2.2
ความใหม่ของสถานะ OCSP ถูกกำหนดขอบเขตด้วย thisUpdate และ nextUpdate	RFC 6960	§4.2
B-LT และ B-LTA เพิ่ม Document Security Store และการประทับเวลาเอกสารสำหรับการตรวจสอบความถูกต้องแบบระยะยาว (ขอบเขต Enterprise)	ETSI EN 319 142-2	§5.5
ตัวจัดการลายเซ็นที่ผลิตระดับระยะยาวรองรับรายการ DSS และการประทับเวลาเอกสาร (ขอบเขต Enterprise)	ETSI EN 319 142-2	§6.3.3.3

ทุกข้อกำหนดเป็นการถอดความ NextPDF ไม่ได้ทำซ้ำข้อความเชิงบรรทัดฐาน โปรดดูมาตรฐานที่เผยแพร่เพื่อถ้อยคำที่เป็นทางการ NextPDF Pro นำการรองรับการลงนาม PAdES B-T มาใช้ตาม ETSI EN 319 122-1 §5.3 (signature-time-stamp), RFC 3161, RFC 5652 และ RFC 5816 และได้รับการตรวจสอบด้วย fixture ส่วน ETSI EN 319 142-1 (ส่วนระดับพื้นฐานของ PAdES) อยู่นอกชุดหลักฐานที่อ้างอิง ดังนั้น NextPDF Pro จึง ไม่ อ้างการรับรอง ความสอดคล้อง หรือการปฏิบัติตาม ETSI EN 319 142-1 อิสระ และไม่อ้างความถูกต้องทางกฎหมายของเอกสาร หน้านี้ระบุโครงสร้างที่ผลิตขึ้น มาตรฐานที่การรองรับ B-T นำมาใช้ และขอบเขต B-LT/B-LTA ของ Enterprise ไม่ใช่ระดับความสอดคล้องที่ได้รับการรับรอง

ดูเพิ่มเติม

• การลงนามของ Core — ตัวลงนาม CMS, การประทับเวลา RFC 3161, การตรวจสอบเส้นทาง RFC 5280, OCSP และ CRL
• การจับคู่พื้นฐาน PAdES — B-B, B-T, B-LT, B-LTA ในแต่ละรุ่น
• Security (ภาพรวมความสามารถ) — หน้าความสามารถด้านความปลอดภัยสาธารณะของ Pro
• CMS · PAdES · RFC 3161 timestamp · KMS · DSS — คำศัพท์ในอภิธานศัพท์