<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><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>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 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 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 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 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 class="m_302437843593208024moz-txt-link-rfc2396E" href="mailto:public@cabforum.org" target="_blank"><public@cabforum.org></a><br>
    To:     CABFPub <a class="m_302437843593208024moz-txt-link-rfc2396E" href="mailto:public@cabforum.org" target="_blank"><public@cabforum.org></a><br>
    CC:     Ben Wilson <a 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>