A cross-ca electronic file mutual recognition system, method, device and medium thereof

Abstract

The application relates to the technical field of electronic signature, in particular to a cross-CA electronic file mutual recognition system, which comprises a manufacturer management module and a bridging module, the manufacturer management module is used for managing basic information of multiple CA manufacturers and establishing a trust list model; the bridging module adopts a bridging adaptation mode, different CA manufacturers' digital certificates and signature algorithms are adapted to downstream, and a unified docking interface is provided for a business system in upstream. The application can solve the technical problem that electronic files cannot be verified across agencies due to the non-uniformity of CA agency certificate formats, signature algorithms and file packaging standards in the prior art, a business system can complete multi-CA electronic file signature verification by only once docking a unified API interface, without needing to develop and adapt to different manufacturers, and the application is compatible with multiple signature file formats such as PDF and OFD, supports a CRL revoked certificate verification mechanism, and is suitable for digital scenarios such as e-government, electronic bidding and electronic contract.

Description

Technical Field

[0001] This invention belongs to the field of electronic signature technology, specifically a cross-CA electronic document mutual recognition system, method, device and medium. Background Technology

[0002] With the continuous advancement of digital government construction, electronic documents have become a core business carrier for e-government services and enterprise digital transformation. Electronic authentication service providers, as authoritative third-party trusted institutions, effectively safeguard the authenticity and trustworthiness of public and private keys of business entities by issuing digital certificates and providing certificate validity verification services. They play a crucial role in maintaining the security of electronic transactions and ensuring the legal validity of electronic documents.

[0003] However, the current market contains numerous independently operated third-party electronic authentication service providers, including Shanghai CA, Beijing CA, CFCA, Guangdong CA, and many others. These CAs employ different digital certificate storage formats, different signature cryptographic algorithms, and different file encapsulation standards, forming independent technical systems with a lack of unified mutual recognition mechanisms. This lack of standardized technology directly leads to a prominent industry problem: electronic documents signed by one CA cannot be parsed and verified in the business systems of other CAs. A long-standing technical barrier exists within the industry, preventing cross-CA electronic document signing, recognition, and verification.

[0004] This technical deficiency has caused significant problems in practical applications: when electronic documents are transferred between regions, departments, levels, or business systems, the document verification process becomes extremely lengthy and cumbersome because the CA institutions relied upon by the signatory and the verifier may be different. Business systems need to develop adaptation modules for different CA institutions or rely on specific verification tools. This not only greatly increases development and maintenance costs, but also seriously hinders the efficient transfer and interoperability of electronic documents in government, e-commerce, and other business scenarios.

[0005] To address the aforementioned technical shortcomings, this invention provides a cross-CA electronic document mutual recognition system, aiming to achieve unified parsing and verification of documents signed by multiple CAs, reduce the development costs of multi-vendor adaptation for business systems, and improve the efficiency of cross-domain electronic document circulation. Summary of the Invention

[0006] A cross-CA electronic document mutual recognition system includes a vendor management module and a bridging module; The vendor management module is configured to manage the basic information of multiple CA vendors and establish a trust list model based on the basic information, wherein the basic information includes the certificate information and user information of each CA vendor. The bridging module is communicatively connected to the vendor management module and is configured to obtain electronic documents signed by different CA vendors provided by the user, parse and identify the data packets of the electronic documents, and match the corresponding CA vendor information from the vendor management module according to the parsing results to verify and mutually recognize the electronic documents. The bridging module adopts a bridging adaptation mode, which adapts to the digital certificates and signature algorithms of different CA vendors downstream, and provides a unified interface for business systems upstream.

[0007] Preferably, the bridging module includes a file parsing unit, a format recognition unit, and an adaptation matching unit; the file parsing unit is configured to disassemble the data packet of the electronic file provided by the user and extract the digital certificate information, signature algorithm identifier, and encapsulation format information therein; the format recognition unit is configured to identify the target CA vendor that signed the electronic file based on the extracted digital certificate information and signature algorithm identifier; the adaptation matching unit is configured to retrieve the corresponding digital certificate information from the trust list model of the vendor management module based on the identified target CA vendor and verify the digital signature of the electronic file.

