[cabfpub] Potential F2F Topics
pzb at amzn.com
Mon Oct 10 22:01:47 UTC 2016
While I think the IETF is the right place for technical work on redaction, the IETF explicitly avoids work on policy.
In the realm of CT, 6962bis section 4.2 includes the option to log a name-constrained intermediate CA in place of logging end-entity certificates. There has be no move to remove this from 6962bis. Assuming this remains included in the final RFC, does that mean Chrome will treat such certificates as logged?
I agree that there should be discussion in less “insular” forums, but I also think there is value in discussion at the F2F.
> On Oct 10, 2016, at 2:32 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 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.
> 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.
> On Mon, Oct 10, 2016 at 2:30 PM, Rob Stradling via Public <public at cabforum.org> wrote:
> Are there still any slots to fill? I think it would be good to discuss
> the way forward (if indeed there is one!) for CT domain redaction.
> On 01/10/16 17:00, Peter Bowen wrote:
> > 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.
> > I would like to suggest two topics:
> > 1) Non-FIPS algorithms for customer public keys and certificate signing
> > 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.
> > 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?
> > 2) Network and Certificate Systems Security Requirements
> > 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?
> > Ideally members would send data on their experiences ahead of time so we can have a productive discussion.
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> Public mailing list
> Public at cabforum.org
More information about the Public