การตรวจสอบลายเซ็น: ฝั่งตรวจสอบเชิงเข้ารหัสลับของ AdES / PAdES

ภาพรวมโดยย่อ

NextPDF Enterprise ตรวจสอบลายเซ็นดิจิทัลในเชิงเข้ารหัสลับ ฝั่งตรวจสอบจะอ่าน Cryptographic Message Syntax (CMS) SignedData หรือโทเค็นการประทับเวลาตาม Request for Comments (RFC) 3161 จาก PDF คำนวณไดเจสต์ใหม่ ตรวจลายเซ็น ผูกลายเซ็นแต่ละรายการกับใบรับรองที่ใช้ลงนาม และตรวจสอบความถูกต้องของห่วงโซ่ใบรับรองรวมถึงการประมวลผลนโยบายใบรับรอง โดยเทียบกับคลังจุดยึดความเชื่อถือที่ผู้เรียกใช้จัดหา หน้านี้อธิบายพฤติกรรม โดยระบุว่าสิ่งใดได้รับการตรวจสอบ สิ่งใดถูกปฏิเสธแบบ fail-closed อัลกอริทึมใดได้รับการรองรับ และขอบเขตความเชื่อถืออยู่ที่ใด

ความสามารถนี้แยกจาก Validation ซึ่งรันการตรวจสอบนโยบายเชิงโครงสร้างแบบอ่านอย่างเดียว และจงใจไม่ดำเนินการเข้ารหัสลับใดๆ อีกทั้งยังเป็นคู่ฝั่งตรวจสอบของ ตัวผลิตลายเซ็น ซึ่งเขียนโครงสร้าง PDF Advanced Electronic Signatures (PAdES) B-LT / B-LTA

การติดตั้ง

composer require nextpdf/enterprise:^3

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

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

การตรวจสอบเชิงเข้ารหัสลับของ CMS / โทเค็นการประทับเวลา สแตก DER ที่เข้มงวด กำหนดความยาวแน่นอน และครบถ้วนในตัว จะแยกวิเคราะห์ CMS SignedData และโทเค็นการประทับเวลาตาม RFC 3161 โทเค็นจะได้รับการยอมรับก็ต่อเมื่อมี SignerInfo เพียงหนึ่งรายการพอดี แอตทริบิวต์ที่ลงนามของโทเค็นแยกวิเคราะห์ได้อย่างเข้มงวด ใบรับรองของผู้ลงนามแก้ไขอ้างอิงได้ แอตทริบิวต์ message-digest ตรงกับไดเจสต์ที่คำนวณใหม่ การผูกใบรับรองที่ใช้ลงนามภาคบังคับ (ESS signing-certificate-v2) เป็นจริง และลายเซ็น SignerInfo ตรวจผ่านบนแอตทริบิวต์ที่ลงนามซึ่งติดแท็กใหม่ กฎการจับคู่ไดเจสต์เป็นไปตามแบบจำลองการตรวจสอบของ RFC 5652 §5.6 / §5.4: ผู้รับคำนวณไดเจสต์ข้อความของเนื้อหาใหม่ และลายเซ็นจะถูกต้องก็ต่อเมื่อค่านั้นเท่ากับแอตทริบิวต์ที่ลงนาม messageDigest ตัวตรวจสอบจะไม่เชื่อถือไดเจสต์ที่ผู้ผลิตจัดหามาเลย

การตรวจสอบความถูกต้องของใบรับรอง TSA ณ genTime ค่า genTime ของการประทับเวลาคือชั่วขณะ UTC ที่สร้างโทเค็น (RFC 3161 §2.4.2) ใบรับรองที่ใช้ลงนามของ TSA จะถูกตรวจสอบ ณ ชั่วขณะนั้น ไม่ใช่ ณ “ปัจจุบัน”: extended key usage ของใบรับรองต้องเป็น id-kp-timeStamping เดี่ยวที่เป็น critical (RFC 3161 §2.3) และช่วงความถูกต้อง ห่วงโซ่ ที่มาของจุดยึดความเชื่อถือ และการเพิกถอนของใบรับรอง ล้วนถูกประเมินเทียบกับ genTime ห่วงโซ่ที่มีรูปแบบโครงสร้างถูกต้องแต่ไม่เชื่อมถึงจุดยึดความเชื่อถือที่กำหนดค่าไว้ จะไม่มีทางรองรับผลลัพธ์เชิงบวกได้