[0008] Preferably, the file parsing unit supports parsing data packets of various electronic document formats, including signed data packets in PDF, OFD, XML, and JSON formats. The file parsing unit adopts corresponding parsing strategies for different electronic document formats to extract signature metadata in a unified format. The signature metadata includes certificate issuer information, certificate serial number, signature algorithm OID, and signature value. The file parsing unit reads signature field data for PDF format files, reads signature description files for OFD format files, and extracts signature node data for XML and JSON format files, and outputs a standardized signature metadata dataset.

[0009] Preferably, the format recognition unit extracts the CA (Certificate Authority) name from the digital certificate issuer field output by the file parsing unit, identifies the signature algorithm type from the signature algorithm identifier, automatically matches the CA vendor profiles in the trust list, accurately identifies the target CA vendor to which the document is signed, and generates a matching result containing the target CA vendor identifier.

[0010] Preferably, the matching unit retrieves the corresponding trusted root certificate from the trust list model of the vendor management module based on the identified target CA vendor identifier, performs digital signature verification operation in conjunction with the CRL revocation status verification result, outputs a mutual recognition conclusion on whether the file is legal and valid, and finally outputs a clear verification conclusion of mutual recognition pass or mutual recognition fail.

[0011] Preferably, the system further includes a CRL list management module, configured to configure the CRL list addresses of each CA vendor, periodically obtain the list of revoked certificates, and perform revocation status checks during certificate verification; the CRL list management module uniformly maintains the CRL revocation list addresses of each CA vendor, and is configured to automatically pull the latest revoked certificate list through a scheduled synchronization task; when the adaptation and matching unit performs signature verification, it synchronously calls the CRL list management module to perform certificate revocation status verification.

[0012] Preferably, the trust list model is a multi-CA mutual recognition and verification trust list model, configured to establish the relationship between each CA electronic signature service provider and the certificates provided by the CA institutions used by each CA electronic signature service provider; the core logic of the trust list model is to establish a one-to-one binding relationship between the electronic signature service provider and the underlying CA root certificate, retrieve the trusted certificate when verifying electronic documents across vendors, and store the CRL revocation list access address of each CA vendor and synchronize it to the CRL list management module.

[0013] The present invention also provides a method for cross-CA electronic document mutual recognition, applied to the cross-CA electronic document mutual recognition system described in any one of the above, characterized by comprising the following steps: The system manages the basic information of multiple CA vendors through a vendor management module and establishes a trust list model. It acquires electronic documents signed by different CA vendors provided by users, parses and identifies the data packets and formats of the electronic documents through a bridging module, and matches the corresponding CA vendor information from the vendor management module based on the parsing results to verify and mutually recognize the electronic documents. Through a unified interface provided to upstream business systems, the business systems can identify and verify electronic documents signed by multiple CA institutions through a single connection.

[0014] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, characterized in that the processor executes the computer program to implement the steps of the cross-CA electronic document mutual recognition method described above.

[0015] The present invention also provides a computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the steps of the cross-CA electronic document mutual recognition method described above.

[0016] The technical solution provided by this invention has the following advantages compared with the known prior art: This invention's cross-CA electronic document mutual recognition system and method relies on a bridging module to complete multi-format file parsing and automatic CA vendor identification. Combined with the vendor management module's trust list model, it constructs a global trusted trust chain, enabling unified parsing and mutual recognition of documents signed by different CA institutions. This solution focuses solely on the document verification process and does not involve electronic signature generation. It is lightweight and highly versatile, completely resolving the industry pain point of incompatibility between multiple CA certificates, algorithms, and encapsulation standards, which leads to inability to verify documents across CAs, thus breaking down barriers to cross-CA electronic document mutual recognition. Business systems only need to interface with a single standardized and unified API interface to be compatible with the electronic document verification needs of all CA vendors, eliminating the workload of developing separate adaptation modules for each vendor. In scenarios involving the addition or replacement of multiple CAs, only the vendor trust list within the system needs to be updated; the business system requires no secondary modifications, significantly reducing long-term maintenance complexity and substantially lowering business system development and maintenance costs. The system integrates standardized CA mutual recognition components, making deployment convenient and effectively supporting the high-speed flow of government and business documents across regions, departments, and levels, significantly improving the efficiency of cross-domain electronic document flow. The bridging module is natively compatible with mainstream signed electronic documents such as PDF and OFD. End users can complete cross-vendor document verification without installing multiple CA-specific clients and verification tools. The entire process is transparent and seamless for end users, thus optimizing the user experience. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the overall architecture of the cross-CA electronic document mutual recognition system according to an embodiment of the present invention.

