<div dir="ltr">I've added some edits to make it align more closely with the discussion and correct a couple of items. <div><br><div>I think it should go out from the OMC as a whole - which does mean that everyone should view it - and if we are sending as OMC then it should be on the basis of a vote (so we are not placing words in the mouths of people who haven't read and approved the wording). </div><div><br></div><div>I also wouldn't have sent the draft blog post to the public as yet ... <br><div><br></div><div>Tim.</div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 3, 2018 at 6:42 AM, Salz, Rich <span dir="ltr"><<a href="mailto:rsalz@akamai.com" target="_blank">rsalz@akamai.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wrote a draft blog post. If anyone on the OMC wants to edit and put their name on it, or suggest edits and I post it, that’s fine with me.<br>
<div class="HOEnZb"><div class="h5"><br>
On 1/1/18, 7:30 PM, "Paul Dale" <<a href="mailto:paul.dale@oracle.com">paul.dale@oracle.com</a>> wrote:<br>
<br>
A concurrent update for the mailing list page: <a href="https://www.openssl.org/community/mailinglists.html" rel="noreferrer" target="_blank">https://www.openssl.org/<wbr>community/mailinglists.html</a> too?<br>
<br>
Pauli<br>
--<br>
Oracle<br>
Dr Paul Dale | Cryptographer | Network Security & Encryption<br>
Phone <a href="tel:%2B61%207%203031%207217" value="+61730317217">+61 7 3031 7217</a><br>
Oracle Australia<br>
<br>
-----Original Message-----<br>
From: Richard Levitte [mailto:<a href="mailto:levitte@openssl.org">levitte@openssl.org</a>]<br>
Sent: Saturday, 23 December 2017 12:48 AM<br>
To: <a href="mailto:openssl-project@openssl.org">openssl-project@openssl.org</a><br>
Subject: Re: [openssl-project] As per vote, the project list is created<br>
<br>
In message <<a href="mailto:20171222105738.GA17869@roeckx.be">20171222105738.GA17869@<wbr>roeckx.be</a>> on Fri, 22 Dec 2017 11:57:38 +0100, Kurt Roeckx <<a href="mailto:kurt@roeckx.be">kurt@roeckx.be</a>> said:<br>
<br>
kurt> You should probably announce this new list more widely<br>
<br>
Agreed. Wasn't someone going to make a blog post about it? Or was that just a general "we should" where noone actually said "I will"?<br>
For if no one feels they've taken that on, I will ;-)<br>
<br>
--<br>
Richard Levitte <a href="mailto:levitte@openssl.org">levitte@openssl.org</a><br>
OpenSSL Project <a href="http://www.openssl.org/~levitte/" rel="noreferrer" target="_blank">http://www.openssl.org/~<wbr>levitte/</a><br>
______________________________<wbr>_________________<br>
openssl-project mailing list<br>
<a href="mailto:openssl-project@openssl.org">openssl-project@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-project" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-<wbr>project</a><br>
______________________________<wbr>_________________<br>
openssl-project mailing list<br>
<a href="mailto:openssl-project@openssl.org">openssl-project@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-project" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-<wbr>project</a><br>
<br>
<br>
</div></div><br><br>---------- Forwarded message ----------<br>From: Rich Salz <<a href="mailto:rsalz@openssl.org">rsalz@openssl.org</a>><br>To: <<a href="mailto:openssl-omc@openssl.org">openssl-omc@openssl.org</a>><br>Cc: <br>Bcc: <br>Date: Tue, 2 Jan 2018 20:41:12 +0000<br>Subject: [openssl-omc] [blog] master update<br>The branch master has been updated<br>
via 90a4eb9e289be237bc80dc5393d32e<wbr>79b2d7b001 (commit)<br>
from 0c536ced1e9bb1684ddf60af42e236<wbr>dd69d3dd52 (commit)<br>
<br>
<br>
- Log ------------------------------<wbr>------------------------------<wbr>-----<br>
commit 90a4eb9e289be237bc80dc5393d32e<wbr>79b2d7b001<br>
Author: Rich Salz <<a href="mailto:rsalz@akamai.com">rsalz@akamai.com</a>><br>
Date: Tue Jan 2 15:39:37 2018 -0500<br>
<br>
Draft of F2F blog post<br>
<br>
------------------------------<wbr>------------------------------<wbr>-----------<br>
<br>
Summary of changes:<br>
source/_posts/2018-01-04-f2f-<wbr>email-etc.markdown | 130 ++++++++++++++++++++++++<br>
1 file changed, 130 insertions(+)<br>
create mode 100644 source/_posts/2018-01-04-f2f-<wbr>email-etc.markdown<br>
<br>
diff --git a/source/_posts/2018-01-04-<wbr>f2f-email-etc.markdown b/source/_posts/2018-01-04-<wbr>f2f-email-etc.markdown<br>
new file mode 100644<br>
index 0000000..c62a133<br>
--- /dev/null<br>
+++ b/source/_posts/2018-01-04-<wbr>f2f-email-etc.markdown<br>
@@ -0,0 +1,130 @@<br>
+---<br>
+layout: post<br>
+title: "Another Face to Face: Email changes and crypto policy"<br>
+date: 2018-01-04 1:00<br>
+comments: true<br>
+author: "???"<br>
+published: false<br>
+---<br>
+<br>
+The OpenSSL OMC met last month for a two-day face-to-face meeting, and<br>
+like previous F2F meetings, most of the team was present and we got a<br>
+great deal of issues addressed. This blog posts talks about some of them,<br>
+and most of the others will get their own blog posts, or notices, later.<br>
+<br>
+One of the overall threads of the meeting was about increasing the<br>
+transparency of the project. By default, everything should be done in<br>
+public. We decided to try some major changes to email and such.<br>
+<br>
+<!-- more --><br>
+<br>
+## Security Releases<br>
+<br>
+First, a short item. We are changing our release schedule so that unless<br>
+there are extenuating circumstances, security releases will go out on<br>
+Tuesday, with the pre-notification being the previous Tuesday. We don't see<br>
+a need to have people ready to sacrifice their weekend every time a new CVE<br>
+comes out (see our<br>
+<a href="<a href="https://www.openssl.org/policies/secpolicy.html" rel="noreferrer" target="_blank">https://www.openssl.org/<wbr>policies/secpolicy.html</a>"><wbr>security policy</a><br>
+for details).<br>
+<br>
+On the other hand, a Heartbleed-style vulnerability that has known exploits<br>
+would a good example of an extenuating circumstance.<br>
+<br>
+## Online communication<br>
+<br>
+We created a new mailing list,<br>
+<a href="<a href="https://mta.openssl.org/mailman/listinfo/openssl-project" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-<wbr>project</a>">openssl-project</a>,<br>
+that is for discussions about the governance and policies of OpenSSL.<br>
+Anyone can join this list. Initially, only members of the OMC and committers<br>
+will be able to post; everyone else will be moderated.<br>
+At first glance, this seems to go against our goal of more transparency.<br>
+We want this to be a useful list for the project members to communicate in<br>
+public -- like many Parliaments, for example, where debate is public but the<br>
+public doesn't speak.<br>
+<br>
+Still, not everyone is completely comfortable with this, and some have said<br>
+that they will basically approve any posting held for moderation.<br>
+It's an experiment, and if we can open the list for public posting, without<br>
+getting drowned out, we'll do so. Note that all OMC vote results will be<br>
+posted here, as will initial discussions about vote topics. One important item<br>
+that will be discussed on this list is planning for upcoming releases.<br>
+Also, our paid fellows will be posting monthly status reports there.<br>
+<br>
+We decided to increase our use of GitHub. In addition to asking that all<br>
+bug reports and enhancement requests be reported as issues, we now want all<br>
+major code proposals to be discussed as issues before a large pull request<br>
+shows up. This will let the community discuss the feature, offer input on<br>
+design and such, before having code to look at. We hope this will let us<br>
+all first look at the bigger picture, before getting bogged down in the<br>
+weeds of line-by-line code reviews.<br>
+<br>
+We are going to close the openssl-dev mailing list. The distinction between<br>
+openssl-dev and openssl-users was often unclear, and the changes described<br>
+above will make that situation worse. GitHub issues are the way<br>
+most projects work these days, and with the creation of openssl-project it<br>
+should be much more clear how and when to use the openssl-users mailing<br>
+list.<br>
+<br>
+If our expectations are wrong, of course, we'll fix or revert these<br>
+changes.<br>
+<br>
+## Cryptography Policies<br>
+<br>
+Part of our discussions were about our mission.<br>
+<br>
+- What security properties are we trying to provide our users?<br>
+- Do we see ourselves as responsbile for keeping the ecosystem secure?<br>
+- Are we a TLS toolkit or a "it's all there" crypto toolkit?<br>
+- And so on...<br>
+<br>
+While discussing these questions, we came up with a few policy decisions.<br>
+These apply to all new cryptography, and in a future release we will address<br>
+the existing source.<br>
+<br>
+- Insecure configuration options will not be enabled by default but must<br>
+be enabled by a compile-time switch. We had already started to do this by<br>
+disabling SSLv2 and small keys. A recent change is that "multi-prime RSA"<br>
+will enforce a maximum number of prime factors by default. In the future,<br>
+it's possible we'll increase the minimum key sizes for a variety of algorithms.<br>
+<br>
+- It must be possible to disable all new algorithms at compile-time.<br>
+When we extend that existing code, we'll probably skip cases that are known<br>
+to not work. Building OpenSSL without SHA will break libssl, so it's not worth<br>
+spending time on that.<br>
+<br>
+- The EVP interface is the primary interface for calling crypto operations.<br>
+All new algorithms should only provide this API.<br>
+In a future release, existing API's like ``AES_encrypt`` will be provided<br>
+with a compatibility layer, perhaps separately, that wraps the EVP API.<br>
+<br>
+- All algorithms and protocols should be recognized by a national or<br>
+international standards body. That is somewhat vague, but the important<br>
+point is that we are implementors, not cryptographers, and will defer<br>
+judgement to experts.<br>
+<br>
+- The DEFAULT value for the cipher string is not the same as ALL.<br>
+That is, while many ciphers will be available to the libraries, they will<br>
+not be enabled at the TLS layer unless specified at run-time.<br>
+This brought up the point that the syntax of the cipher string cannot<br>
+support the things people need it to do, including "cipher classes,"<br>
+custom keywords, and site-wide configurations.<br>
+<br>
+## Roadmap<br>
+<br>
+We remain committed to having TLS 1.3 be the main feature for our next<br>
+release. Of course we must wait for the IETF to finish it. We'll again<br>
+point out that this is version 1.1.1, and you should get your applications<br>
+ready by porting to 1.1.0 now.<br>
+<br>
+We reviewed the status of our license-change work. We'll post an update in<br>
+a couple of weeks, but our goal is to change the license with this next<br>
+release.<br>
+<br>
+We also decided that the primary focus of the next feature release will be<br>
+FIPS. We know that FIPS is very important to some, not all, members of our<br>
+community and we are committed to addressing this. We don't have much more<br>
+information to share, and we know there has been some confusion and<br>
+misleading communication out there. But we do want to make this strong,<br>
+definitive statement: OpenSSL will implement a FIPS solution, and we expect<br>
+it will be much faster than previous timetables.<br>
<br>
<br>______________________________<wbr>_________________<br>
openssl-project mailing list<br>
<a href="mailto:openssl-project@openssl.org">openssl-project@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-project" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-<wbr>project</a><br></blockquote></div><br></div>