7.9 PKIX support
-
7.9.8 Consideration of actual application
-
Consideration of plan
1. The public key system is just a technical specification, an infrastructure.
2. If the goal of mutual trust between systems needs to be achieved, the corresponding agreement between systems must be reached and all participants must follow the constraints of the agreement.
3. Usually, it is necessary to design the audit specification and supervise the implementation of the agreement.
4. For example, the public domain CA signs a website certificate to prove the authenticity of the site to the user. Once such a CA issues the same certificate to the domain name hijackers, the user must be deceived. Therefore, the public domain CA must be a trusted third party. The trouble is that the trusted third party is not self-certified, so all public domain CA provide the audit and the remains issues belong to the law.
5. It can be understood that the trust provided by the public key system is the extension of the reality trust to the electronic system. The reality trust is the real basis.
6. Determine that the systems with the reality trust relationship can arrange the signed field model of the certificate by themselves and explain the corresponding fields by themselves. The Limax reinterprets the certificate policy, provides enumerated limax.pkix.X509CertificatePolicyCPS. This enumeration can be inherited if necessary, providing a basic partition for the private trust system.
-
Consideration from operation
-
1 ROOTCA
1.1 In the period of validity, the private key must be safely saved. A varity of offline ways can be chosen. The PKCS11 smart card can be used as a choice, but not is the best one because the hardware failure should be considerated.
1.2 The Ocsp signature certificate exipration issue should be noted. Once the Ocsp signature certificate is expired, the OcspServer automatically exits.
1.3 The actual expiration time of Ocsp signature certificate is determined by the certificate expiration time minus nextUpdateDelay, bacause the signature certificate has no reason to endorse the behavior beyond its validity period.
1.4 If the ROOTCA wants to revoke the CA certificate, the two steps should be performed. First, upload the CA certificate to OcspServer and move to ocspStore directory; then, use gencrl to issue CRL, and upload to the location specified by OcspServer cRLFile.
1.5 The ROOTCA is responsible for updating CRL and uploading it to OcspServer server host according to the nextUpdate date set when signing CRL last time.
-
2 CAServer
2.1 The safe server host (network security and physical security must be considered). After all, the CA private key is stored on it, and the PKCS11 smart card can be considered.
2.2 The certificate management service is bound on localhost. Actually, the operator should not directly login CAServer to operate certificate management, and must set up a reverse proxy. Here a auditable link is purposely added.
2.3 Start the authcode.jar generated by CAServer. Although it can be freely distributed, it is only in the pre-condition that the authCode seed is enough safe. If a leak problem is doubtable, it could re-start CAServer and re-set seed to generate the new authcode.jar.
2.4 The anti-Trojan is necessary for the machine to run the certificate management service.
2.5 The CA certificate expiration issue should be noted and send the new application to ROOTCA in advance.
2.6 Design timing execution script to collect the certificate within the archive directory, manage all issued certificated according to the design plan, and clean up the archive directory after collection.
3 In the pre-condition that the server memory allows, try to configure a large Ocsp response cache.
4 The external service, using HTTP and HTTPS protocols, can set up the corresponding forward proxy.
5 Run ntp service to synchronize the timer.
6 Choose anti-attack and safe domain name service.
7 In order to achive the anti-attack and load balance goals, the OcspServer and CAServer can be deployed multiple copies, and any a CAServer can be used to sign certificate. The REVOKE and RECALL operations can be considered to timing execute the simple script on the server-side, obtaining the operation data on the specified position and directly operating in the ocspStore directory.
-
-
Consideration from development
1 The certificate field designed in the plan stage, and strategy explaination way must be correctly executed in the development.
2 The certificate chain signed by CAServer contains the ROOTCA certificate which issued CAServer. The verification in the simple case is enough. If ROOTCA itself is overdue and renewed, or it is necessary to verify the certificate derived from the other ROOTCA, the renewed or other ROOTCA must be added to the trust. For example, limax.pkix.SSLContextAllocator.addTrust(), provides such method.
3 The ROOTCA certificate must be distributed through a secure channel. In reality, the Windows update and JDK update will update the ROOTCA certificate on the public domain. Such type of updates through network, have no way to avoid fraud in fact. Perhaps in the pre-condition that assuming that fraud will not continue, there is chance to provid some strategy afterwards.
4 In fact, the tools provided by Limax do not support DSA algorithm. In the beginning of design, the DSA algorithm with SHA1 is used to sign. After 2017, the SHA1 is gradually abandoned. DSA1024/SHA256, DSA2048/SHA256, these algorithm are supported by JDK, but not by Windows. So for compatibility, the Limax tools just provide the algorithm to test and prove the compatibility. The EC alogorithm uses some specific curves which are published by authority and have no compatibility issue. The skeptics worry about implantating the back door, so the RSA algorithm is the common choice.
-