[0018] Figure 2 This is a schematic diagram of the internal unit structure of the bridging module in an embodiment of the present invention.

[0019] Figure 3 This is a schematic diagram of the overall process of the cross-CA electronic document mutual recognition method according to an embodiment of the present invention.

[0020] Figure 4 This is a schematic diagram illustrating the detailed process of parsing electronic document data packets and verifying CA vendor matching in an embodiment of the present invention. Detailed Implementation

[0021] The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the invention, and should not be construed as limiting the invention.

[0022] like Figure 1As shown, the cross-CA electronic document mutual recognition system of this invention adopts a layered architecture design, consisting of a business system layer, a unified interface layer, a cross-CA electronic document mutual recognition system layer, and a CA vendor layer from top to bottom. The business system layer includes various business systems such as electronic bidding platforms, e-government platforms, and electronic contract review systems. Each business system in the business system layer communicates with the cross-CA electronic document mutual recognition system layer through the unified interface layer in a standardized manner. The cross-CA electronic document mutual recognition system layer includes a bridging module, a vendor management module, and a CRL list management module. These three modules work together to complete the parsing, identification, and verification of cross-CA electronic documents. The CA vendor layer includes digital certificates issued by various CA institutions such as Shanghai CA digital certificates, Beijing CA digital certificates, CFCA digital certificates, and Guangdong CA digital certificates.

[0023] In the actual operation of the cross-CA electronic document mutual recognition system of this invention, the electronic bidding platform in the business system layer needs to receive bid documents signed by different CA vendors, the government service platform needs to verify electronic certificates issued by different CA institutions, and the electronic contract review system needs to process digitally signed contracts issued by multiple CA vendors. Under traditional technical conditions, these business systems need to connect to the verification interface of each CA vendor separately, resulting in high development costs and maintenance difficulties. After adopting the technical solution of this invention, the business systems only need to connect once to the standardized API service provided by the unified interface layer to achieve unified parsing and verification of electronic documents signed by all CA vendors.

[0024] The vendor management module is one of the core components of this invention. Its main function is to uniformly manage the basic information of multiple CA vendors and establish a multi-CA mutual recognition and verification trust list model based on this basic information. The basic information of CA vendors managed by the vendor management module includes the digital certificate information and user information of each CA vendor. The digital certificate information includes root certificates and intermediate certificates issued by different CA institutions such as Shanghai CA, Beijing CA, CFCA, and Guangdong CA. The user information includes the registration information of enterprises and individuals served by each CA institution.

[0025] The vendor management module associates and maps basic information with certificate and user information provided by third-party CA institutions. Specifically, it establishes a real-time synchronization channel with the official data interfaces of various CA institutions, periodically obtaining information such as the Certificate Revocation List (CRL) addresses published by the official CA institutions, including those for Shanghai CA, Beijing CA, CFCA, and Guangdong CA. It then associates and binds the locally stored CA vendor basic profiles with the certificates and user information officially released by the third-party CA institutions, generating a complete and reliable trust relationship graph. This trust relationship graph records the one-to-one binding relationship between each electronic signature service provider and its underlying CA root certificate, providing a reliable trust chain for cross-vendor electronic document verification.

[0026] The core logic of the trust list model establishes a mapping relationship between electronic signature service providers and underlying CA root certificates. When the bridging module needs to verify the signature of an electronic document, the trust list model can quickly locate the corresponding trusted root certificate based on the digital certificate information embedded in the document, thereby completing the signature validity verification. Simultaneously, the trust list model also stores the CRL revocation list access address information of each CA vendor and synchronizes it to the CRL list management module in real time, ensuring that the latest certificate revocation status can be obtained promptly during the certificate verification process.

