[cabfpub] Potential F2F Topics

Ryan Sleevi sleevi at google.com
Tue Oct 11 09:43:15 MST 2016


While I understand the IETF doesn't work on policy, I meant to suggest that
the most important aspect - which absolutely belongs in the IETF - is use
cases.

I do not believe we can have a meaningful discussion of policy without
understanding use cases. It's clear that the technical solutions explored
in the IETF are also at an impasse, again, due to use cases.

My view is that for the CA/B Forum to discuss policy solutions to the
problems, it's an absolute requirement that those proponents of redaction
express their use cases in the IETF, and, if it's more than simply
Symantec, that those CAs express their support for such use cases. Further,
I would argue it's important to ensure that those customers of CAs -
whether Symantec or otherwise - be engaged and willing to participate in
the IETF to discuss their use cases.

Then, and only then, can we have a meaningful exploration as to which use
cases can be solved and addressed via technical means (via the IETF), and
which methods require policy solutions (via the CA/Browser Forum).

I think it's placing the cart very much before the horse to engage in a
discussion in the Forum about policy solutions to problems that are neither
well understood nor articulated in the IETF.

On Mon, Oct 10, 2016 at 3:01 PM, Peter Bowen <pzb at amzn.com> wrote:

> 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.
>
> Thanks,
> Peter
>
> > 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
> > https://cabforum.org/mailman/listinfo/public
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20161011/6824aabb/attachment-0001.html>


More information about the Public mailing list