Thanks for the thorough review of the document, Andrew, replies below. On Tue, Jul 18, 2017 at 4:46 AM, Andrew Ayer <[email protected]> wrote:
> On page 27, the following doesn't make sense to me: > > > If the returned "sct" is intended to be provided to clients, then > > "sth" and "inclusion" (if returned) SHOULD also be provided to > > clients (e.g., if "type" was 1 then all three "TransItem"s could be > > embedded in the certificate). > > First, I assume "client" means TLS client? > > Second, since a type of 1 means a certificate (not a precertificate), > it's unclear how the returned TransItems could be embedded in a > certificate. Should it say 2 (precertificate) instead? > Proposed fix in https://github.com/google/certificate-transparency-rfcs/pull/271. > > Page 32 refers to the '"submission" output parameter'. There is no > submission output parameter. It should say "submitted_entry" instead. > > I think section 1.3 (Major Differences from CT 1.0) should mention the > replacement of the add-chain and add-pre-chain API endpoints with > submit-entry. > Proposed fix for both in https://github.com/google/certificate-transparency-rfcs/pull/272. > > I am disappointed that the get-sths endpoint isn't included, though I > accept that this can go in a future document. > > A more serious issue is that the signature mutation attack I reported > is not fixed. This is a correctness issue and needs to be fixed. I > have put a proposed fix out for discussion[1]. > I'll follow up on that thread. > > Regards, > Andrew > > [1] https://www.ietf.org/mail-archive/web/trans/current/msg03035.html > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
