SM wrote: > > The IESG wrote: >> >>The IESG has received a request from an individual submitter to consider >>the following document: >>- 'Certificate Transparency' >> <draft-laurie-pki-sunlight-05.txt> as Experimental RFC >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send substantive comments to the >>ietf@xxxxxxxx mailing lists by 2013-01-24. Exceptionally, comments may be > > In Section 1: > > "Certificate Transparency aims to mitigate the problem of misissued > certificates by providing publicly auditable, append-only, untrusted > logs of all issued certificates." > > It seems that CAs are having trust issues. ETSI TS 102 042 audits > looks like paperwork instead of assessing what could go wrong > [1]. Isn't Certificate Transparency trying to mitigate the problem > of CAs issuing fake certificates instead of "misissued" certificates? More appropriately, RPs are having trust issues with public CAs, and domain owners have found themselves more than once faced with the unexpected fraudulent issuance of certs allegedly authorized for their domains. Certificate Transparency (CT), the ways I understand it, is basically a public certificate issuance log for public CAs (those you find in the CABrowser forum, who have their their (Root)CA certs distributed as pre-trusted in common Web Browsers). Such a public cert issuance log can be used by domain owners to detect cert issuance for their domains that they didn't actually authorize or ask for (so which are likely fraudulent) *much* earlier after cert issuance. So far, this would often only become apparent if the CA detected the fraudulent issuance itself, or when an attacked RP would realize that it is being attacked with a perfectly valid(!!) server certificate. The latter typically happens only with RPs that perform cert pinning and where the user that is alerted about an unexpected server cert change is sufficiently knowledgable to distinguish a likely misissued server cert from a mere roll-over server cert change. X.509/PKIX has a serious design/birth defect in certificate revocation, by lacking the means to convey the information whether a certificate was properly issued and is properly visible to CA audits and desaster recovery procedures. For CRLs that design flaw can not be fixed within the protocol itself, because CRLs are a pure blacklisting mechanism that blindly assumes that the absence of a revocation implies that a certificate has been properly issued. An assumption that has been proven to be a flawed in the real world several times by now. When complementing CRL checking with CT, this X.509 CRL design flaw can be mitigated. There currently are proposals for fixing a slightly different (but related) problem for OCSP in PKIX, but there are some X.509 fanciers that appear enfuriated by the idea of admitting that X.509 CRLs and rfc2560-OCSP contain a shortcoming that needs fixing, so progress in PKIX is slow. The scope of CT is different than whatever PKIX might deliver (even when rough consensus can be obtained within PKIX to improve OCSP), because CT allows domain owners to monitor/determine issuance of certs for their domain from public records. -Martin