At 11:33 20-12-2012, 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?
In Section 3:
"Logs MUST NOT impose any conditions on copying data retrieved from
the log."
I am reading the above as meaning that the data retrieved is in the
public domain. Is that correct? The wording could be improved as
logs do not have any consciousness.
In Section 3.1:
"In order to enable attribution of each logged certificate to its
issuer, the log SHALL publish a list of acceptable root certificates
(this list might usefully be the union of root certificates trusted
by major browser vendors)."
Why is this a "SHALL" instead of a "MUST"? I suggest a better
wording for "log" in the above as "log" is defined as "a single,
ever-growing, append-only Merkle Tree of such certificates". There
are other occurrences of "log" in the draft that should be reviewed.
In Section 4:
"Messages are sent as HTTPS GET or POST requests. Parameters for
POSTs and all responses are encoded as JSON objects.
I suggest adding a reference for JSON objects.
"It must map one-to-one to a known public key (how this
mapping is distributed is out of scope for this document)."
This looks like a requirement.
"A compliant v1 implementation MUST NOT expect this to
be 0 (i.e. v1)."
What happens if the v1 implementation gets a zero?
In Section 7.3:
"Violation of the append-only property is detected by global gossiping,
i.e., everyone auditing logs comparing their versions of the latest
signed tree heads."
In my humble opinion that's a practical approach.
Section 7 is about security and privacy considerations. I didn't see
any privacy considerations in Section 7. I don't think that it is
really needed as the document is about publicly auditable logs. If
there is any concern about information disclosure it could be
mentioned that Certificate Transparency is for public end-entities.
Regards,
-sm
1. Confirm that there are automatic blocks in place for high-profile
domain names (including those targeted in the DigiNotar and Comodo
attacks in 2011)