[0027] The bridging module is the core execution unit in this embodiment of the invention, establishing a bidirectional data communication link with the vendor management module. The bridging module receives multi-CA-signed electronic documents uploaded by the business system through a unified interface layer, and performs operations such as data packet parsing, format recognition, vendor matching, and full-process signature verification. The bridging module adopts a bidirectional bridging adaptation architecture design. Its downstream side is compatible with the private digital certificate standards of various CA vendors, as well as various national cryptographic and internationally recognized signature algorithms. Its upstream side exposes a unified and standardized interface, providing standardized verification services to the business system.

[0028] like Figure 2 As shown, the bridging module is internally divided into three independent functional units: a file parsing unit, a format recognition unit, and an adaptation and matching unit. These three units work together to complete the entire process of cross-CA electronic document verification.

[0029] The file parsing unit is responsible for disassembling the original electronic document data packets and extracting the embedded digital certificate information, unique signature algorithm identifiers, and file encapsulation format identifiers. File parsing unit 8 is compatible with parsing various types of signed electronic document data packets, covering mainstream electronic document formats such as PDF, OFD, XML, and JSON. For different file formats, the file parsing unit is configured with dedicated parsing logic modules. For PDF format electronic documents, file parsing unit 8 reads the signature field data within the file and extracts the signature field content from the PDF document's signature dictionary. For OFD format electronic documents, the file parsing unit reads the signature description file and extracts the signature byte stream from the OFD document's signature area. For XML and JSON format electronic documents, the file parsing unit extracts the embedded digital signature information by parsing XML nodes or JSON object structures.

[0030] The file parsing unit employs corresponding parsing strategies for electronic documents of different formats, uniformly outputting a standardized signature metadata dataset. The signature metadata includes at least four core fields: certificate issuer information, certificate serial number, signature algorithm OID, and original signature value. The certificate issuer information records the name of the CA (Certificate Authority) that issued the digital certificate; the certificate serial number is a unique number assigned to the certificate by the CA; the signature algorithm OID is an object identifier that identifies the type of signature algorithm; and the original signature value is the digital signature result calculated by the signer based on the document content. By extracting this standardized metadata, the file parsing unit converts electronic documents of different formats into a unified data structure, providing consistent data input for subsequent format recognition and adaptation matching.

[0031] The format recognition unit receives the signature metadata output by the file parsing unit, extracts the CA (Certificate Authority) name and signature algorithm type information, and automatically matches it with the CA vendor profiles in the trust list to accurately identify the target CA vendor that signed the current electronic document. The format recognition unit's identification process is based on the following logic: First, it extracts the CA name from the Certificate Issuer field in the signature metadata, such as "Shanghai Digital Certificate Authentication Center Co., Ltd." or "Beijing Digital Certification Co., Ltd."; then, it identifies the algorithm type used in the signature from the signature algorithm OID field, such as RSA, SM2, or ECDSA; finally, it matches the extracted CA name and algorithm type with the trust list in the vendor management module to locate the specific CA vendor that signed the document and generates a matching result containing the target CA vendor's identifier.

[0032] The format recognition unit has a built-in CA vendor feature library, which records personalized information such as certificate template characteristics, algorithm support range, and issuance policies of each CA vendor. When the format recognition unit cannot match the target CA vendor through the simple certificate issuer name, it can further analyze other feature fields of the certificate, such as certificate extensions and policy identifiers, and make a comprehensive judgment by combining the prior knowledge in the feature library to ensure the accuracy and reliability of the recognition.

[0033] The adaptation and matching unit is the unit in the bridging module responsible for executing the final verification logic. It receives the target CA vendor identifier output by the format recognition unit, retrieves the corresponding trusted root certificate from the vendor management module's trust list model, combines it with the certificate revocation status information provided by the CRL list management module, performs digital signature verification, and finally outputs a mutual recognition conclusion regarding the legality and validity of the electronic document.

