7.9 PKIX支持
-
7.9.8 现实应用的考虑
-
规划的考虑
1. 公钥系统仅仅是技术规范，一个基础设施。
2. 如果要达成系统间相互信任的目标，必须在系统间达成相应的协议，所有参与者必须遵从协议的约束。
3. 通常情况下，设计审计规范，监督协议的执行是必要的。
4. 例如，公共域CA签发一份网站证书，向用户证明网站的真实性。一旦这样的CA为域名劫持者签发同样的证书，用户必然被欺骗。所以，公共域CA必须是可信第三方，麻烦在于可信第三方不可自证，所有的公共域CA都提供审计，剩下的问题只能扔给法律。
5. 可以这样理解，公钥系统提供的信任，是现实中的信任向电子化系统的延伸，现实中的信任才是真正的基础。
6. 确定现实信任关系的系统之间，可以自己约定证书签署字段的模式，自己解释相应的字段。Limax重新解释证书策略，提供枚举limax.pkix.X509CertificatePolicyCPS，需要的情况下可以继承该枚举，为私有的信任系统提供一个最基本的划分。
-
运营的考虑
-
1 ROOTCA
1.1 有效期内私钥必须安全保存，可以选择各种线下方式，PKCS11智能卡可以作为一个选择，但不一定是最好的，硬件失效也应该考虑
1.2 注意Ocsp签名证书过期问题，一旦Ocsp签名证书过期，OcspServer自动退出。
1.3 Ocsp签名证书的实际过期时间由证书过期时间减去nextUpdateDelay决定，因为签名证书没有理由为自己有效期范围外的行为背书。
1.4 ROOTCA如果要回收CA证书, 应该执行2步操作, 首先将CA证书上传到OcspServer, 移动到ocspStore目录；接下来使用gencrl签署CRL, 上传到OcspServer cRLFile指定位置。
1.5 ROOTCA有责任根据上一次签署CRL时设置的nextUpdate日期更新CRL并上传到OcspServer服务器主机。
-
2 CAServer
2.1 安全的服务器主机（网络安全，物理安全都必须考虑），毕竟CA私钥存储在上面，可以考虑使用PKCS11智能卡。
2.2 证书管理服务绑定在localhost上，实际上，操作者不应该直接登录CAServer操作管理证书，必须架设反向代理，这里故意增加了一个可审计环节。
2.3 启动CAServer生成的authcode.jar，虽然可以随意分发，但也只是在authCode种子足够安全的前提下。如果怀疑出现了泄密问题，可以重新启动CAServer，重新设置种子生成新的authcode.jar。
2.4 执行证书管理服务的机器，防木马是必须的。
2.5 注意CA证书过期问题，提前向ROOTCA发出新的申请。
2.6 设计定时执行脚本，收集存档目录内的证书，根据设计规划管理所有已签发证书，收集之后清理存档目录。
3 服务器内存许可的前提下，尽量配置大的Ocsp响应cache。
4 对外提供的服务，使用HTTP，HTTPS协议，可以架设相应的正向代理。
5 运行ntp服务，同步时钟。
6 选择抗攻击，安全的域名服务。
7 为了达成抗攻击、负载均衡的目标，OcspServer与CAServer均可以部署多份。这种情况下，签署证书使用任意一台CAServer即可；REVOKE，RECALL操作可以考虑在服务器端定时执行简单脚本，到特定位置获取操作数据，在ocspStore目录内直接操作。
-
-
开发的考虑
1 规划阶段设计的证书字段、策略解释方式必须在开发的时候正确执行。
2 CAServer签发的证书链，自带了签发CAServer的ROOTCA证书，简单情况下的验证是足够的。如果ROOTCA本身过期更新了，或者需要验证别的ROOTCA派生出来的证书，就必须把更新的、别的ROOTCA加入信任，例如，limax.pkix.SSLContextAllocator.addTrust()，提供了这样的方法。
3 ROOTCA证书必须通过安全渠道分发，现实中，Windows更新，JDK更新，都会更新公共域上的ROOTCA证书，这一类通过网络的更新，事实上都没有办法保证避免欺骗，也许假设欺骗不会持续发生这一前提，有机会提供某些事后策略。
4 事实上Limax提供的工具并没有支持DSA算法，DSA算法设计之初就是搭配SHA1用来签名，2017以后SHA1逐渐废弃。DSA1024/SHA256，DSA2048/SHA256，这些算法JDK能够支持，但是Windows并不能支持，为了兼容性，Limax工具仅提供了测试证明兼容的算法。EC算法使用的一些特定曲线，由权威机构发布，兼容性没有问题，怀疑论者担心植入后门，RSA算法还是常用选择。
-