Subject: [Trans] Working group last call, draft-ietf-trans-rfc6962-bis

From: Melinda Shore <[email-masked]>
Date: Tue, 4 Jul 2017 10:37:33 -0800

Hi, all:

This is to announce the (re)start of working group last
call on  draft-ietf-trans-rfc6962-bis.  The draft is
available at: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

Last call will close on July 18, 2017.  Please send comments
to this mailing list.

Melinda

---

From: Andrew Ayer <[email-masked]>
Date: Mon, 17 Jul 2017 20:46:10 -0700

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?

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.

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].

Regards,
Andrew

[1] https://www.ietf.org/mail-archive/web/trans/current/msg03035.html

---

From: Eran Messeri <[email-masked]>
Date: Tue, 18 Jul 2017 16:39:12 +0100

Thanks for the thorough review of the document, Andrew, replies below.

> certificate.  Should it say 2 (precertificate) instead?
Proposed  fix in
https://github.com/google/certificate-transparency-rfcs/pull/271.

> replacement of the add-chain and add-pre-chain API endpoints with
Proposed fix for both in
https://github.com/google/certificate-transparency-rfcs/pull/272.

> have put a proposed fix out for discussion[1].
I'll follow up on that thread.

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>