[0034] The verification process of the matching unit includes the following specific steps: First, it queries the trust list model based on the target CA vendor's identifier to obtain the trusted root certificate information and intermediate certificate chain information of that CA vendor; then, according to the X.509 certificate chain verification specification, it verifies the intermediate certificates sequentially upwards from the user certificate in the electronic file, all the way to the root certificate, to build a complete certificate trust chain; next, it calls the interface provided by the CRL list management module to query whether the certificate serial number exists in the CRL revocation list. If it exists, it is determined that the certificate has been revoked, and the verification fails; finally, it uses the public key of the root certificate to decrypt the digital signature on the electronic file, and compares the decryption result with the recalculated hash value of the file content. If they match, the signature verification passes; otherwise, the verification fails. Based on the above verification results, the matching unit outputs a clear verification conclusion of mutual recognition pass or mutual recognition fail, and returns it to the business system through the unified interface layer.

[0035] The CRL list management module is responsible for maintaining the unified access addresses of the CRL (Certificate Revocation List) for each CA vendor and automatically retrieving the latest revoked certificate lists from each institution through periodic synchronization tasks. The module stores key configuration information such as the CRL list addresses for Shanghai CA, Beijing CA, CFCA, and Guangdong CA. Based on this configuration information, the module periodically triggers synchronization tasks, accesses the CRL publishing endpoints of each CA institution, obtains and parses the latest certificate revocation list data, and updates the serial numbers of revoked certificates to its local cache. When the matching unit performs signature verification, it synchronously calls the query interface provided by the CRL list management module to check the revocation status of the target certificate, preventing documents signed with invalid certificates from passing verification.

[0036] The unified interface layer employs standardized API services to enable standardized communication between business systems and cross-CA electronic document mutual recognition systems. Business systems can access a full suite of capabilities—certificate validity verification, digital signature verification, and general encryption / decryption—by calling the APIs provided by the unified interface layer, eliminating the need to develop separate adaptation code for each CA vendor. The unified interface layer defines complete interface specifications, including file upload interfaces, signature verification request interfaces, batch verification interfaces, and result query interfaces, supporting both synchronous and asynchronous calling modes to meet the needs of different business scenarios.

[0037] The cross-CA electronic document mutual recognition method of this invention includes the following main steps in its specific operation. Step S1 is the trust list model initialization and construction stage. This involves inputting the certificates and basic user profiles of all cooperating CA vendors through the vendor management module, establishing the binding relationship between the electronic signature service provider and the underlying CA root certificate, and inputting the CRL list access addresses of each vendor to complete the initialization and construction of the multi-CA mutual recognition trust list model. This stage also includes establishing data synchronization channels with each CA institution, verifying connection reliability, and ensuring that subsequent signature verification processes can normally obtain the latest certificate and revocation information.

[0038] Step S2 is the electronic document parsing, vendor matching, and signature verification stage. It receives multi-CA signed electronic documents uploaded by the business system through a unified interface layer. The bridging module performs data packet parsing, format recognition, vendor matching, and signature verification, ultimately outputting the mutual recognition determination result. This stage is further divided into three sub-processes for description.

[0039] Sub-process S21 is the file data packet disassembly stage. After receiving the electronic file, the file parsing unit first determines the file format type based on the characteristic bytes in the file header, and then calls the corresponding parsing module for differentiated parsing. For PDF format files, file parsing unit 8 locates the signature field in the PDF document, reads the byte stream data in the signature dictionary, and parses out the embedded X.509 certificate and digital signature. For OFD format files, the file parsing unit reads the signature description file in the OFD document packet and parses the signature metadata in XML format. For XML format files, the file parsing unit locates the Signature node through the XML parser and extracts the content of the KeyInfo and SignatureValue elements. For JSON format files, the file parsing unit parses the JSON object structure and finds the values ​​of the signature and certificate fields. Through the above parsing methods, the file parsing unit uniformly outputs standardized signature metadata containing the certificate issuer, certificate serial number, signature algorithm OID, and signature value.

