Public Notary Transparency
charter-ietf-trans-01

[Ballot comment]
COMMENT 1:
It's important for this charter to be very clear about what logs do and do not do.  They do not correct errors; they only make them visible.  Then you use other things (e.g., cert revocation) to correct the errors.

OLD: "Cryptographically verifiable logs can help to ameliorate these
problems by making it possible to discover and rectify errors before
they can cause harm."
NEW: "Cryptographically verifiable logs can help to ameliorate these
problems by making it possible to discover errors quickly, so that other
mechanisms can be applied to rectify them."


COMMENT 2:
The paragraph starting "These logs can potentially also..." seems speculative and not especially helpful here.


COMMENT 3:
BLOCK 1:
The first deliverable seems to conflate a few things:
  1. How certs get into the logs
  2. How relying parties get information from the logs
  3. How relying parties use information from the logs in validation
The third of these seems quite different from the first two.  For example, the DANE considerations only apply to (3).  Would it be useful to disaggregate these into say two deliverables?  One for log operators (1/2), and one for clients (2/3)?

[Ballot comment]
COMMENT 1:
It's important for this charter to be very clear about what logs do and do not do.  They do not correct errors; they only make them visible.  Then you use other things (e.g., cert revocation) to correct the errors.

OLD: "Cryptographically verifiable logs can help to ameliorate these
problems by making it possible to discover and rectify errors before
they can cause harm."
NEW: "Cryptographically verifiable logs can help to ameliorate these
problems by making it possible to discover errors quickly, so that other
mechanisms can be applied to rectify them."


COMMENT 2:
The paragraph starting "These logs can potentially also..." seems speculative and not especially helpful here.

[Ballot comment]
Let's call it:

LIMPID: Leave the Iesg out of Making names for Protocols are Internationally Deployed

:)

Says this having commented earlier on in their AD tenure against something called LSD .....

[Ballot comment]
Let's call it:

LIMIPID: Leave the Iesg out of Making Interesting names for Protocols that might be Internationally Deployed

:)

Says this having commented earlier on in their AD tenure against something called LSD .....

[Ballot comment]
This at least clarifies it to the point that I understand what they intend to do. I still think it's a shame that they won't be able to work on generic CT for TLS (as against CT for HTTPS) without a re-charter, but that's between the proponents and Stephen.

[Ballot comment]
Thanks for addressing my Blocking concern and the second of my Comments. I leave the unaddressed comment here in case it worries you that your current text is ambiguous and causes chuckles ("hashes of more-or-less anything that is structured in such a way as to provide...")

Would be nice to clean up the long sentences to avoid run-on subordinate
clauses that are ambiguous. Thus...
OLD
A
cryptographically verifiable log is an append-only log of hashes of more-or-less
anything that  is structured in such a way as to provide efficiently-accessible,
cryptographically-supported evidence of correct log behaviour.
NEW
A
cryptographically verifiable log is an append-only log of hashes of more-or-less
anything.  The log is structured in such a way as to provide efficiently-accessible,
cryptographically-supported evidence of correct log behaviour.
END

[Ballot block]
I would like to discuss the following matter with the security ADs:

Given recent discussions I am surprised that privacy is not a work item. The charter calls for work on "Cryptographically verifiable logs". The upside of cryptographically verified logs is that they undeniably verify logs. The downside is that they undeniably verify logs which may contain matter of privacy concern which some may wish to deny.

[Ballot block]
I'm putting this in as a BLOCK mostly because I suspect the answer I will get back is, "No, you've misunderstood what this WG is supposed to do", in which case there is going to need to be a different set of changes made to the charter. Either way, this is causing me confusion and I suspect needs to be fixed before we send it out.

  Mitigating web site certificate mis-issuance is the initial problem of
  interest for this working group.

Seem like it is the *only* (as against "initial") problem of interest for this group. I would suggest: "Mitigating web site certificate mis-issuance through the audibility of certificate issuance is the problem of interest for this working group."

  Additionally, many other Internet protocols require a mapping between
  some kind of identifier and some kind of public key, for example,
  SMTPS, IPSec, DNSSEC and OpenPGP. As with HTTPS, these protocols rely

I think the above obfuscates the purpose of this WG. As I understand it, the WG is to work on something for purposes of certificate authentication, completely independent of protocol. (If that's not true, then I don't really understand what the intent of the WG is, and that needs to be clarified.) I think all of the above should be replaced by, "The authentication of certificates relies...". Then the rest makes sense.

  - Publish an update to RFC 6962 as a standards-track mechanism to
  apply verifiable logs to HTTP over TLS.
 
I don't understand this part of the work item. 6962 is not about HTTP; it's about the creation of the log, and it's how to use the log in TLS (i.e., not in an application specific way). Why would this WG reduce the scope of 6962? I think you should strike "HTTP over".

[Ballot comment]
I suspect this charter really doesn't go far enough. I can't imagine this work will be useful without providing things like revocation lists. I think that should probably be included in the initial charter. But I won't BLOCK over that issue.

[Ballot block]
Although the charter text lists work items, the charter itself does not say
what the purpose of the working group is! I think that is pretty much essential.

[Ballot comment]
Would be nice to clean up the long sentences to avoid run-on subordinate
clauses that are ambiguous. Thus...
OLD
A
cryptographically verifiable log is an append-only log of hashes of more-or-less
anything that  is structured in such a way as to provide efficiently-accessible,
cryptographically-supported evidence of correct log behaviour.
NEW
A
cryptographically verifiable log is an append-only log of hashes of more-or-less
anything.  The log is structured in such a way as to provide efficiently-accessible,
cryptographically-supported evidence of correct log behaviour.
END

---

While I don't oppose the second work item, it seems open-ended and vague. How
will we know when this work item is done (in order to close the WG)?

[Ballot comment]
For some reason, I think the background motivation (mapping) and the main work item (cryptographic logs). Maybe I'm just slow today or it is too late, but I would have been happy with the explanation of cryptographic logs and that the working group is going to work on them. And I agree about the name with other ADs.

[Ballot comment]
I agree with Barry's suggestion to change the fabulously vague name, and it looks like that's been accepted, modulo an actual suggestion that works :-)