Hi Jon,

Thanks for the feedback!  Either here or on the Google doc is fine.  If you have direct suggestions, feel free to comment them in to the Google doc so we can merge them correctly.

I’ll try to address your questions and comments here:

1.       Tiering is always going to be somewhat of a judgement call, particularly between tiers 2 and 3.  Post-quantum algorithms are a good example of this, and I think (in my opinion) some might go either way.  For instance, I would put Frodo (an LWE-based key exchange that is extremely conservative in its parameter choices and has had an open implementation for quite some time) clearly in tier 2.  On the other hand, I would put something like WalnutDSA (a braid group-based signature algorithm that has had many parameter changes over the past year) in tier 3.  It wouldn’t be unreasonable for maintainers to have disagreements on tiers for certain things, so we would have to vote on tier issues.  However, I think that most of the stuff that we will begin with should be clear.

2.       Yes, this is a good point.  I’ll make this change.

3.       Ah, the joys of UC-security.  The “theoretical maintainers” should block any pull requests that combine things in such an insecure manner, since any such mechanisms use crypto in a non-black box manner.  However, you do bring up a good point:  standardized APIs are really nice (that’s actually the goal of the base crypto-lib signature library!).  We hope to coalesce into simple APIs that are universally adopted throughout the project, but we think it will hinder development and adoption if we force people to use certain APIs at the start of the project.  Backwards compatibility with existing projects is another reason why we can’t standardize APIs completely—we would like to have an API that all of the new stuff uses, but backwards compatibility breaks the old stuff.  I guess, to summarize:  we hope that some kind of de facto API Council is formed, but we don’t want to mandate it right now because we think it might hinder adoption and development.

4.       Yes, that’s a good point.  While I’m perfectly comfortable saying that rolling your own hash functions is “incredibly foolish” and having that enshrined and public, I have replaced that phrase with “poor.”  In addition, sadly the FAQ about the dunking booth will have to go before the document is finalized…

5.       The base lib project is planning to incorporate shims to many different languages.  I think that there are many people interested in a Golang interface, so I imagine this will get built.  As the project matures, I imagine we will have more discussions about safe languages.  I think this is also why many people involved in the project are really excited about Rust.

6.       Tier 0, clearly!  ;)

I hope this cleared things up.  Let me know if you have further questions or comments.

Thanks,

Hart