On 14 January 2013 11:30, Stephen Farrell <stephen.farrell@xxxxxxxxx> 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@xxxxxxxxxxxx> > To: ietf@xxxxxxxx > > 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@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? 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/therightkey