[0040] Sub-process S22 is the target CA vendor identification stage. After receiving the signature metadata output by the file parsing unit, the format recognition unit extracts the CA name from the certificate issuer field and identifies the signature algorithm type from the signature algorithm OID field. The extracted information is then matched against the CA vendor profiles in the trust list model. If a match is successful, it is determined that the file was signed by the corresponding CA vendor, and a matching result containing the target CA vendor's identifier is generated. If a match fails, the format recognition unit attempts fuzzy matching or feature matching, combining prior knowledge from the CA vendor feature library for a comprehensive judgment to improve the identification coverage.

[0041] Sub-process S23 is the digital signature validity verification stage. Based on the target CA vendor identifier output in sub-process S22, the matching unit retrieves the corresponding trusted root certificate from the vendor management module's trust list model. Then, it calls the query interface of the CRL list management module to check if the target certificate's serial number appears in the latest synchronized CRL revocation list. If the certificate has been revoked, it immediately outputs a result indicating mutual recognition failure. If the certificate status is normal, it continues with the signature verification operation: using the root certificate's public key to decrypt the digital signature on the electronic document, obtaining the hash value used for signing; then, it calculates the current hash value using the same hash algorithm on the original content of the electronic document; it compares the decrypted hash value with the calculated hash value. If they match, it proves that the signature was indeed generated by the holder of the corresponding private key, and the signature verification passes; if they do not match, it indicates that the signature may have been tampered with or generated by an illegal private key, and the signature verification fails. Based on the above verification results, the matching unit outputs the final judgment of whether the file mutual recognition passes or fails.

[0042] Step S3 is the stage of outputting verification capabilities to the outside world through a unified interface. The business system can call the full-process cross-CA document verification capability through a single connection to the standardized API interface provided by the unified interface layer, and obtain a verification report containing detailed information such as verification results, certificate information, and signature timestamps. There is no need to care about the technical differences of the underlying CA vendors, so as to achieve unified identification and verification of electronic documents signed by all CA institutions.

[0043] To more clearly illustrate the technical effects of the embodiments of the present invention, a detailed description is given using a government e-bidding scenario as an example. A government e-bidding platform needs to receive electronic bid documents submitted by bidders from different regions. These bid documents may be signed with digital certificates issued by different CA vendors, such as Shanghai CA, Beijing CA, CFCA, and Guangdong CA. Under traditional technical solutions, the bidding party's business system needs to interface with the verification interface of each CA vendor separately, developing independent adaptation modules for each CA vendor. The development workload increases linearly with the number of CA vendors, resulting in high maintenance costs. Furthermore, the digital certificates used by bidders may come from different CA institutions, requiring the bidding party to prepare multiple sets of verification tools, leading to cumbersome operation processes and a poor user experience.

[0044] After accessing the cross-CA electronic document mutual recognition system of this invention, the bidding party's business system only needs to connect to the standardized API interface provided by the unified interface layer once to achieve unified verification of bid documents from all CA vendors. When bidder A uses a Shanghai CA digital certificate to sign a PDF format electronic bid document and uploads it to the bidding platform, the file parsing unit of the bridging module first reads the signature field data of the PDF file, extracts the embedded digital certificate and signature value information, and outputs standardized signature metadata. The format recognition unit identifies the signing agency as Shanghai CA based on the certificate issuer field in the signature metadata and generates a matching result containing the Shanghai CA vendor identifier. The adaptation matching unit retrieves the trusted root certificate of Shanghai CA from the trust list model of the vendor management module based on the Shanghai CA vendor identifier, and simultaneously queries whether the certificate has been revoked through the CRL list management module. Finally, it performs the signature verification operation and concludes that the verification is successful. The entire process is transparent and seamless to the business system and end users, requiring no installation of a dedicated Shanghai CA verification client or separate development of an adaptation program for Shanghai CA, thus completing cross-CA document mutual recognition.

