<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 1/3/2017 12:47 πμ, Ryan Sleevi
      wrote:<br>
    </div>
    <blockquote
cite="mid:CACvaWvYW6x3h59fMEF8uCVYvpRh7nhTMEqXH3s33-CKqRhqDAA@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi Dimitris,
        <div><br>
        </div>
        <div>Unfortunately, it doesn't sound like we're on the same
          page. While I appreciate the effort you and Ben and others
          have worked on this, I think this proposal creates new
          security vulnerabilities in both ambiguity and loopholes.</div>
      </div>
    </blockquote>
    <br>
    Nobody can claim that we didn't try to get on the same page :) I
    also (and surely other members) appreciate your efforts to make sure
    the policies and standards are secure and unambiguous and your
    opinion is always important and respected.<br>
    <br>
    <blockquote
cite="mid:CACvaWvYW6x3h59fMEF8uCVYvpRh7nhTMEqXH3s33-CKqRhqDAA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>My request would be that you consider withdrawing the
          ballot or that members who support this change to No, so that
          it can be worked on in the policy group to resolve these
          issues. I would suggest that given the issues are, in part I
          suspect, due to misunderstandings about the concerns/threats,
          it might be best to table this until after the F2F.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    I can't imagine that Mozilla, Entrust, Globalsign, Digicert (that
    already voted "Yes") didn't read through the ballot and didn't
    consider these misunderstandings. As I've heard people say in this
    Forum, perfect is the enemy of good. In my previous replies, I tried
    to engage more members who feel that the current language of the
    ballot creates more ambiguities than it fixes. Judging from the
    silence from other members, I believe that the benefits outweigh the
    downsides creating an "acceptable" ballot, which could very well be
    improved very soon. In fact, it would be great if you could offer
    some edits to the ballot to make it even clearer. The intentions of
    the changes introduced by the WG have been clear and the main
    concern you raised (audits for all Subordinate CAs) are covered by a
    BRs part which remains untouched (the first paragraph of Section
    8.1). If we could proceed with an updated ballot (with fewer changes
    so we can address the specific concerns you still believe to exist)
    right after the F2F, there is no risk.<br>
    <br>
    Even though HARICA proposed the ballot, it was a WG effort so I
    cannot take full responsibility of withdrawing the ballot or
    suggesting members to vote "No" without any feedback from other
    endorsers or other members who I would like to reply to this, and
    offer their opinion, especially if they feel that the ballot must be
    withdrawn. As this is a public discussion, every voting member can
    judge on their own for what's best, after reading this thread.<br>
    <br>
    You also referred to Peter's email
    (<a class="moz-txt-link-freetext" href="https://cabforum.org/pipermail/policyreview/2016-November/000358.html">https://cabforum.org/pipermail/policyreview/2016-November/000358.html</a>).
    Peter participated in some WG meetings after this e-mail and we
    discussed this and so many other variations. They all had some pros
    and cons, so we ended up with the proposed language on this ballot.<br>
    <br>
    <br>
    Best regards,<br>
    Dimitris.<br>
    <br>
    <br>
    <blockquote
cite="mid:CACvaWvYW6x3h59fMEF8uCVYvpRh7nhTMEqXH3s33-CKqRhqDAA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>For example, your response regarding audits is demonstrably
          incorrect - and though I believe it emerges from a
          misunderstanding of effect, even though we share the common
          goal - and that alone is reason for serious concern.</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Tue, Feb 28, 2017 at 2:09 AM,
          Dimitris Zacharopoulos <span dir="ltr"><<a
              moz-do-not-send="true" href="mailto:jimmy@it.auth.gr"
              target="_blank">jimmy@it.auth.gr</a>></span> wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">
              <div class="m_302437843593208024moz-cite-prefix">On
                27/2/2017 9:21 μμ, Ryan Sleevi wrote:<br>
              </div>
              <blockquote type="cite">
                <div dir="ltr"><br>
                  <div class="gmail_extra"><br>
                    <div class="gmail_quote">On Mon, Feb 27, 2017 at
                      10:52 AM, Dimitris Zacharopoulos <span dir="ltr"><<a
                          moz-do-not-send="true"
                          href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>></span>
                      wrote:<br>
                      <blockquote class="gmail_quote" style="margin:0px
                        0px 0px 0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex">
                        <div bgcolor="#FFFFFF">
                          <blockquote type="cite">
                            <div dir="ltr">
                              <div>
                                <div class="gmail_extra">
                                  <div class="gmail_quote">
                                    <blockquote class="gmail_quote"
                                      style="margin:0px 0px 0px
                                      0.8ex;border-left:1px solid
                                      rgb(204,204,204);padding-left:1ex"><br>
                                    </blockquote>
                                    <div><br>
                                    </div>
                                    <div>I think this is a potentially
                                      problematic definition, in that it
                                      relates to the scope of the
                                      operations of the audit, as well
                                      as matters below that I highlight.
                                      I'm hoping the proposers and
                                      drafters can clarify (or link to
                                      previous discussions) as to the
                                      reason in which "or its Affiliate"
                                      was introduced into these
                                      definitions, or to highlight where
                                      it was already a natural and
                                      existing part of these
                                      definitions.<br>
                                    </div>
                                  </div>
                                </div>
                              </div>
                            </div>
                          </blockquote>
                          <br>
                          Peter already provided some clarity for this.
                          The "Affiliate" language was not introduced by
                          this ballot. It was already mentioned in
                          several sections of the BRs (6.1.1.1 "CA Key
                          Pair Generation", 6.1.2 "Private Key Delivery
                          to Subscriber", 6.2.6 "Private Key Transfer
                          into or from a Cryptographic Module", 7.1.2.2
                          "Subordinate CA Certificate" and  7.1.6.3
                          "Subordinate CA Certificates").<br>
                        </div>
                      </blockquote>
                      <div><br>
                      </div>
                      <div>Unfortunately, I think the concern still
                        remains that this is a subtle introduction that
                        goes from being scoped to specific sections (as
                        you've noted) to now being a foundational
                        concept, which unfortunately 'weakens' the BRs,
                        I believe.</div>
                      <div><br>
                      </div>
                      <div>I totally understand and appreciate the
                        intent to align here, especially for the cases
                        Peter noted, but I want to especially make sure
                        to highlight the issue that "or the Affiliate"
                        can be problematic from a set of scope of
                        audits.</div>
                      <div><br>
                      </div>
                      <div>Basically, what's being asked for on this
                        ballot is a trade-off from being logically
                        bugged (and I agree, this is an issue we should
                        fix) to something that is procedurally weaker,
                        and I'm trying to figure out what the plan is to
                        align. From both you and Peter's response, it
                        sounds like you don't believe further changes
                        are needed, and this is concerning.</div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              As far as this ballot is concerned, which is only to
              clarify the use of the term "CA", it does not "weaken" the
              BRs in any way. The use of the term "Affiliate" and policy
              around it, is already there. I personally (and maybe
              others) feel that the "Affiliate" issue needs to be
              further discussed and even be removed as a way of
              providing better conditions but this is something outside
              the scope of this ballot.<br>
              <br>
              <blockquote type="cite">
                <div dir="ltr">
                  <div class="gmail_extra">
                    <div class="gmail_quote">
                      <div> </div>
                      <blockquote class="gmail_quote" style="margin:0px
                        0px 0px 0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex">
                        <div bgcolor="#FFFFFF"> Peter's answer should
                          cover this. Your follow-up questions challenge
                          the fact that the current BRs treat Root
                          Operator's "Affiliates" in a different way
                          than the non-Affiliates but this is a policy
                          matter and should be discussed separately. In
                          any case, I don't think it changes the fact
                          that all Subordinate CAs (whether internally
                          or externally operated) need to be audited. In
                          the case of Internally Operated Subordinate
                          CAs, the audit might be covered in the Root
                          Operator audit, and this information should be
                          included in the audit scope.<br>
                        </div>
                      </blockquote>
                      <div><br>
                      </div>
                      <div>That's the intent - but my question is, where
                        is it specified? I may have missed that, and
                        that was the point of raising these concerns: if
                        I'm misreading, and it's already addressed,
                        fantastic. But I don't believe it is, hence the
                        concern :)</div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              8.1: "Certificates that are capable of being used to issue
              new certificates MUST either be Technically Constrained in
              line with section 7.1.5 and audited in line with section
              8.7 only, or Unconstrained and fully audited in line with
              all remaining requirements from this section". IMO, from
              this reading, it is clear that all Subordinate CAs MUST be
              fully audited or self-audited (per 8.7) if they use
              Technically Constrained Subordinate CA Certificates. There
              is no distinction about whether the Subordinate CA is
              "Internal" or "External".<br>
              <br>
              "Affiliates" in the current BRs have different policy in
              the following:<br>
              <ul>
                <li>The key generation ceremony SHOULD (instead of MUST)
                  be witnessed by an external auditor (6.1.1.1)<br>
                </li>
                <li>The Policy Identifier MAY (instead of MUST) be
                  present in the Subordinate CA Certificate and the
                  "anyPolicy" identifier MAY (instead of MUST NOT) be
                  used. (7.1.6.3).<br>
                </li>
              </ul>
              I believe that's all there is to it.<br>
              <br>
              <blockquote type="cite">
                <div dir="ltr">
                  <div class="gmail_extra">
                    <div class="gmail_quote">
                      <div> </div>
                      <blockquote class="gmail_quote" style="margin:0px
                        0px 0px 0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex">
                        <div bgcolor="#FFFFFF"> After several
                          discussions within the WG, it was agreed that
                          the most accurate technical language is that
                          "Private Keys sign Certificates".
                          Certificates, don't sign Certificates. </div>
                      </blockquote>
                      <div><br>
                      </div>
                      <div>I understand the "why". I'm more specifically
                        asking three questions:</div>
                      <div>1) Is my interpretation correct?</div>
                      <div>2) Is this desired?</div>
                      <div>3) Is there a plan to fix it?</div>
                      <div><br>
                      </div>
                      <div>From the rest of this section, I can
                        interpret your response as "1) Yes 2) No, not
                        necessarily 3) Not really, but we could come up
                        with one". I'm not sure if that really provides
                        the level of assurance when considering whether
                        to vote on this ballot, even though I agree and
                        understand the why, and am relieved it isn't
                        intended.</div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              Your interpretation for 1) is correct regarding the
              specific OCSP responder question.<br>
              <br>
              For 2), the WG's desire was to use technically correct
              language in the entire BRs to describe the "signing"
              process. You had a very specific concern about the OCSP
              responder where RFC 6960 allows either the name of the
              responder of a hash of the responder's public key as the
              ResponderID so even that is taken care of. However, if
              this concern remains, we will move to fixing it.<br>
              <br>
              For 3), if this concern remains, we will fix it. I would
              like to ask if more members have the same concern, to
              please speak up.<br>
              <br>
              <blockquote type="cite">
                <div dir="ltr">
                  <div class="gmail_extra">
                    <div class="gmail_quote">
                      <div> </div>
                      <blockquote class="gmail_quote" style="margin:0px
                        0px 0px 0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex">
                        <div bgcolor="#FFFFFF">So, according to your
                          example, if the ResponderID was the hash of
                          the Subordinate CA Certificate's public key,
                          it would not be prohibited even though that
                          key would be included in two or more
                          Subordinate CA Certificates. Perhaps the
                          multiple CA Certificates with the same
                          key-pair scenario is not entirely addressed.
                          We could update the BRs to specifically
                          include language for the ResponderID
                          information, if you think people would be
                          puzzled about what information should be
                          included in that field.<br>
                        </div>
                      </blockquote>
                      <div><br>
                      </div>
                      <div>Whether we address this by specifying
                        language fro the ResponderID (which seems overly
                        specific) or by addressing the general concern,
                        I'd like to see a concrete proposal to address
                        this, ideally before voting concludes.</div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              So far, the WG thought that the phrase "signed by the
              Private Key associated with a Root CA Certificate or a
              Subordinate CA Certificate" was technically correct and
              enough to clearly demonstrate a link between a Private Key
              and a Specific CA Certificate. If the corresponding public
              key to that private key is included in another Subordinate
              CA Certificate, it only adds policy requirements around
              that private key.<br>
              <br>
              Put differently, if a Private Key is associated with
              Certificate "SubCA1" which is operated by "SubCA1 org" and
              for some reason the same private key is associated with
              Certificate "SubCA2" which is operated by "SubCA2 org", we
              need to determine what obligations exist for the handling
              of that Private Key for its entire lifecycle and usage,
              which is the superset of SubCA1 and SubCA2. If the
              requirements surrounding SubCA1 and SubCA1 org are
              "requirements A" and the requirements surrounding SubCA2
              and SubCA2 org are "requirements B", then the Private Key
              must meet requirements A+B.<br>
              <br>
              <blockquote type="cite">
                <div dir="ltr">
                  <div class="gmail_extra">
                    <div class="gmail_quote">
                      <div> </div>
                      <blockquote class="gmail_quote" style="margin:0px
                        0px 0px 0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex">
                        <div bgcolor="#FFFFFF">
                          <blockquote type="cite">
                            <div dir="ltr">
                              <div>
                                <div class="gmail_extra">
                                  <div class="gmail_quote">
                                    <blockquote class="gmail_quote"
                                      style="margin:0px 0px 0px
                                      0.8ex;border-left:1px solid
                                      rgb(204,204,204);padding-left:1ex">
                                      In Section 4.9.10 (On-line
                                      revocation checking requirements)<br>
                                      <br>
                                    </blockquote>
                                    <div><br>
                                    </div>
                                    <div>Was this intentional?</div>
                                  </div>
                                </div>
                              </div>
                            </div>
                          </blockquote>
                          <br>
                          This specific change was addressed during the
                          discussion phase (<a moz-do-not-send="true"
class="m_302437843593208024gmail-m_-4091516754384310756moz-txt-link-freetext"
href="https://www.mail-archive.com/public@cabforum.org/msg02652.html"
                            target="_blank">https://www.mail-archive.com/<wbr>public@cabforum.org/msg02652.h<wbr>tml</a>).<br>
                        </div>
                      </blockquote>
                      <div><br>
                      </div>
                      <div>Did you link to the right thread? I cannot
                        find a clear answer, but perhaps I'm just
                        missing it. As it stands, I think this alone is
                        potentially grounds that we may need to vote
                        against it, because it's a clear reduction in
                        assurance.<br>
                      </div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              The link is from a thread started by Ben. Unfortunately, I
              couldn't find it in the mail-archive so it is pasted here:<br>
              <br>
              --- BEGIN QUOTE---<br>
              -------- Forwarded Message --------<br>
              Subject:     [cabfpub] Policy Review Working Group's
              Pre-Ballot to Clarify Use of "CA"<br>
              Date:     Thu, 19 Jan 2017 16:44:46 +0000<br>
              From:     Ben Wilson via Public <a moz-do-not-send="true"
                class="m_302437843593208024moz-txt-link-rfc2396E"
                href="mailto:public@cabforum.org" target="_blank"><public@cabforum.org></a><br>
              Reply-To:     CA/Browser Forum Public Discussion List <a
                moz-do-not-send="true"
                class="m_302437843593208024moz-txt-link-rfc2396E"
                href="mailto:public@cabforum.org" target="_blank"><public@cabforum.org></a><br>
              To:     CABFPub <a moz-do-not-send="true"
                class="m_302437843593208024moz-txt-link-rfc2396E"
                href="mailto:public@cabforum.org" target="_blank"><public@cabforum.org></a><br>
              CC:     Ben Wilson <a moz-do-not-send="true"
                class="m_302437843593208024moz-txt-link-rfc2396E"
                href="mailto:ben.wilson@digicert.com" target="_blank"><ben.wilson@digicert.com></a><br>
              <br>
              <br>
              All,<br>
              <br>
              The Policy Review Working Group has completed its review
              of the Baseline Requirements for purposes of clarifying
              use of the term "CA" and related terminology.  Please
              review and comment on the following pre-ballot.  A
              redlined version of the Baseline Requirements is attached
              to facilitate your review and comment.  <br>
              <br>
              I did want to highlight one of the proposed changes that
              is not related to "CA" terminology.   That proposed change
              is in Section 4.9.10.  The current language is ambiguous,
              and it doesn't say what was originally intended when it
              was adopted.  The current language says, "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." 
              <br>
              <br>
              The proposed change would rephrase this sentence to say
              what was originally intended.  It would say, "OCSP
              responders for Subordinate CA Certificates that are
              Technically Constrained in accordance with Section 7.1.5
              are exempt from this prohibition on responding with a
              "good" to OCSP requests for the status for such
              certificates."<br>
              <br>
              I don't know if anyone is relying on this provision, but
              its original intent was to address concerns by users of
              legacy CA software / OCSP responder software who
              complained that they could not meet this requirement
              because their OCSP responders were built to rely only on
              CRLs.<br>
              <br>
              If this proposed change presents a problem for anybody, it
              will be removed from this ballot and put into its own
              separate ballot.<br>
              <br>
              <br>
              Thanks,<br>
              Ben<br>
              --- END QUOTE---<br>
              <br>
              Gerv replied on January 25th that he agrees with the
              proposed change on 7.1.5 which basically clears the
              language. It doesn't reduce the assurance. The assurance
              is already "reduced" in the current BRs. Here is the
              current language in 4.9.10:<br>
              <br>
              "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".<br>
              <br>
              The new proposed language says exactly the same thing but
              in a more clear way. So, again, the ballot does not
              propose policy changes (although as we said a couple of
              times, the WG was very tempted to propose policy changes
              to make things better).<br>
              <br>
              <br>
              <blockquote type="cite">
                <div dir="ltr">
                  <div class="gmail_extra">
                    <div class="gmail_quote">
                      <div> </div>
                      <blockquote class="gmail_quote" style="margin:0px
                        0px 0px 0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex">
                        <div bgcolor="#FFFFFF"> A typo indeed. It is
                          clear in the red-lined version.<br>
                        </div>
                      </blockquote>
                      <div><br>
                      </div>
                      <div>For future reference, we should try to figure
                        out what version is being voted on, when the
                        e-mailed ballot and Red Line disagree :) This is
                        a minor issue, but I can easily see more
                        significant issues creeping in, least of all,
                        because I have not looked at all at the Red
                        Lined version, because that's not the balloted
                        text :)</div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              Agreed. I guess once we become more familiar with a github
              process, we will use one version over another as
              authoritative for ballots (most probably the github
              version).<br>
              <br>
              <blockquote type="cite">
                <div dir="ltr">
                  <div class="gmail_extra">
                    <div class="gmail_quote">
                      <div> </div>
                      <blockquote class="gmail_quote" style="margin:0px
                        0px 0px 0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex">
                        <div bgcolor="#FFFFFF">
                          <blockquote type="cite">
                            <div dir="ltr">
                              <div>
                                <div class="gmail_extra">
                                  <div class="gmail_quote">
                                    <blockquote class="gmail_quote"
                                      style="margin:0px 0px 0px
                                      0.8ex;border-left:1px solid
                                      rgb(204,204,204);padding-left:1ex">
                                      In Section 8.7 (Self-Audits)<br>
                                      <br>
                                      <br>
                                      Replace the last paragraph with:<br>
                                      <br>
                                      During the period in which a
                                      Technically Constrained Externally
                                      Operated Subordinate CA issues
                                      Certificates, the Issuing CA SHALL
                                      monitor adherence to the Issuing
                                      CA's Certificate Policy and/or
                                      Certification Practice Statement
                                      and the Externally Operated
                                      Subordinate CA's Certificate
                                      Policy and/or Certification
                                      Practice Statement. On at least a
                                      quarterly basis, against a
                                      randomly selected sample of the
                                      greater of one certificate or at
                                      least three percent of the
                                      Certificates issued by the
                                      Externally Operated Subordinate
                                      CA, during the period commencing
                                      immediately after the previous
                                      audit sample was taken, the CA
                                      SHALL ensure adherence to all
                                      applicable Certificate Policies
                                      and/or Certification Practice
                                      Statements.<br>
                                    </blockquote>
                                    <div><br>
                                    </div>
                                    <div>Much like several other changes
                                      mentioned above, this limits the
                                      scope of the existing text from
                                      "internal or external" to simply
                                      "external". Thus it reduces the
                                      scope of examination for
                                      internally operated subordinate CA
                                      certificates, which may be
                                      operated by an Afilliate under a
                                      distinct CP/CPS. Is that fair to
                                      say?</div>
                                  </div>
                                </div>
                              </div>
                            </div>
                          </blockquote>
                          <br>
                          The rest of the section remains the same. It
                          doesn't remove the obligation for the CA (this
                          covers ALL CA organizations, including
                          affiliates) to perform quarterly self-audits.<br>
                          <br>
                          The reasoning for changing the last paragraph
                          to only "Externally Operated Subordinate CAs",
                          was that the language dictates that the
                          "Issuing CA SHALL monitor adherence...". We
                          thought that it doesn't make sense to have one
                          organization monitor adherence to it's own
                          organization. It is already required for the
                          Root CA Operator to adhere to its own CP
                          and/or CPS (that must cover all Internally
                          Operated Subordinate CAs), check against a
                          randomly selected sample, etc, as specified in
                          the first paragraph of section 8.7.<br>
                        </div>
                      </blockquote>
                      <div><br>
                      </div>
                      <div>So I think the point you're making is
                        important, and I'm not cleared where it's
                        technically spelled out or required, and do hope
                        you can highlight this.</div>
                      <div><br>
                      </div>
                      <div>You're asserting that all Internally Operated
                        Subordinate CAs are operated by the Root
                        Operator AND, if I'm understanding correctly,
                        audited to the same CP/CPS as the Root CA
                        Certificate - is this correct?</div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              No. I am saying that it could be, under some
              circumstances. For example, if a Root Operator has an
              internal department (under the same Management) that
              handle issuances under a specific Subordinate CA
              Certificate, then this Internally Operated Subordinate CA
              could be covered in the audit of the Root Operator. If
              we're talking about two separate legal entities under
              different Management, then a separate audit report is
              needed according to Section 8.1.<br>
              <br>
              <blockquote type="cite">
                <div dir="ltr">
                  <div class="gmail_extra">
                    <div class="gmail_quote">
                      <div><br>
                      </div>
                      <div>I haven't found text to normatively require
                        either statement, and that's the concern: even
                        if it's the same organization as the Root
                        Operator, the possibility for distinct CP/CPSes
                        to exist between the Root CA Certificate's
                        policies and the Internally Operated Subordinate
                        CA's policies (and/or independent audits)
                        exists, and as much as possible, I want to
                        ensure the same consistent duty of care with
                        respect to policies and practices. I fear this
                        introduces a loophole for Affiliates to 'skip'
                        audits and key protection, even if unintended,
                        so I'm curious if we can find a resolution for
                        this within the voting period.</div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              The requirement for all Subordinate CAs to be audited
              comes from the first paragraph of Section 8.1, as stated
              above. It leaves no room for interpretations and includes
              ALL Subordinate CAs, Internal or External.<br>
              <br>
              <blockquote type="cite">
                <div dir="ltr">
                  <div class="gmail_extra">
                    <div class="gmail_quote">
                      <div> </div>
                      <blockquote class="gmail_quote" style="margin:0px
                        0px 0px 0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex">
                        <div bgcolor="#FFFFFF"><br>
                          Here are the two definitions introduced:<br>
                          <br>
                          <b><span lang="EN-US">Root CA Operator:</span></b><span
                            lang="EN-US"><span>  </span></span><span
                            lang="EN-US">The top-level Certification
                            Authority (i.e. an organization) whose CA
                            Certificate (or associated Public Key) is
                            distributed by Application Software
                            Suppliers as a trust anchor<br>
                          </span><br>
                          <b><span lang="EN-US">Internally Operated
                              Subordinate CA:</span></b><span
                            lang="EN-US"> <span> </span>A Subordinate
                            CA Operator, operated by a Root CA Operator
                            or its Affiliate that is in possession or
                            control of the Private Key associated with
                            the Subordinate CA Certificate</span> <br>
                          <br>
                          The Root CA Operator is already -by
                          definition- responsible for all actions
                          related to its Internally Operated Subordinate
                          CAs and Affiliates.</div>
                      </blockquote>
                      <div><br>
                      </div>
                      <div>I disagree, and that's the point of concern.
                        If the Root CA Operator included the definition
                        of Affiliates - ergo bringing consistency to the
                        scope of audits and operation - then perhaps
                        this issue would be resolved (of course, it may
                        introduce new bugs). But as it stands, an
                        Internally Operated Sub CA having the "or its
                        Affiliate" creates a loophole in which all the
                        policies which apply to a Root CA Operator
                        _don't_ apply to the Affiliate, because IOSCAs
                        clearly distinguish Affiliate as "something
                        other than the Root CA Operator"</div>
                      <div><br>
                      </div>
                      <div>Does this make sense?</div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              I believe it is the opposite. To the best of my knowledge
              and understanding (and I hope members can correct me if
              I'm wrong), IOSCAs are treated as "something as the Root
              CA Operator". That's already captured in the BRs today.<br>
              <br>
              <blockquote type="cite">
                <div dir="ltr">
                  <div class="gmail_extra">
                    <div class="gmail_quote">
                      <div> </div>
                      <blockquote class="gmail_quote" style="margin:0px
                        0px 0px 0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex">
                        <div bgcolor="#FFFFFF"> Voting ends on Thursday
                          March 2 at 22:00 UTC but the remaining issues
                          will be tracked and addressed in a future
                          ballot.<br>
                        </div>
                      </blockquote>
                      <div><br>
                      </div>
                      <div>My hope is something a bit more concrete than
                        future ballot before then, because I think some
                        of these concerns are enough to prevent our
                        support </div>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              The voting ends tomorrow and I hope to have addressed some
              or all your concerns. Ben and Tim (and even Peter who
              attended several of the WG meetings) are welcome to add
              any comments to help addressing these concerns even
              further. I also encourage other members with the same or
              similar concerns who feel they are not properly addressed,
              to speak up so we can decide if we must proceed with
              amendments. Unfortunately, at the stage we are at, the
              ballot cannot be withdrawn so it can either pass or fail.
              Overall, the ballot has significant language improvements
              -as many have already stated- and it would be nice to have
              every member's support. Policy problems that pre-existed
              the ballot, still remain but that was left untouched on
              purpose, so we could proceed with policy improvements
              after we had a consistent language and definitions
              throughout the BRs.<br>
              <br>
              <br>
              Best regards,<br>
              Dimitris.<br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>