声明：喝了酒翻译的，出问题不负责。
原文：
http://blog.ejbca.org/2013/09/certificate-transparency-and.html
词汇表：
TBSCertificate：To-Be-Signed, 将要被颁发的证书，https://stackoverflow.com/questions/5304531/certificate-structure
issuerDN：发放者专有名称，http://www-01.ibm.com/support/knowledgecenter/SSPLFC_7.2.2/com.ibm.taddm.doc_7.2.2/zemainstall/zema_install_cce_api_appendix_PUT_eccapi_admin_config_certificates_alias.html?lang=zh
subjectDN：主题专有名称，同上
CT：Certificate Transparency，证书透明度
On to PreCertificates...
前证书：
PreCertificates are defined in section "3.1. Log Entries" as (text trimed by me) "The Precertificate is constructed from the certificate to be issued by adding a special critical poison extension to the end-entity TBSCertificate". Then it describes how it can be produced and it is mentioned throughout the spec in many places.
rfc6962 3.1节称，“前证书是”TBSCertificate前部加一个关键扩展，描述证书如何生成。RFC接下来用了很多这个名词。
A PreCertificate is a essentially a certificate signed with one of two options:
有两种办法签发前证书：
1. PreCertificates signed by the real CA.
This sounds very dangerous as will break the fundamental X.509 rule of unique issuerDN/serialNumber pairs. The consequences of having two "certificates" with the same issuerDN/serialNumber in the wild can not possibly be estimated, making this practice quite dangerous imho.
1.用真实CA签发
听起来很危险，因为破坏了X.509中唯一发放者专有名称/序列号对的规则。有可能会出现两个有效的证书，在我看来很危险。
2. PreCertificates signed by a separate PreCertificate signing CA, which is a SubCA to the real signing CA. This is a less scary, since it is normal practice that different CAs can issue certificate with the same subjectDN/serialNumber, just not the same issuerDN.
2. 用专门的根CA下属的前证书CA签发。
这样看起来好多了，因为不同的CA可以发出同样主题专有名称/序列号对的证书，只是发放者专有名称不同。
The actual implementation of issuing PreCertificates makes it quite impractical. I would believe that most CA implementations creates theTBSCertificate as part of the actual certificate issuance. The CA will not create the TBSCertificate to have is lying around for a couple of days before using it to issue the real certificate.
发放前证书的过程让这个东西不使用。我觉得大部分CA都不会在发放证书前先发放一个这个，就为了在发放真证书前混几天。
Thus, if the CA is to create a PreCertificate to send to the CT log, it might as well issue the real certificate and send it to the log. The time difference should be in the milliseconds for most CAs.
所以，如果CA想部署证书透明度系统，直接签发真证书就是——就差个几毫秒时间。
If the CA wants to wait before distributing the real certificate, to make sure it's in the logs before put into production, it can surely do so as well.
如果CA想等等再发真实证书，确保日志进入系统，也可以。
The PreCertificate imho suffers from several complicating factors for implementers, both on the CA and the CT log side. The TBSCertificate must have a poison extension inserted, and removed, effectively re-encoding the ASN.1 TBSCertificate several times, all these are points of failure.
所以前证书在CA和日志方面都受影响。TBSCertificate必须包括一个投毒前缀，Blahblah。
The reason for PreCertificates are not clearly explained. Why would you want to use PreCertificates?
那为什么要用前证书啊？
Fine combing through the spec gives me some ideas on why, for example to be able to embed the Certificate extension from PreCertificate CT logs in the final certificate (section 3.3). But the the TBSCertificate of the PreCertificate is then no longer the real TBSCertificate? In that case, why is the PreCertificate the TBSCertificate at all, and not just a new data structure with the data the CT log wants?
例如，将前证书的日志加入最终证书。但是还是很乱啊。
The PreCertificate complicates the CT spec by orders of magnitude, which is not a good thing. There are so many ifs and buts about PreCertificate the RFC is not even itself consitent about what it is.
所以前证书就是胡闹，B事一堆，最终啥都没弄明白，RFC都没想明白这东西是干什么的。
Ok, I know the PreCertificate is is optional, but the best standards, who gets fast, wide and robust deployment, are the simpler ones (KISS). Skipping PreCertificates from the CT spec makes it so much simpler.
恩，前证书是可发可不发的，但是为了简化，就不要他得了。
My suggestion:
- Skip PreCertificates altogether
我的建议：
- 别用前证书了
I see though why people will not accept that just because I say something...so in that case
- Explain the purpose behind PreCertificates well
- Describe what the actual information fro PreCertificate are used
- Be consistent throughout in the RFC