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(_at_)ietf(_dot_)org 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