ลายเซ็นเอกสารพื้นฐานแบบ PAdES ที่แยกออกมา (detached) ตัวสกัดเฉพาะจะดำเนินการตรวจสอบพื้นฐานแบบ Advanced Electronic Signatures (AdES) / PAdES จริงสำหรับลายเซ็นเอกสารแบบแยกออกมา: ไดเจสต์ข้อความถูกคำนวณใหม่บนช่วงไบต์ที่ลงนามแล้วนำมาเปรียบเทียบ ลายเซ็นได้รับการตรวจสอบ และการผูกใบรับรองที่ใช้ลงนามเป็นข้อบังคับ ความสามารถนี้แทนที่กลไกสำรองเดิมที่ตรวจเฉพาะโครงสร้าง ตัวตรวจสอบการประทับเวลาและตัวสกัดลายเซ็นเอกสารใช้ตัวตรวจสอบ ESS issuer-and-serial ตัวเดียวกัน ดังนั้นการแยกวิเคราะห์การผูกใบรับรองจึงไม่คลาดเคลื่อนระหว่างกัน

ห่วงโซ่ความครอบคลุม DocTimeStamp สำหรับการเก็บถาวร validateArchivalTimestampChain() ตรวจสอบความถูกต้องของห่วงโซ่โทเค็น DocTimeStamp ที่เชื่อถือได้บนช่วงไบต์ของ PDF ในฐานะหลักฐานการเก็บถาวรแบบ B-LTA imprint ของแต่ละโทเค็นผูกกับไบต์ ByteRange จริงที่โทเค็นนั้นครอบคลุม ห่วงโซ่เป็นไปตามลำดับ ETSI อย่างเข้มงวด ห่วงโซ่ TSA ของทุกโทเค็นยึดกับจุดยึดความเชื่อถือ และห่วงโซ่ต้องครอบคลุมไฟล์จนถึงเครื่องหมายสิ้นสุดไฟล์ จะถึงผลลัพธ์ผ่านโดยสมบูรณ์เฉพาะกรณีที่ห่วงโซ่ครบถ้วน ยึดกับจุดยึดความเชื่อถือ และครอบคลุมจนถึง EOF เท่านั้น

การประมวลผลนโยบายใบรับรอง (RFC 5280 §6.1.4) การตรวจสอบความถูกต้องของเส้นทางใช้การประมวลผลนโยบายใบรับรองเต็มรูปแบบ: ต้นไม้นโยบายที่จัดโครงสร้างเป็นโหนด การแมปนโยบายพร้อมกลไกสำรอง anyPolicy และการพับ (folding) policyConstraints / inhibitAnyPolicy โดยรองรับด้วยตัวอ่าน DER สำหรับส่วนขยายนโยบายแบบ fail-closed ตัวแปรสถานะการประมวลผลเส้นทาง explicit_policy และ inhibit_anyPolicy (RFC 5280 §6.1.2) เป็นตัวกำหนดว่าจำเป็นต้องมีต้นไม้นโยบายที่ถูกต้องและไม่ว่างหรือไม่ ขั้นตอนสรุปจะหาส่วนตัดของต้นไม้นโยบายที่ถูกต้องกับ user-initial-policy-set (RFC 5280 §6.1.4) เมื่อไม่มีนโยบายที่จำเป็นและยอมรับ anyPolicy การประมวลผลจะไม่มีข้อจำกัด ซึ่งเป็นค่าเริ่มต้นและไม่เปลี่ยนแปลงจากพฤติกรรมเดิม

อัลกอริทึมที่รองรับ

ฝั่งตรวจสอบยอมรับชุดอัลกอริทึมด้านล่างและ fail closed กับสิ่งใดก็ตามที่อยู่นอกชุดนี้: อัลกอริทึมที่ไม่รองรับถือเป็นการตรวจสอบที่ถูกปฏิเสธ ไม่มีทางผ่านแบบเงียบๆ