[0045] The same verification process also applies to electronic documents signed by other CA vendors such as Beijing CA, CFCA, and Guangdong CA. The bridging module automatically identifies the corresponding CA vendor and calls the appropriate verification logic to ensure the accuracy and consistency of the verification results. When a new CA vendor needs to be integrated, simply add the vendor's trust profile in the vendor management module and update the trust list model. The business system can automatically support the verification requirements for documents from the new CA vendor without any code modifications.

[0046] This invention has been deployed and tested on a large scale on an electronic bidding platform, achieving significant technical improvements compared to traditional vendor-specific adaptation solutions. Regarding verification efficiency, traditional cross-CA file manual and system-based step-by-step verification takes approximately 120 minutes, while the automated unified verification of this invention reduces this time to less than 30 minutes, improving overall workflow efficiency by over 75%. In terms of development costs, traditional solutions require developing adaptation modules for N CAs, with development workload increasing linearly with the number of CAs. This invention only requires a single connection to a unified API interface, reducing overall development costs by over 60%. Regarding maintenance costs, traditional solutions require iterating business system code when adding a new CA vendor, while this invention only requires adding a vendor trust profile in the vendor management module, achieving zero code modification and significantly reducing long-term maintenance complexity.

[0047] This invention's cross-CA electronic document mutual recognition system and method relies on a bridging module to complete multi-format file parsing and automatic CA vendor identification. Combined with the vendor management module's trust list model, it constructs a global trusted trust chain, enabling unified parsing and mutual recognition of documents signed by different CA institutions. This solution focuses solely on the document verification process and does not involve electronic signature generation. It is lightweight and highly versatile, completely resolving the industry pain point of incompatibility between multiple CA certificates, algorithms, and encapsulation standards, which leads to inability to verify documents across CAs, thus breaking down barriers to cross-CA electronic document mutual recognition. Business systems only need to interface with a single standardized and unified API interface to be compatible with the electronic document verification needs of all CA vendors, eliminating the workload of developing separate adaptation modules for each vendor. In scenarios involving the addition or replacement of multiple CAs, only the vendor trust list within the system needs to be updated; the business system requires no secondary modifications, significantly reducing long-term maintenance complexity and substantially lowering business system development and maintenance costs. The system integrates standardized CA mutual recognition components, making deployment convenient and effectively supporting the high-speed flow of government and business documents across regions, departments, and levels, significantly improving the efficiency of cross-domain electronic document flow. The bridging module is natively compatible with mainstream signed electronic documents such as PDF and OFD. End users can complete cross-vendor document verification without installing multiple CA-specific clients and verification tools. The entire process is transparent and seamless for end users, thus optimizing the user experience.

[0048] In the description of this invention, the terms "Electronic Certification Authority" or "CA Authority" refer to a third-party certification authority that has obtained an electronic certification service license in accordance with the law, responsible for issuing and managing digital certificates and providing certification services for electronic signatures. The term "digital certificate" refers to an electronic credential issued by a CA Authority that contains the certificate holder's public key information and identity information, using the X.509 standard format. The term "CRL" refers to a Certificate Revocation List, published periodically by the CA Authority, recording the serial numbers of revoked certificates for verification purposes. The term "signature metadata" refers to the core data elements extracted from signed electronic documents used for signature verification, including certificate information, algorithm identifiers, and signature values. The term "trust list model" refers to a data structure that stores CA vendor information and certificate trust relationships, used to quickly locate trusted certificates in cross-CA signature verification scenarios. The term "bridging adaptation" refers to the technical means of protocol conversion and data mapping between different technical standards to achieve interoperability between heterogeneous systems.

[0049] In this invention, unless otherwise explicitly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "over," and "on top" of the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

[0050] In this invention, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0051] Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

Claims

1. A cross-CA electronic document mutual recognition system, characterized in that, Includes a vendor management module and a bridging module; The vendor management module is configured to manage the basic information of multiple CA vendors and establish a trust list model based on the basic information, wherein the basic information includes the certificate information and user information of each CA vendor. The bridging module is communicatively connected to the vendor management module and is configured to obtain electronic documents signed by different CA vendors provided by the user, parse and identify the data packets of the electronic documents, and match the corresponding CA vendor information from the vendor management module according to the parsing results to verify and mutually recognize the electronic documents. The bridging module adopts a bridging adaptation mode, which adapts to the digital certificates and signature algorithms of different CA vendors downstream, and provides a unified interface for business systems upstream.

