[cabfpub] Life after Ballot 188 - Clarify use of term "CA" in Baseline Requirements

[Ryan Sleevi]

On Thu, Mar 9, 2017 at 12:47 PM, Ben Wilson via Public <public at cabforum.org>
wrote:

> Previously Ryan raised several concerns he had regarding Ballot 188.  As
> discussed below, some of those concerns were not germane to the ballot, but
> were suggestions for future policy changes because the Working Group
> endeavored that the ballot be policy-neutral.  I am not arguing that we
> were perfect in avoiding policy changes or that Ryan didn't spot parts that
> would have changed policy, but on Monday, March 6, 2017 3:22 PM, Dimitris
> Zacharopoulos wrote:
>
> >  The items that were identified as policy changes are listed below:
> >
> >  the fact that Technically Constrained SubCAs that can respond "good"
> for unknown certificates,
> >  comes from 4.9.10. I think Mozilla and Google suggested that the ballot
> proposed a more relaxed language than the current BRs.
> >
>
> Response:  This was not a proposed policy change--it merely removed a
> double negative.  The present language says,
>
> "If the OCSP responder receives a request for status of a certificate that
> has not been issued, then the responder SHOULD NOT respond with a "good"
> status. The CA SHOULD monitor the responder for such requests as part of
> its security response procedures.   Effective 1 August 2013, OCSP
> responders for CAs which are not Technically Constrained in line with
> Section 7.1.5 MUST NOT respond with a "good" status for such certificates."
>
> Since 1 August 2013 is in the past and we've now had 3+ years for software
> to become compliant, should we just present a ballot that removes the
> exception in this last sentence--which would be a policy change?
>
> >  the exceptions for Affiliates to the Issuing CA, also come from various
> places of the BRs. Google suggested that Affiliates should be
> >  handled as externally operated Subordinate CAs. (I am not 100% if I am
> describing this correctly, but we will discuss it at the WG
> >   and the F2F and hopefully Ryan will make it clear).
> >
>
> Response:  Requiring Affiliates to be treated as externally operated
> Subordinate CAs is a change in policy.  Some CA members have acquired other
> CAs and yet preserved their separate corporate status, and therefore, there
> are several places in the Baseline Requirements where Affiliates are
> treated as a single group.  Maybe the best approach, which I think the
> Policy Review Working Group will undertake, is to prepare an
> outline/overview of potential changes to policy that will clarify (in
> advance of any ballot) the various situations in which Affiliates,
> Externally Operated CAs, Enterprise RAs, Delegated Third Parties, and other
> similarly situated entities must comply with provisions of the Baseline
> Requirements such as:  key generation, audit, CA certificate profile,
> Subscriber Agreements vs. Terms of Use, Reliable Data Sources, etc.
>
> >  For 6.1.1.1, Google suggested that we should always require the auditor
> to attest that any Key Pairs, for any CA Certificate,
> >  be accompanied with a Qualified Auditor attesting that the CA followed
> its Key Generation Script.
> >
>
> Response:  Currently the Baseline Requirements do not require that an
> auditor witness every single key pair generation.  At the risk of
> soliciting an antitrust violation, does the Forum want to make a dramatic
> change in policy and require that its WebTrust/ETSI auditor attend every
> key generation event?
>

It sounds like you're attempting to shutdown discussion of policy changes?
I'm not sure what makes this special, other than Relying Parties should
have reasonable assurance of the key materials.

Dimitris' summary was not correct here, and apologies that I was unable to
join the call this morning. I look forward to discussing this matter more
at our F2F, which I suspect can be quite productive and help clear whatever
misunderstandings may have arisen, and why the description I provided was
highlighting how 188 represented an (apparently unintentional) policy
change, rather than suggesting policy changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170309/44848812/attachment-0003.html>