ตระกูล	ที่รองรับ	หมายเหตุ
RSA (PKCS#1 v1.5)	`rsaEncryption` กับ SHA-2 และ `sha*WithRSAEncryption` OID	ยอมรับ
ECDSA	เส้นโค้ง P-256, P-384, P-521	ยอมรับ
RSASSA-PSS	—	ไม่รองรับ → fail-closed
EdDSA	—	ไม่รองรับ → fail-closed
ไดเจสต์ SHA-3	—	ไม่รองรับ → fail-closed
SHA-1	—	อ่อนแอ: ลายเซ็นพื้นฐานที่ตรวจผ่านภายใต้ SHA-1 จะถูกลดระดับเป็นความล้มเหลวด้านข้อจำกัดการเข้ารหัสลับ ไม่ใช่การผ่าน

พื้นผิว API

ผู้ใช้เรียกใช้งานฝั่งตรวจสอบผ่านเอนจินสาธารณะและสัญญา Core / Pki ส่วนคลาสกลยุทธ์ที่เป็นรูปธรรมถือเป็นส่วนภายใน

ชนิด	ประเภท	บทบาท
`AdESValidationEngine`	class	จุดเริ่มต้นของฝั่งตรวจสอบ: การตรวจสอบความถูกต้องของลายเซ็นและห่วงโซ่การเก็บถาวร
`AdESValidationEngine::validateArchivalTimestampChain()`	method	ตรวจสอบความถูกต้องของห่วงโซ่ความครอบคลุม DocTimeStamp ที่เชื่อถือได้บนช่วงไบต์ของ PDF
`ValidationReport`	ผลลัพธ์	ผลลัพธ์ที่มีโครงสร้าง: สถานะโดยรวมพร้อมข้อค้นพบรายการตรวจสอบแต่ละรายการ
`PathValidatorInterface`	interface (`NextPDF\…\Pki`)	SPI การตรวจสอบความถูกต้องของเส้นทางการรับรอง (certification-path) ที่เอนจินพึ่งพา
`PathValidationOptions`	value object	ตัวควบคุมการประมวลผลนโยบาย: `requireExplicitPolicy`, `inhibitAnyPolicy`, `inhibitPolicyMapping`, `maxPolicyFanout`
`TrustAnchorStoreInterface`	interface	ชุดจุดยึดที่เชื่อถือได้ซึ่งผู้เรียกใช้จัดหา และห่วงโซ่จะถูกประเมินเทียบกับชุดนี้

เมท็อดห่วงโซ่การเก็บถาวรมีลายเซ็นเมท็อดดังนี้:

public function validateArchivalTimestampChain(
    string $pdfBytes,
    array $dssData = [],
    ?TrustAnchorStoreInterface $anchors = null,
): ValidationReport;

จะถึงผลลัพธ์ผ่านโดยสมบูรณ์เฉพาะเมื่อห่วงโซ่ DocTimeStamp ได้รับการตรวจสอบครบถ้วน ยึดกับจุดยึดความเชื่อถือ และครอบคลุมไฟล์จนถึงเครื่องหมาย EOF เท่านั้น

CertificateChainValidator::validate() รับชุดนโยบายเริ่มต้น (initial-policy set) (คือ user-initial-policy-set ตาม RFC 5280) ค่าเริ่มต้นคือ anyPolicy ซึ่งไม่มีข้อจำกัด ดังนั้นห่วงโซ่ทั่วไปจึงไม่ได้รับผลกระทบ ให้ส่งชุดที่ระบุชัดเจนเข้าไป หรือกำหนด requireExplicitPolicy เพื่อบังคับให้ต้องมีต้นไม้นโยบายที่ถูกต้องและไม่ว่าง

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

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;

$report = $engine->validateArchivalTimestampChain($pdfBytes, [], $trustAnchors);

if ($report->isTotalPassed()) {
    // A complete, trust-anchored, EOF-covering DocTimeStamp chain.
}

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

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;
use Psr\Log\LoggerInterface;

final readonly class ArchivalEvidenceCheck
{
    public function __construct(
        private AdESValidationEngine $engine,
        private LoggerInterface $logger,
    ) {}

    public function check(string $pdfBytes, TrustAnchorStoreInterface $anchors): bool
    {
        $report = $this->engine->validateArchivalTimestampChain($pdfBytes, [], $anchors);

        foreach ($report->findings as $finding) {
            $this->logger->info('archival.finding', [
                'check'  => $finding->checkId,
                'status' => $finding->status->value,
            ]);
        }

        // A positive result proves byte-range coverage by a trusted timestamp
        // chain — it is one input to your decision, not a legal conclusion.
        return $report->isTotalPassed();
    }
}

การเปลี่ยนแปลงพฤติกรรม & หมายเหตุการอัปเกรด

ฝั่งตรวจสอบเปลี่ยนจากการยอมรับเชิงโครงสร้าง / เชิงเวลา ไปสู่การตรวจสอบเชิงเข้ารหัสลับเต็มรูปแบบ หากผู้ใช้พึ่งพาพฤติกรรมเดิมที่ผ่อนปรนกว่า โปรดทบทวนการเปลี่ยนแปลงเหล่านี้

Fail-closed กับการประทับเวลาที่รู้จักแต่ตรวจสอบไม่ได้ DocTimeStamp หรือโทเค็นการเก็บถาวรที่ก่อนหน้านี้ผ่านจากพื้นฐานเชิงโครงสร้างและเชิงเวลา บัดนี้ต้องผ่านการตรวจสอบเชิงเข้ารหัสลับเต็มรูปแบบ: ลายเซ็น message-digest และการผูกใบรับรองที่ใช้ลงนาม โทเค็นที่ตรวจสอบไม่ผ่านจะไม่ให้หลักฐานการมีอยู่ (proof-of-existence) เชิงบวกอีกต่อไป แต่จะแมปไปเป็นผลลัพธ์ที่ไม่อาจชี้ขาดหรือล้มเหลว
ลายเซ็นพื้นฐาน SHA-1 ถูกลดระดับ ไม่ใช่ผ่าน ลายเซ็นเอกสารพื้นฐานที่ตรวจผ่านแต่ใช้ SHA-1 จะถูกรายงานเป็นความล้มเหลวด้านข้อจำกัดการเข้ารหัสลับ ไม่ใช่การผ่านโดยสมบูรณ์
บังคับใช้การประมวลผลนโยบายใบรับรองตาม RFC 5280 §6.1.4 ห่วงโซ่ที่ explicit_policy ลดถึงศูนย์โดยมีต้นไม้นโยบายที่ถูกต้องว่างเปล่า บัดนี้จะล้มเหลว รวมถึงกรณีที่ policyConstraints requireExplicitPolicy ภายในห่วงโซ่เป็นตัวขับเคลื่อน ห่วงโซ่ค่าเริ่มต้นที่ไม่มีข้อจำกัด (ไม่มีนโยบายที่จำเป็น ยอมรับ anyPolicy) ไม่ได้รับผลกระทบ
การเปลี่ยนแปลงลายเซ็นคอนสตรักเตอร์ (BC break) AdESValidationEngine::__construct() บัดนี้กำหนดชนิดของพารามิเตอร์ $chainValidator เป็น SPI Pki\PathValidatorInterface โดยตั้งค่าเริ่มต้นแบบ lazy เป็น Pki\CertificateChainValidator::withDefaults() ก่อนหน้านี้เป็น Ltv\CertificateChainValidator ที่เป็นรูปธรรม ผู้เรียกใช้ที่เคยฉีด LTV validator ที่เป็นรูปธรรม ต้องฉีดการนำ Pki SPI ไปใช้แทน ตัว Pki validator ห่อหุ้มเอนจินเส้นทางเชิงโครงสร้างตัวเดียวกัน และเพิ่มข้อจำกัดด้านชื่อ (name constraints) กับการประมวลผลนโยบาย โดยไม่มีผลใดๆ (no-op) สำหรับอินพุตค่าเริ่มต้นที่สอดคล้องตามข้อกำหนด

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

อัลกอริทึมที่ไม่รองรับ ≠ ไม่อาจสรุป RSASSA-PSS, EdDSA และ SHA-3 ถูกปฏิเสธแบบ fail-closed ไม่ใช่เลื่อนพิจารณา หากผู้ลงนามของคุณใช้อัลกอริทึมเหล่านั้น ฝั่งตรวจสอบนี้จะไม่คืนผลลัพธ์เชิงบวก
ความเชื่อถือสัมพัทธ์กับจุดยึด การตรวจสอบจะสัมพัทธ์กับคลังจุดยึดความเชื่อถือที่ผู้ใช้จัดหาเสมอ ชุดจุดยึดที่ว่างเปล่าหรือผิด จะให้ผลลัพธ์ไม่เชื่อถือ (not-trusted) โดยไม่คำนึงถึงความถูกต้องเชิงเข้ารหัสลับ
genTime ไม่ใช่ปัจจุบัน ใบรับรอง TSA จะถูกตัดสิน ณ genTime ของโทเค็น ใบรับรอง TSA ที่หมดอายุไปแล้วยังสามารถรองรับโทเค็นที่สร้างขึ้นขณะที่ใบรับรองยังถูกต้องได้ ส่วนใบรับรองที่ยังไม่ถูกต้อง ณ genTime ทำไม่ได้
ความครอบคลุมถึง EOF ห่วงโซ่การเก็บถาวรต้องครอบคลุมเอกสารจนถึงเครื่องหมาย EOF การประทับเวลาที่ครอบคลุมเพียงส่วนต้นของไฟล์ ไม่ได้สร้างความครอบคลุมทั้งเอกสาร
ไม่พิสูจน์ว่าถูกเพิกถอน ไม่เท่ากับ Good คำตัดสิน Valid ต้องมีสถานะที่ไม่ถูกเพิกถอนอย่างชี้ขาด หากทั้ง OCSP และ CRL คืนค่า Unknown หรือ Unavailable แม้แต่ลายเซ็นที่ถูกต้องในเชิงเข้ารหัสลับ ห่วงโซ่ถูกต้อง และยึดกับจุดยึดความเชื่อถือ ก็จะแก้ไขเป็น Indeterminate ให้จัดหาวัสดุ Good ของ OCSP/CRL ที่ฝังอยู่สำหรับใบรับรองของผู้ลงนาม เพื่อให้ถึง Valid

ประสิทธิภาพ

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

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

Fail-closed เป็นค่าเริ่มต้น ทุกขั้นตอนการยอมรับจะปฏิเสธวัสดุที่ไม่สามารถตรวจสอบเชิงบวกได้ ความสามารถนี้ป้องกันไม่ให้เอกสารประกาศความถูกต้องที่เอนจินไม่เคยยืนยัน
การต่อท้ายหลังการประทับเวลาถูกขัดขวางด้วยความครอบคลุมถึง EOF เนื่องจาก imprint ของการประทับเวลาเก็บถาวรแต่ละครั้งผูกกับไบต์ ByteRange จริง และห่วงโซ่ต้องเชื่อมถึง EOF เนื้อหาที่ต่อท้ายหลังการประทับเวลาจึงไม่ถูกครอบคลุมโดยการประทับเวลานั้น และไม่ได้รับน้ำหนักเชิงพยานหลักฐานจากการประทับเวลานั้น
ปฏิบัติต่ออินพุตเสมือนเป็นภัย ไบต์ PDF, CMS ที่ฝังอยู่ และโทเค็นการประทับเวลาจากแหล่งที่ไม่เชื่อถือ จะถูกแยกวิเคราะห์โดยตัวอ่าน DER แบบความยาวกำหนดแน่นอนที่เข้มงวด ซึ่งปฏิเสธการเข้ารหัสที่ผิดรูปแบบหรือความยาวไม่กำหนดแน่นอน

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

การตรวจสอบดำเนินในกระบวนการและในเครื่อง โดยไม่มี I/O ผ่านเครือข่าย ใบรับรองและลายเซ็นมีข้อมูลระบุตัวตนของ subject อยู่ โปรดใช้การควบคุมการเก็บรักษาและการลดข้อมูลให้น้อยที่สุดของผู้ใช้กับรายงานและข้อมูลใบรับรองใดๆ ที่สกัดออกมา

การวัดและส่งข้อมูลที่ปลอดภัย & การล้างข้อมูลในล็อก

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

ขอบเขตของขอบข่าย

ระบุขอบเขตเหล่านี้ในผลลัพธ์ที่ผู้ใช้เห็น เพื่อไม่ให้ตีความผลลัพธ์เชิงบวกเกินจริง

validateArchivalTimestampChain() พิสูจน์ความครอบคลุมช่วงไบต์ ไม่ใช่ความเข้าถึงได้ของ xref เมท็อดนี้ยืนยันว่าห่วงโซ่การประทับเวลาที่เชื่อถือได้ครอบคลุมช่วงไบต์ของเอกสารจนถึง EOF ในเชิงเข้ารหัสลับ เมท็อดนี้ไม่ดำเนินการวิเคราะห์ความเข้าถึงได้ของออบเจกต์ระดับ xref หรือ startxref ซึ่งอยู่นอกขอบข่ายโดยการออกแบบ กฎความครอบคลุมถึง EOF ร่วมกับการยึดจุดยึดความเชื่อถือ จะขัดขวางการโจมตีแบบต่อท้ายหลังการประทับเวลา ไม่ใช่การวิเคราะห์กราฟออบเจกต์
อยู่นอกขอบข่ายโดยการออกแบบ Evidence Records (RFC 4998 / RFC 6283) การตรวจสอบโทเค็นการประทับเวลา RSASSA-PSS, EdDSA หรือ SHA-3 การผสานรวม trusted-list (TSL) และ qualified-TSA และการดึงข้อมูลการเพิกถอนของ TSA แบบออนไลน์ ไม่ได้จัดให้โดยฝั่งตรวจสอบนี้ การเพิกถอนถูกประเมินจากวัสดุที่ตัวตรวจสอบมีอยู่แล้ว

ความสอดคล้องตามข้อกำหนด

พฤติกรรม	อ้างอิง	สถานะ
ค่าลายเซ็น / โทเค็นการประทับเวลาเก็บไว้แบบเข้ารหัส DER ใน `/Contents`	ISO 32000-2 §12.8.1	แยกวิเคราะห์และตรวจสอบแล้ว
พจนานุกรมการประทับเวลาเอกสาร	ISO 32000-2 §12.8.5	อ่านสำหรับห่วงโซ่การเก็บถาวร
ผู้รับคำนวณไดเจสต์ของเนื้อหาใหม่ ซึ่งต้องเท่ากับแอตทริบิวต์ messageDigest	RFC 5652 §5.6 / §5.4	บังคับใช้
ใบรับรอง TSA มี EKU `id-kp-timeStamping` เดี่ยวที่เป็น critical	RFC 3161 §2.3	ตรวจสอบ ณ genTime
genTime คือชั่วขณะ UTC ที่สร้าง	RFC 3161 §2.4.2	ใช้เป็นชั่วขณะของการตรวจสอบ
ตัวแปรสถานะการประมวลผลนโยบาย (`explicit_policy`, `inhibit_anyPolicy`)	RFC 5280 §6.1.2	ประมวลผลแล้ว
ขั้นตอนสรุปหาส่วนตัดของต้นไม้นโยบายที่ถูกต้องกับ user-initial-policy-set	RFC 5280 §6.1.4	บังคับใช้
รายการ DSS และการประทับเวลาเอกสารสำหรับลายเซ็นระยะยาว	ETSI EN 319 142-2 §5.5	ตรวจสอบแล้วในฐานะหลักฐานการเก็บถาวร

ทุกข้อกำหนดเป็นการถอดความของ NextPDF ไม่ได้ทำซ้ำข้อความเชิงบรรทัดฐาน โปรดศึกษามาตรฐานที่เผยแพร่เพื่อถ้อยคำที่เป็นทางการ NextPDF ไม่อ้างการรับรอง AdES / PAdES ใดๆ ฝั่งตรวจสอบนำการตรวจสอบเชิงเข้ารหัสลับที่อธิบายโดยข้อกำหนดที่อ้างถึงไปใช้ แต่ไม่ใช่บริการตรวจสอบที่ได้รับการรับรอง และไม่สร้างคำรับรองจากบุคคลที่สาม

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

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

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

สินทรัพย์	ฝ่ายตรงข้าม	ความเสี่ยง	มาตรการบรรเทา
โทเค็นการประทับเวลา	โทเค็นที่ถูกปลอมแปลงหรือดัดแปลง	หลักฐานการมีอยู่ที่เป็นเท็จ	การตรวจสอบเชิงเข้ารหัสลับเต็มรูปแบบ fail-closed กับสิ่งใดก็ตามที่ตรวจสอบไม่ได้
ใบรับรอง TSA	ผู้ออกที่ไม่เชื่อถือ	ความเชื่อถือที่ดูเสมือนจริงซึ่งตัวตรวจสอบไม่ควรยืนยัน	ห่วงโซ่ตรวจสอบความถูกต้องจนถึงจุดยึดที่ผู้เรียกใช้จัดหา ณ genTime ห่วงโซ่ที่ไม่เชื่อถือไม่มีทางผ่าน
ไบต์ของเอกสาร	การต่อท้ายหลังการประทับเวลา	เนื้อหาได้รับน้ำหนักของการประทับเวลาโดยไม่มีความครอบคลุม	imprint ผูกกับไบต์ ByteRange จริง + กฎความครอบคลุมถึง EOF
อัลกอริทึมที่อ่อนแอ	ลดระดับลงเป็น SHA-1 / สคีมที่ไม่รองรับ	ลายเซ็นที่อ่อนแอถูกอ่านว่าถูกต้อง	SHA-1 ถูกลดระดับ RSASSA-PSS / EdDSA / SHA-3 fail-closed

การกั้นรุ่น (Edition gate)

ฝั่งตรวจสอบนี้เป็นความสามารถระดับ Enterprise และส่งมอบในแพ็กเกจ nextpdf/enterprise NextPDF Core ตรวจจับการมีอยู่ของลายเซ็นและผลิตลายเซ็น B-B / B-T แต่ไม่ได้จัดให้มีฝั่งตรวจสอบเชิงเข้ารหัสลับนี้ รับใบอนุญาต

แฟล็กฟีเจอร์ใบอนุญาต

ฝั่งตรวจสอบถูกกั้นโดยรุ่น Enterprise (license_feature_flag: enterprise) และแก้ไขอ้างอิงผ่านสัญญา Core และ Pki application programming interface (API) สาธารณะไม่เปลี่ยนแปลงเมื่ออัปเกรดรุ่น

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

CMS หรือโทเค็นการประทับเวลาจะได้รับการยอมรับก็ต่อเมื่อมี SignerInfo เพียงหนึ่งรายการพอดี แอตทริบิวต์ที่ลงนามแยกวิเคราะห์อย่างเข้มงวด ใบรับรองของผู้ลงนามแก้ไขอ้างอิงได้ message-digest ตรงกัน การผูกใบรับรองที่ใช้ลงนามภาคบังคับ และลายเซ็น SignerInfo ที่ตรวจผ่าน
ใบรับรอง TSA ถูกตรวจสอบความถูกต้อง ณ genTime ของโทเค็น: EKU id-kp-timeStamping เดี่ยวที่เป็น critical, ช่วงความถูกต้อง, ห่วงโซ่ที่ยึดกับจุดยึดความเชื่อถือ และการเพิกถอน
คำตัดสิน Valid ยังต้องมีสถานะที่ไม่ถูกเพิกถอนอย่างชี้ขาด เพิ่มเติม: อย่างน้อยหนึ่ง Good ที่เชื่อถือได้ (การตอบสนอง OCSP ที่ตรวจสอบแล้วว่า good หรือ CRL ที่ใหม่ซึ่งวางซีเรียลไว้นอกรายการที่ยังไม่หมดอายุ) สถานะที่เพียงไม่พิสูจน์ว่าถูกเพิกถอน โดยที่ OCSP และ CRL ต่างเป็น Unknown หรือ Unavailable จะแก้ไขเป็น Indeterminate ไม่มีทางเป็น Valid (ETSI EN 319 102-1: สถานะการเพิกถอนไม่พร้อมใช้งาน → INDETERMINATE) เนื่องจากเส้นทางสำรอง CRL รับรองเพียงความใหม่ของรายการ ไม่ใช่การเพิกถอนรายซีเรียล ห่วงโซ่ที่ใช้ CRL อย่างเดียวโดยไม่มี OCSP ที่เป็น Good จึงมักเป็น Indeterminate
validateArchivalTimestampChain() จะถึงผลลัพธ์ผ่านโดยสมบูรณ์เฉพาะห่วงโซ่ DocTimeStamp ที่ครบถ้วน ยึดกับจุดยึดความเชื่อถือ และครอบคลุมถึง EOF เท่านั้น มันพิสูจน์ความครอบคลุมช่วงไบต์ ไม่ใช่ความเข้าถึงได้ของ xref
การประมวลผลนโยบายใบรับรองเป็นไปตาม RFC 5280 §6.1.4 ห่วงโซ่ค่าเริ่มต้นที่ไม่มีข้อจำกัดไม่ได้รับผลกระทบ
อัลกอริทึมที่รองรับคือ RSA (PKCS#1 v1.5 กับ SHA-2) และ ECDSA (P-256/384/521) RSASSA-PSS, EdDSA และ SHA-3 fail closed ส่วน SHA-1 ถูกลดระดับ

สถานะการสแกน NDA

หน้าสาธารณะนี้อธิบายเฉพาะพฤติกรรมฝั่งตรวจสอบที่สังเกตได้จากภายนอกเท่านั้น โดยระบุชื่อเอนจินสาธารณะ สัญญา Pki / จุดยึดความเชื่อถือ และเมท็อด validateArchivalTimestampChain() ผ่านพื้นผิวที่รองรับ ส่วนภายในที่เป็นรูปธรรมของ DER, CMS, ตัวประมวลผลนโยบาย และตัวตรวจสอบเส้นทาง อยู่ในเอกสารอ้างอิงเชิงลึกที่ถูกกั้นภายใต้ข้อตกลงไม่เปิดเผยข้อมูล (NDA)

กลไกสำรองของ Core

NextPDF Core ตรวจจับการมีอยู่ของลายเซ็นและผลิตลายเซ็น B-B / B-T แต่ไม่ได้ตรวจสอบ CMS หรือโทเค็นการประทับเวลาในเชิงเข้ารหัสลับ ไม่ตรวจสอบความถูกต้องของห่วงโซ่การเก็บถาวร และไม่รันการประมวลผลนโยบายตาม RFC 5280 §6.1.4 การปรับใช้ที่มีเฉพาะ Core ไม่มีฝั่งตรวจสอบที่เทียบเท่า ดู ความปลอดภัย / การลงนาม (Core)

กลไกสำรองของ Pro

NextPDF Pro เพิ่มกลยุทธ์การลงนามและการจัดการ e-invoice แต่ไม่ได้จัดให้มีฝั่งตรวจสอบเชิงเข้ารหัสลับนี้ การตรวจสอบความถูกต้องของห่วงโซ่การเก็บถาวรและการประมวลผลนโยบายใบรับรองส่งมอบใน nextpdf/enterprise เท่านั้น

หมายเหตุขอบเขตของ Enterprise

ฝั่งตรวจสอบถูกอธิบายในระดับพฤติกรรม สแตก DER ที่เข้มงวด ตัวแยกวิเคราะห์ CMS ตัวประมวลผลนโยบาย และส่วนภายในของตัวตรวจสอบเส้นทาง อยู่นอกขอบข่ายของพื้นผิวสาธารณะและไม่ถูกทำซ้ำที่นี่

ขอบเขตการปรับใช้

การตรวจสอบพึ่งพาคลังจุดยึดความเชื่อถือและวัสดุการเพิกถอนใดๆ ที่ผู้เรียกใช้จัดหาหรือที่ฝังอยู่ในเอกสาร NextPDF Enterprise ประเมินวัสดุนั้น แต่ไม่ได้ดำเนินการ trust list, TSA หรือบริการการเพิกถอน ผู้ดำเนินการเป็นผู้รับผิดชอบการเลือกจุดยึดและความใหม่ของวัสดุการเพิกถอนที่ฝังอยู่

ขอบเขตการปฏิบัติตามกฎหมาย

หน้านี้ถูกทำเครื่องหมายว่า export_control_class: legal-review-required เนื่องจากเกี่ยวข้องกับการตรวจสอบเชิงเข้ารหัสลับ ต้องได้รับการอนุมัติทางกฎหมายก่อนที่จะตั้งแฟล็ก publish ผลลัพธ์การตรวจสอบเชิงบวกเป็นข้อความเชิงเข้ารหัสลับเกี่ยวกับลายเซ็นและการประทับเวลาของเอกสาร ไม่ใช่ความเห็นทางกฎหมาย ไม่ใช่การวินิจฉัยคุณสมบัติตาม eIDAS และไม่ใช่การรับรอง NextPDF ไม่อ้างการรับรอง AdES / PAdES ใดๆ โปรดปรึกษาที่ปรึกษาด้านการปฏิบัติตามกฎเกณฑ์และด้านกฎหมายของผู้ใช้สำหรับภาระผูกพันตามกฎระเบียบของผู้ใช้

ดูเพิ่มเติม

ลายเซ็น: ตัวผลิต PAdES B-LT / B-LTA — ฝั่งผู้ผลิต
Validation — การตรวจสอบนโยบายเชิงโครงสร้างในกระบวนการ (ไม่มีการเข้ารหัสลับ)
คลังเก็บถาวร: DSS, VRI, สุขภาพ LTV — การเก็บถาวรระยะยาวและสุขภาพ LTV
ความปลอดภัย / การลงนาม (Core) — CMS, RFC 3161, การตรวจสอบเส้นทางตาม RFC 5280, OCSP/CRL
การแมปพื้นฐาน PAdES — B-B, B-T, B-LT, B-LTA ข้ามรุ่นต่าง ๆ
PAdES · DSS · LTV — คำศัพท์ในอภิธานศัพท์