Subject: [therightkey] fwd: apps area review of draft-laurie-pki-sunlight-05 (Eliot's version)

From: =JeffH <[email-masked]>
Date: Mon, 21 Jan 2013 19:13:48 -0800

------- Forwarded Message

Date:    Thu, 10 Jan 2013 13:50:07 +0100
From:    Eliot Lear <[email-masked]>
To:      [email-masked],
	 "[email-masked]" <[email-masked]>, "'IESG'" <[email-masked]
	  rg>
Subject: [apps-discuss] apps area review of draft-laurie-pki-sunlight-05 (Eliot
	  's version)

Gents,

Thanks for contributing an experimental doc to the IETF.

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-laurie-pki-sunlight-5
Title: Certificate Transparency
Reviewer: Eliot Lear
Review Date: 10 Jan 2012
IETF Last Call Date: 20 Dec. 2012

Summary: This document requires relatively minor revision prior to
publication.  Noting that its intended status is experimental, I've
focused on clarity of what problem is being solved and the clarity of
how it is being solved so that the experiment can be performed and
appropriate analysis performed.  In particular there seem to be two
goals: for an owner to monitor what certs have been signed for a given
subject, and for an auditor to review ALL certs on a log, perhaps
relevant to a particular CA or multiple CAs.  Anyway, get more clear
please in the beginning.

Major issues:

Note: I haven't tested your formal assertions in Section 3.  That's for
implementers of your specification.

Introduction:

I would prefer to see a clearer statement of the problem, such that it
is clear that the complexity of Merkle trees is warranted.  In the
absence of such a statement, a reference to something would suffice.  In
particular, how large a data set would alternatively be returned in a
linear fashion?  What is being optimized, and what is being traded off?
I don't expect this is a major effort to correct, but it will be a major
flaw if it is not corrected (thus listed here).

Please include a reference to what you mean by Log or define it formally.

Minor issues:

Abstract:

Do you really mean "log signatures" in your last paragraph?  What if the
log itself has its private key stolen?

"Misissued" is not a word.  This might seem like a nit but you make it
quite hard for non-native speakers to understand what you are trying to
say when they can't use a dictionary to figure it out.

Introduction

Consider including an Existing Work subsection.

Section 2.1.1:

    In other words, the audit path consists of the list of
    missing nodes required to compute the nodes leading from a leaf to

Did you really mean "missing nodes" or just "nodes" or
"internal/interior nodes"?

In that section, more clearly define "m".

3. Log Format

    Anyone can submit certificates to certificate logs for public
    auditing, however, since certificates will not be accepted by clients
    unless logged, it is expected that certificate owners or their CAs
    will usually submit them.

This might be clear if we understood more clearly what problem you were
solving.  Also, fix the run-on sentence.

Section 3.1:

    Anyone can submit a certificate to any log.  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).

There is an implication that really authorization occurs through the
accepted list of CAs.  I don't know that you need to or want to state
the first sentence.  Rather you've provided a RESTful interface.  Why
not allow for appropriate HTTP/TLS authentication and leave it to
deployments?

Section 4

Please indicate the appropriate MIME type for responses (e.g., Accept:)
as well as for your POSTs.
Nits:

1. Informal introduction

Introduction is enough, unless you are going to have both a formal
introduction AND an informal introduction...

Please add a citation for Merkle Trees.  Here's one:
Merkle, R. "Secrecy, authentication and public key systems / A certified
digital signature". Ph.D. Dissertation, Stanford University, 1979.

Section  3 and elsewhere

Your formal description language requires a reference.

------- End of Forwarded Message