On 14 January 2013 11:30, Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
FYI. Some comments sent just to the IETF list. Please
respond there.
Thanks,
S.
-------- Original Message --------
Subject: Re: Last Call: <draft-laurie-pki-sunlight-05.txt> (Certificate
Transparency) to Experimental RFC
Date: Thu, 10 Jan 2013 09:10:32 -0800
From: SM <sm(_at_)resistor(_dot_)net>
To: ietf(_at_)ietf(_dot_)org
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?
Is there a difference, when you get down to it?
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?
Yes. This is necessary for auditing/monitoring.
The wording could be improved as
logs do not have any consciousness.
I have changed it to "Log operators..."
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"?
MUST and SHALL are equivalent.
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.
What wording do you suggest that would be better?
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.
There will be in the next version.
"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.
If it were a requirement it would say MUST - but in any case, it is
gone in the next version.
"A compliant v1 implementation MUST NOT expect this to
be 0 (i.e. v1)."
What happens if the v1 implementation gets a zero?
I don't understand the question.
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.
Good point, I have renamed it.
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)
_______________________________________________
therightkey mailing list
therightkey(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/therightkey