2. The cross-CA electronic document mutual recognition system as described in claim 1, characterized in that, The bridging module includes a file parsing unit, a format recognition unit, and an adaptation matching unit. The file parsing unit is configured to disassemble the data packet of the electronic file provided by the user and extract the digital certificate information, signature algorithm identifier, and encapsulation format information. The format recognition unit is configured to identify the target CA vendor that signed the electronic file based on the extracted digital certificate information and signature algorithm identifier. The adaptation matching unit is configured to retrieve the corresponding digital certificate information from the trust list model of the vendor management module based on the identified target CA vendor and verify the digital signature of the electronic file.

3. The cross-CA electronic document mutual recognition system as described in claim 2, characterized in that, The file parsing unit supports parsing data packets of various electronic document formats, including PDF and OFD format signed data packets. The file parsing unit adopts corresponding parsing strategies for different electronic document formats to extract signature metadata in a unified format. The signature metadata includes certificate issuer information, certificate serial number, signature algorithm OID, and signature value. The file parsing unit reads signature field data for PDF format files and signature description files for OFD format files, extracts signature node data, and outputs a unified standardized signature metadata dataset.

4. The cross-CA electronic document mutual recognition system as described in claim 2, characterized in that, The format recognition unit extracts the CA (Certificate Authority) name from the digital certificate issuer field output by the file parsing unit, identifies the signature algorithm type from the signature algorithm identifier, automatically matches the CA vendor profiles in the trust list, accurately identifies the target CA vendor to which the document is signed, and generates a matching result containing the target CA vendor identifier.

5. The cross-CA electronic document mutual recognition system as described in claim 2, characterized in that, The matching unit retrieves the corresponding trusted root certificate from the trust list model of the vendor management module based on the identified target CA vendor identifier, performs digital signature verification operation in conjunction with the CRL revocation status verification result, outputs a mutual recognition conclusion on whether the file is legal and valid, and finally outputs a clear verification conclusion of mutual recognition pass or mutual recognition fail.

6. The cross-CA electronic document mutual recognition system as described in claim 1, characterized in that, The system also includes a CRL list management module, configured to configure the CRL list addresses of each CA vendor, periodically obtain the list of revoked certificates, and perform revocation status checks during certificate verification. The CRL list management module uniformly maintains the CRL revocation list addresses of each CA vendor and is configured to automatically pull the latest revoked certificate list through a scheduled synchronization task. When the adaptation and matching unit performs signature verification, it synchronously calls the CRL list management module to verify the certificate revocation status.

7. The cross-CA electronic document mutual recognition system as described in claim 1, characterized in that, The trust list model is a multi-CA mutual recognition and verification trust list model, which is configured to establish the relationship between each CA electronic signature service provider and the certificate provided by the CA institution it uses, based on the certificate information provided by the CA institution used by each CA electronic signature service provider. The core logic of the trust list model is to establish a one-to-one binding relationship between the electronic signature service provider and the underlying CA root certificate, retrieve the trusted certificate when verifying electronic documents across vendors, and store the access addresses of the CRL revocation lists of each CA vendor and synchronize them to the CRL list management module.

8. A method for cross-CA electronic document mutual recognition, applied to the cross-CA electronic document mutual recognition system according to any one of claims 1 to 1, characterized in that, Includes the following steps: The system manages the basic information of multiple CA vendors through a vendor management module and establishes a trust list model. It acquires electronic documents signed by different CA vendors provided by users, parses and identifies the data packets and formats of the electronic documents through a bridging module, and matches the corresponding CA vendor information from the vendor management module based on the parsing results to verify and mutually recognize the electronic documents. Through a unified interface provided to upstream business systems, the business systems can identify and verify electronic documents signed by multiple CA institutions through a single connection.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the cross-CA electronic document mutual recognition method as described in claim 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the cross-CA electronic document mutual recognition method as described in claim 8.

Images