<div dir="ltr">I would actually like to avoid that being a topic for the CA/Browser Forum, in as much as it will continue to amplify the problem we have - of parties suggesting a need for redaction, but not working within the IETF to ensure their needs are properly specified or met.<div><br></div><div>That said, I anticipate there to be a significant and lively discussion related to CT during the browser update, of which redaction will no doubt come up, so perhaps it would be best to simply treat it as part of that discussion, and with any sizable or significant contributions channeled towards the IETF, rather than the somewhat insular Forum. This is especially true as we work through the IPR obligations.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 10, 2016 at 2:30 PM, Rob Stradling via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are there still any slots to fill?  I think it would be good to discuss<br>
the way forward (if indeed there is one!) for CT domain redaction.<br>
<span class="im HOEnZb"><br>
On 01/10/16 17:00, Peter Bowen wrote:<br>
</span><span class="im HOEnZb">> I haven’t seen much recent activity on topics for the F2F.  It looks like we still have most of the second day with placeholders to be filled in.<br>
><br>
> I would like to suggest two topics:<br>
><br>
> 1) Non-FIPS algorithms for customer public keys and certificate signing<br>
><br>
> The Baseline Requirements current primarily use the Federal Information Processing Standards (FIPS) published by the United States National Institute of Standards and Technology as a reference for hash and digital signature algorithms.  A number of groups are doing work on new algorithms that are not likely to be memorialized in a FIPS or will take a very long time to do so.  These include EdDSA (including Ed25519 and Ed448) from Dan Bernstein and the IRTF/IETF, SM2 & SM3 from the China Office of State Commercial Cryptography Administration, GOST R 34.10-2012 from the Euroasian Interstate Council for Standardization, Metrology and Certification, and ECGDSA from Germany, and ECKCDSA from Korea.  Additionally there are “Post-Quantum” algorithms coming down the pipeline that will arrive at some future point.<br>
><br>
> How do we want to handle these?  What requirements should be in place before we added these to the BRs and allow CAs start to utilize these?<br>
><br>
><br>
> 2) Network and Certificate Systems Security Requirements<br>
><br>
> The Network and Certificate Systems Security Requirements (NCSSR) were discussed at the last F2F but it was kind of dropped.  What challenges are CAs finding?  Are there places where they are not clear or where they can be interpreted to ban practices the Forum feels are appropriate?  As they are a separate document from the BRs, do trust store maintainers expect that all CAs (whether for SSL or not) are audited as meeting the requirements or do they only apply to “SSL” CAs?<br>
><br>
> Ideally members would send data on their experiences ahead of time so we can have a productive discussion.<br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Rob Stradling<br>
Senior Research & Development Scientist<br>
COMODO - Creating Trust Online<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
</div></div></blockquote></div><br></div>