Re: Last Call: <draft-laurie-pki-sunlight-05.txt> (Certificate Transparency) to Experimental RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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)


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]