[cabfpub] [EXTERNAL]Re: Draft Agenda for Thursday May 25 CABF Teleconference

[Ryan Sleevi]

Hi Bruce,

There's a whole host of problems that are all so deeply related that they
cannot be easily disentangled.

Note: I introduced the topic in
https://cabforum.org/pipermail/public/2017-April/010730.html with the
goals. Many of the specific changes - the problem statements - are on the
GitHub link, on line-by-line annotations explaining the reasoning and
subsequent discussion.

For the purposes of further discussion:

* The profile of OCSP that exists (e.g. responder lifetime) is inconsistent
with those of browser requirements, meaning that there is an 'effective'
minimum already specified that is more than the Baseline Requirements
specify, and which every (current) member of the CA/B Forum is already held
to
* CAs' deployment of OCSP, today, results in characteristics that prevent
or inhibit meaningful efforts to deploy more widestream OCSP stapling
  * CAs' make use of the full profile of OCSP, which is maximally
permissive, in a way that introduces significant performance problems (e.g.
including the full response chain within the OCSP response)
  * CAs' fail to provide timely OCSP information following the issuance of
a certificate, adding an unbounded complexity to the availability of the
OCSP response itself
* CAs' deployment of OCSP, today, results in insecure practices that expose
users to unnecessary risk and undermines the trustworthiness of revocation
information
  * CAs enable the use of the nonce-extension, particularly with SHA-1,
which creates significant risk to clients if the OCSP Responder certificate
is not designed appropriately (which cannot be done in the case of
non-delegated responder)
  * CAs' delegated responder practices expose keying material to systems
outside of the scope of audit. A compromise of this keying material is to
effectively compromise revocation for the CA itself
  * CAs' OCSP response signing practices may, in some cases, make an
inappropriate risk determination on the protection of responses
(particularly pre-generated responses) that is effectively the same as a
revocation compromise

As I mentioned on the original link, CRLs equally benefit from such a
profile, and the unnecessarily complexity of some deployments - whether
non-spec-conforming deployments (e.g. non-critical
issuerDistributionPoints) or poorly optimized deployments (e.g. 1,000,000
certificates all using a single CRL) equally prevent meaningful
improvements into the revocation space.

If we are to have productive conversations about revocations, and the ways
in which they are useful to clients - and this is regardless of something
like CRLs, CRLSets, or proposals such as CRLLite - then we need to have a
consistent profile, much like we do for certificates. The GitHub discussion
attempts to set out the overall goals - where do we want to see the system
in (N time period) - and then figure out what those values of phasing in
(which doesn't necessarily need to be all at once) should be.

So I think it's important, in this discussion, to focus on the substance of
the goal, rather than notions such as timeframes or specific ballots, so we
can find some common agreement and understanding of the goals, iterate on
the means to achieve them, and then discuss the time necessary. By doing
this, we can hopefully reduce the time, by providing more positive signals
to the industry (both ISVs and CAs) about directions to consider, invest
in, and research.

On Wed, May 24, 2017 at 1:14 PM, Bruce Morton <
Bruce.Morton at entrustdatacard.com> wrote:

> Hi Ryan,
>
>
>
> I support the OCSP Responder discussion. I’m wondering if you could also
> provide a problem statement which we would like to solve. I do not see this
> information in the GitHub link.
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Monday, May 22, 2017 1:32 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Ryan Sleevi <sleevi at google.com>
> *Subject:* [EXTERNAL]Re: [cabfpub] Draft Agenda for Thursday May 25 CABF
> Teleconference
>
>
>
> Hi Kirk,
>
>
>
> I'd be interested if we could spend some time discussing l), if the
> members interested are able to make the call (Paul van Brouwershaven from
> GlobalSign if possible, Dimitris, Tim, Bruce). We spent time - both on the
> bug and the list - discussing OCSP Responder certificates and their
> validity lifetime relative to the risks. Assuming we have time, I suspect
> it might be useful to both recap some of that discussion, and bring it to
> the attention of the broader group to get feedback and thoughts on the
> goals.
>
>
>
> On Sun, May 21, 2017 at 9:03 PM, Kirk Hall via Public <public at cabforum.org>
> wrote:
>
> Here is a draft agenda for our call this Thursday, May 25.  Please offer
> edits and suggestions.
>
>
>
> 1.      Roll Call
>
> 2.      Read Antitrust Statement
>
> 3.      Review Agenda
>
> Approve Minutes of CABF teleconference of May 11, 2017 as amended
>
> 4.      Governance Change Working Group update.
>
> 5.      Validation Working Group update.
>
> 6.      Policy Review Working Group update.
>
> 7.      Charter for new Security Controls Working Group (to update
> Network Security requirements)
>
> 8.      Ballot Status (see list below)
>
> 9.      New Bylaw to resolve procedural disputes (ballot errors, voting
> issues)
>
> 10.  Next F2F meeting:
>
> June 20-22, 2017 Berlin (D-Trust) – Suggested F2F Agenda Items
>
> 11.  Any Other Business
>
> 12.  Next call June 8, 2017
>
> 13.  Adjourn
>
>
>
> ****
>
>
>
> *CURRENT STATUS OF BALLOTS (as of May 11, 2017)*
>
>
>
> *1. Ballots in Voting Period*
>
> a)      Ballot 191 – Clarify Place of Business Information (Jeremy) –
> ends May 23
>
>
>
> *2. Ballots in Discussion Period*
>
> a)      Ballot 200 – CA/Browser Forum Code of Conduct (Virginia) - ends
> May 23
>
>
>
> *3. Ballots in Review Period*
>
> a)     Ballot 197 – Effective Date of Ballot 193 Provisions - ends June 2
>
> b)     Ballot 198 – Onion Revisions  – ends June 8 - *Uncertain*
>
> c)      Ballot 199 - Require commonName in Root and Intermediate
> Certificates  – ends June 8
>
>
>
> *4. Draft Ballots*
>
> a)     Ballot 184 - RFC 822 Names and otherNames, SRV names (Jeremy)
>
> b)     Ballot 186 – Limiting reuse of validation information (Ryan)
>
> c)      Ballot 190 – BR 3.2.2.4 Validation Methods (Jeremy)
>
> d)     Ballot 191 – Clarify Place of Business Info (Jeremy)
>
> e)     Ballot 192- Notary Clarification (Jeremy)
>
> f)       Ballot 201 - .Onion Revisions (Jeremy)
>
> g)     RAs and Delegated Third Parties (Gerv)
>
> h)     Expected ASN.1 grammar for BR & EV certificates (Peter)
>
> i)       Bylaws change – Membership requirements (Gerv)
>
> j)       Bylaw change - Voting rules (Jos)
>
> k)      Requiring RFC 3647 format (Ryan)
>
> l)       Profiling OCSP & CRLs (Ryan)
>
>
> _______________________________________________
> 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/20170524/c6426cf4/attachment-0001.html>