<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 18/11/2021 4:09 μ.μ., Bruce Morton
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:DM5PR11MB00419DE53956BFF1201F1D01829B9@DM5PR11MB0041.namprd11.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style>@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:DengXian;
        panose-1:2 1 6 0 3 1 1 1 1 1;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
        {font-family:"Segoe UI Emoji";
        panose-1:2 11 5 2 4 2 4 2 2 3;}@font-face
        {font-family:"\@DengXian";
        panose-1:2 1 6 0 3 1 1 1 1 1;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}div.WordSection1
        {page:WordSection1;}ol
        {margin-bottom:0in;}ul
        {margin-bottom:0in;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Hi Dimitris,<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I don’t accept that IT audit will not be
          used. The reason is that the ballot will remove software keys
          from non-EV code signing certificates. This is a new
          requirement and will impact the majority of the certificates
          and the Subscribers. In addition, there was no requirement to
          check how Subscriber keys were generated or non-EV code
          signing certificates, another new requirement.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
    </blockquote>
    <br>
    This is confusing. We had this language for EV Code Signing
    Certificates and nobody was using it. How would it be used for
    non-ev code signing certificates?<br>
    <br>
    <blockquote type="cite"
cite="mid:DM5PR11MB00419DE53956BFF1201F1D01829B9@DM5PR11MB0041.namprd11.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal">I don’t think that a CA or Qualified
          Auditor can audit a bank of HSMs in production, HA and DR
          modes for all the keys which a software developer will need
          for the next undefined period of time. They can only look at
          the past. I understand that you can ship a token with more
          than one key, but the HSM might have thousands or millions of
          keys required for generation on-demand.</p>
      </div>
    </blockquote>
    <br>
    Ok, so you are thinking of a Subscriber that owns an HSM and gets an
    IT audit that has an audit report that asserts that all Keys
    associated with Code Signing Certificates are generated in an
    on-prem certified HSM. Is this what this method is supposed to
    cover?<br>
    <br>
    <blockquote type="cite"
cite="mid:DM5PR11MB00419DE53956BFF1201F1D01829B9@DM5PR11MB0041.namprd11.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Option 5 Cloud-based protection is NOT
          Option 7 Signing Service protection. Cloud-based protection
          will allow a Subscriber to use an HSM from AWS. Signing
          Service protection has many requirements in the CSBRs, which
          currently includes an audit report. I assume that a CA will
          provide a Signing Service or could be similar to a TSP
          providing QSCD key generation and signing.
          <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Option 5 states, “The Subscriber provides a
          suitable report from the cloud-based key protection solution
          subscription and resources configuration protecting the
          private key in a suitable hardware crypto module meeting the
          requirements specified in section 16.3.1.” This is essentially
          a subscription agreement and not an audit report.</p>
      </div>
    </blockquote>
    <br>
    This "subscription agreement" has absolutely no assurances about
    anything. Any company could suggest they are a "cloud-based"
    provider with no audits and no assurances but would have a
    "subscription agreement". Would CAs accept that?<br>
    <br>
    We can discuss more on the call today.<br>
    <br>
    Dimitris.<br>
    <br>
    <blockquote type="cite"
cite="mid:DM5PR11MB00419DE53956BFF1201F1D01829B9@DM5PR11MB0041.namprd11.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Thanks, Bruce.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <div style="border:none;border-top:solid #E1E1E1
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b>From:</b> Dimitris Zacharopoulos
              (HARICA) <a class="moz-txt-link-rfc2396E" href="mailto:dzacharo@harica.gr"><dzacharo@harica.gr></a>
              <br>
              <b>Sent:</b> Thursday, November 18, 2021 1:58 AM<br>
              <b>To:</b> Bruce Morton <a class="moz-txt-link-rfc2396E" href="mailto:Bruce.Morton@entrust.com"><Bruce.Morton@entrust.com></a>;
              <a class="moz-txt-link-abbreviated" href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a>; Ian McMillan
              <a class="moz-txt-link-rfc2396E" href="mailto:ianmcm@microsoft.com"><ianmcm@microsoft.com></a><br>
              <b>Subject:</b> Re: [Cscwg-public] [EXTERNAL] Re:
              Discussion: Proposed Ballot CSC-6: Update to Subscriber
              Private Key Protection Requirements<o:p></o:p></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
        <div>
          <p class="MsoNormal">On 17/11/2021 8:56 μ.μ., Bruce Morton
            wrote:<o:p></o:p></p>
        </div>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal">Hi Dimitris,<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Regarding this statement, “I see that you
            probably missed my comment for removing option 4. (a
            suitable IT audit, etc). Are there any objections to
            removing that problematic option?”<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">The concern I have and has been raised on
            a call is if a customer has purchased a server HSM, which
            does not support key attestation, what is the CAs
            alternative to verify that the many keys have been generated
            on the HSM?<o:p></o:p></p>
        </blockquote>
        <p class="MsoNormal"><br>
          This is covered under option 6.<br>
          <br>
          <i>" 6.    The CA or a Qualified Auditor witnesses the key
            creation in a suitable hardware crypto module solution
            including a cloud-based key generation and protection
            solution. "
          </i><br>
          <br>
          <br>
          <o:p></o:p></p>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">I do understand that this is a
            problematic option, but I do not see another option for the
            above use case. We might be better suited to provide more
            information on the IT audit. Here are some ideas:<o:p></o:p></p>
          <ol style="margin-top:0in" type="1" start="1">
            <li class="MsoListParagraph"
              style="margin-left:0in;mso-list:l5 level1 lfo3">Form audit
              letter included in the CSBRs<o:p></o:p></li>
            <li class="MsoListParagraph"
              style="margin-left:0in;mso-list:l5 level1 lfo3">Signed by
              a verified identity, such as a Contract Signer<o:p></o:p></li>
            <li class="MsoListParagraph"
              style="margin-left:0in;mso-list:l5 level1 lfo3">Audit
              letter Includes a warranty that all keys for code signing
              certificates requested will be generated on the HSM<o:p></o:p></li>
            <li class="MsoListParagraph"
              style="margin-left:0in;mso-list:l5 level1 lfo3">Audit
              includes crypto device make, model, serial number and
              picture of serial number<o:p></o:p></li>
            <li class="MsoListParagraph"
              style="margin-left:0in;mso-list:l5 level1 lfo3">Etc.
              <o:p></o:p></li>
          </ol>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">I think we see that the current
            environment has limited USB tokens which support both
            3072/4096-bit RSA and key attestation. We also see that many
            server HSMs do not support key attestation. It looks like
            the ecosystem needs to evolve a little longer before we can
            make our requirements perfect.<o:p></o:p></p>
        </blockquote>
        <p class="MsoNormal"><br>
          As explained in previous discussions, there is no "IT audit"
          today that can remotely attest that an operating environment
          achieves the levels of security described in 16.3.1 (i.e. FIPS
          140-2 level 2 or EAL 4+). I believe your use case is perfectly
          covered with the new option 6.<br>
          <br>
          <br>
          <o:p></o:p></p>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Also, I don’t see that option 4 IT audit
            is any more problematic than option 5 a cloud provider
            subscription agreement.<o:p></o:p></p>
        </blockquote>
        <p class="MsoNormal"><br>
          The "cloud-based key protection solution" (or a "signing
          service key protection solution") will include an audit report
          that describes that the solution actually uses HSMs certified
          according to 16.3.1. The CA will review this audit report,
          ensure that the solution is compliant with 16.3.1 and then
          allow the Subscriber to use that service. Actually, 5 is very
          similar to 7, which is why I am suggesting we merge the
          "cloud-based solution" and the "signing service".<br>
          <br>
          Dimitris.<br>
          <br>
          <br>
          <o:p></o:p></p>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Bruce.<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <div>
            <div style="border:none;border-top:solid #E1E1E1
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b>From:</b> Cscwg-public <a
                  href="mailto:cscwg-public-bounces@cabforum.org"
                  moz-do-not-send="true">
                  <cscwg-public-bounces@cabforum.org></a> <b>On
                  Behalf Of </b>Dimitris Zacharopoulos (HARICA) via
                Cscwg-public<br>
                <b>Sent:</b> Wednesday, November 17, 2021 1:22 PM<br>
                <b>To:</b> Ian McMillan <a
                  href="mailto:ianmcm@microsoft.com"
                  moz-do-not-send="true"><ianmcm@microsoft.com></a>;
                <a href="mailto:cscwg-public@cabforum.org"
                  moz-do-not-send="true" class="moz-txt-link-freetext">cscwg-public@cabforum.org</a><br>
                <b>Subject:</b> Re: [Cscwg-public] [EXTERNAL] Re:
                Discussion: Proposed Ballot CSC-6: Update to Subscriber
                Private Key Protection Requirements<o:p></o:p></p>
            </div>
          </div>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
          <div>
            <p class="MsoNormal">On 17/11/2021 7:01 μ.μ., Ian McMillan
              wrote:<o:p></o:p></p>
          </div>
          <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
            <p class="MsoNormal"><span
                style="mso-fareast-language:EN-US">Hi Dmitris, </span>
              <o:p></o:p></p>
            <p class="MsoNormal"><span
                style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
            <p class="MsoNormal"><span
                style="mso-fareast-language:EN-US">This is not too
                painful.
              </span><span style="font-family:"Segoe UI
                Emoji",sans-serif">😊</span><o:p></o:p></p>
            <p class="MsoNormal"><span
                style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
            <p class="MsoNormal"><span
                style="mso-fareast-language:EN-US">Effective date set is
                September 1, 2022 as stated in section 16.3, but 16.2
                already has an effective date (June 1, 2021) for signing
                services to use
              </span>at least FIPS 140-2 level 2, or Common Criteria EAL
              4+ for ALL Code Signing Certificates per the table in
              section 1.3.  I’ll add the effective date into the table
              in section 1.3 for the changes in 16.3 on all code signing
              certs . Please review the text I used in the 1.3 table,
              and suggest some better language if possible.<o:p></o:p></p>
            <p class="MsoNormal"> <o:p></o:p></p>
            <p class="MsoNormal">When I read the,"conforming to <b>at
                least</b> FIPS 140-2 level 2, or Common Criteria EAL
              4+", it does apply to CC EAL 4+ as well.
              <o:p></o:p></p>
          </blockquote>
          <p class="MsoNormal"><br>
            Thanks for clarifying.<br>
            <br>
            <br>
            <br>
            <o:p></o:p></p>
          <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
            <p class="MsoNormal"> <o:p></o:p></p>
            <p class="MsoNormal">In 16.2, I’ve corrected the typo
              (thanks!), but for cloud-based solutions they will have
              their own terms for resources under a subscription. I
              think the wording we’ll need to summarize to is for each
              key generated and stored in the cloud-based subscription
              it must be conforming to the requirements. With Azure and
              AKV, if I have a subscription with a resource group and an
              AKV resource underneath, for every key I generate, I’ll
              need to specify the vault protection level (HSM) upon key
              creation. This means I could have a subscription with N
              number of keys with various protection levels. AKV
              recommends users do not group secrets into one vault, but
              it doesn’t stop users from making this risk decision on
              their own (more keys in one vault, the larger impact if
              compromised). GCP and AWS all have similar offerings and
              concepts, but the common level of terminology is
              subscription. I’ve updated the language to specifically
              target the subscription configuration at the level that
              manages the private key.
              <o:p></o:p></p>
          </blockquote>
          <p class="MsoNormal"><br>
            I believe this is too prescriptive. I don't think we can
            describe these specific options in a public standards
            document. That's why the term "signing service" and
            "cloud-based provider" must be described in terms of
            functional expectations. Who knows what options will be
            available in 2-5 years, or whether Microsoft, Amazon, Google
            and others will change their models and call these options
            something different than "subscription".<br>
            <br>
            <br>
            <br>
            <o:p></o:p></p>
          <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
            <p class="MsoNormal"> <o:p></o:p></p>
            <p class="MsoNormal">In 16.3.1, I’ve updated….<o:p></o:p></p>
            <p class="MsoNormal"> <o:p></o:p></p>
            <ol style="margin-top:0in" type="1" start="1">
              <li class="MsoListParagraph"
                style="margin-left:0in;mso-list:l2 level1 lfo6">To be
                the suggested text you provided, “Subscriber uses a
                hosted hardware crypto module meeting the specified
                requirement;” I feel this effectively closes the
                loophole you pointed out.<o:p></o:p></li>
            </ol>
            <p class="MsoNormal"> <o:p></o:p></p>
            <p class="MsoNormal">On cloud-based vs signing service
              solutions (2 & 3), they are distinctly different
              solutions in the market for subscribers today, so I feel
              we need to expressly call them out differently.
              <o:p></o:p></p>
          </blockquote>
          <p class="MsoNormal"><br>
            I don't disagree with that statement, although we do need to
            discuss and document their differences and even describe
            their functions in a clear and unambiguous way. The term
            "cloud" is overloaded and has been used in this industry to
            mean very different things  depending on the context.<br>
            <br>
            <br>
            <br>
            <o:p></o:p></p>
          <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
            <p class="MsoNormal"> <o:p></o:p></p>
            <p class="MsoNormal">For section 16.3.2, I am good with the
              suggested change to #2 with a small ordering tweak being,
              “The Subscriber counter-signs certificate requests that
              can be verified by using a manufacturer’s certificate
              indicating that the key was generated in a non-exportable
              way using a suitable hardware module;”<o:p></o:p></p>
            <p class="MsoNormal"> <o:p></o:p></p>
            <p class="MsoNormal">With #1, I’d prefer keeping the same
              way it is today.  I’m interested how folks view section
              10.2.4 playing a part here as well (and with signing
              services).
              <o:p></o:p></p>
          </blockquote>
          <p class="MsoNormal"><br>
            To help with the comparison, let me repeat the text here:<br>
            <br>
            <i>"1.    The CA ships a suitable hardware crypto module,
              with a preinstalled key pair" could be changed to:<br>
              <br>
              "1.    The CA ships a suitable hardware crypto module,
              with one or more pre-generated key pairs that the CA has
              generated using those crypto modules"</i><br>
            <br>
            The current wording is limiting the key-pairs to just <b>one
              key-pair</b> (singular) when the CA can ship more than one
            key-pairs (for future use). I also wanted to avoid the case
            where CAs generate keys outside of these hardware modules
            (via software because it's faster) and then import them into
            crypto-modules and ship them to Subscribers.<br>
            <br>
            I see that you probably missed my comment for removing
            option 4. (a suitable IT audit, etc). Are there any
            objections to removing that problematic option?<br>
            <br>
            <br>
            <br>
            <br>
            <o:p></o:p></p>
          <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
            <p class="MsoNormal"> <o:p></o:p></p>
            <p class="MsoNormal">On #8, My goal wasn’t to set a deadline
              for new methods to be introduced, but to require any
              innovations to be well documented by the CAs and brought
              to the Forum’s working group for inclusion. That said, I
              see the loophole this creates in that a CA could include a
              new method in their CP/CPS docs and bring it to the WG in
              the accordance with this requirement. But the WG could
              deem the method not acceptable and there is no requirement
              that states the CA must not use that now rejected method.
              The downside is we really do not want to maintain a
              rejected method list, so I am with you on the suggested
              change you provided with the date being September 1, 2022.
              I would like to keep the dates all aligned to reduce
              confusion.
              <o:p></o:p></p>
          </blockquote>
          <p class="MsoNormal"><br>
            I believe this was discussed during our last call and the
            plan was for a roadmap that would ultimately remove this
            "any other method" option. Until that time, CAs would need
            to disclose their "any other methods" to the CABF until a
            certain date (Sep 1, 2022 seems fine with me), so the WG can
            evaluate the security of that method and either include or
            reject it. I think we're in total agreement here :)<br>
            <br>
            <br>
            <br>
            <o:p></o:p></p>
          <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
            <p class="MsoNormal"> <o:p></o:p></p>
            <p class="MsoNormal">The attached updated redline draft has
              all these changes.<o:p></o:p></p>
          </blockquote>
          <p class="MsoNormal"><br>
            Let me know how you feel about the other changes. To
            summarize:<br>
            <br>
            In section 16.3.2:<o:p></o:p></p>
          <ol type="1" start="1">
            <li class="MsoNormal"
              style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
              level1 lfo9">
              Update option 1 to allow more keys to be shipped and keys
              generated <b>in</b> crypto-devices instead of outside and
              then imported<o:p></o:p></li>
            <li class="MsoNormal"
              style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
              level1 lfo9">
              Removal of option 4<o:p></o:p></li>
          </ol>
          <p>We will probably need some more analysis comparing "signing
            service" vs "cloud provider" to get a better feeling of the
            functional differences and adjust accordingly.<o:p></o:p></p>
          <p> <o:p></o:p></p>
          <p>Thanks,<o:p></o:p></p>
          <p>Dimitris.<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal"><i>Any email and files/attachments
              transmitted with it are confidential and are intended
              solely for the use of the individual or entity to whom
              they are addressed. If this message has been sent to you
              in error, you must not copy, distribute or disclose of the
              information it contains. <u>Please notify Entrust
                immediately</u> and delete the message from your system.</i>
            <o:p></o:p></p>
        </blockquote>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
    </blockquote>
    <br>
  </body>
</html>