<div dir="ltr">I can understand the sentiment, but in the spirit of ensuring we install screws with screwdrivers and nails with hammers, rather than the other way around, it's worth noting that alternative methods of providing that degree of transparency exist, and in a way that can preserve much more of the privacy properties.<div><br></div><div>You can see this at <a href="https://security.googleblog.com/2017/01/security-through-transparency.html">https://security.googleblog.com/2017/01/security-through-transparency.html</a> based on the CONIKS work from Princeton ( <a href="https://coniks.cs.princeton.edu/">https://coniks.cs.princeton.edu/</a> )</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 13, 2017 at 12:35 AM, Dimitris Zacharopoulos via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Even though it is currently out of scope in the current form of the
    CA/B Forum, IMO it would be very beneficial to use CT Logs to
    include pre-Certificates used for digital signatures and S/MIME.
    These Certificates include Personally Identifiable Information and
    e-mail addresses that could be collected by spammers so redaction
    would be something useful to have.<br>
    <br>
    I understand that currently there is no application to enforce this
    but having a technical provision might drive a product to implement
    support for SCTs in client Certificates.<br>
    <br>
    <br>
    Dimitris.<div><div class="h5"><br>
    <br>
    <div class="m_-8978535127674488176moz-cite-prefix">On 13/11/2017 5:49 πμ, Eric Mill via
      Public wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>To note for the record: when a group of affiliated with the
          U.S. Federal PKI attended CA/Browser Forum F2F 39 in Redmond,
          on behalf of the General Services Administration and the
          Department of Defense, I announced that were beginning a new
          project to create a publicly trusted root, and that we planned
          to submit all issued certificates to Certificate Transparency
          logs. </div>
        <div><br>
        </div>
        <div>As part of that, I also represented GSA and DoD's consensus
          that we were not requesting support for CT redaction in order
          to meet that pledge. We were, and are, comfortable with a CT
          requirement that does not include support for redaction.<br>
        </div>
        <div><br>
        </div>
        <div>To speak just for myself, but based on my work experience
          at improving the security of federal government systems, the
          effect of implementing support for redaction in the CT
          ecosystem would be to reduce security, and I strongly
          recommend that CAs drop any efforts to push for support of
          it. </div>
        <div><br>
        </div>
        <div>There are at least 3 ways that redaction would reduce
          internet security if implemented in CT:</div>
        <div><br>
        </div>
        <div>* Increasing the complexity and bug surface of
          SCT-consuming clients (such as browsers and monitors) and
          SCT-producing systems (such as CAs).</div>
        <div><br>
        </div>
        <div>* Loss of visibility and accountability in the Web PKI by
          reducing the value of CT logs to the ecosystem. This is
          combined with the likelihood of "over-redaction", where
          enterprises choose to redact certificates by default out of
          misplaced security concerns. </div>
        <div><br>
        </div>
        <div>* What Chrome and others have already pointed out -- there
          are a variety of situations in which domain owners may lose
          visibility what certificates are authorized for their own
          hostnames, either through domain transfers or acquisitions, or
          through governance issues in sufficiently large enterprises.</div>
        <div><br>
        </div>
        <div>While I'm sure CAs are accurately representing the concerns
          of some of their customers, the customers are not always
          right. Relying on the obscurity of hostnames as a security
          boundary is not only ineffective, but dangerous. And in the
          case of the Web PKI, where security is shared and where the
          actions of individual CAs can sometimes imperil the security
          of organizations who have no relationship to those CAs,
          ecosystem accountability is a paramount concern.</div>
        <div><br>
        </div>
        <div>-- Eric</div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Fri, Nov 3, 2017 at 7:23 PM, Kirk
            Hall via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div link="#0563C1" vlink="#954F72" lang="EN-US">
                <div class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133WordSection1">
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    Entrust, Secom, Comodo, and other CAs will be asking
                    the IETF TRANS Working Group to revive work on a new
                    RFC to complete specifications for CT Domain Label
                    Redaction (called “Redaction” for short in this
                    message).  The new RFC would only cover technical
                    issues and not policy issues.  </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    The RFC for Certificate Transparency, RFC 6962,
                    started to address Redaction, but never completed
                    the work because of policy issues that were raised
                    about “recourse”, or how domain owners would be able
                    to obtain information about redacted certificates
                    that were CT logged to determine if they were
                    legitimate or misissued.</p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    This email is to lay out the course we want to
                    follow to complete the technical specs for Redaction
                    in the IETF, and also to address the recourse issues
                    and consider appropriate changes to the Forum’s
                    Baseline Requirements in response.</p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    <b><u>1. New IETF effort on completing Redaction
                        specifications via a new RFC</u></b></p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    Tadahiko of Secom and Rob Stradling of Comodo are
                    working on a new I-D draft on Redaction that will be
                    presented to the IETF TRANS Working Group for
                    consideration.  Tadahiko will present the draft at
                    the next IETF meeting in Singapore in mid-November.</p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    Why do we want to complete the Redaction
                    specifications?  Because we believe enterprise users
                    of certificates in particular want to have the
                    option of using publicly-trusted, CT logged
                    certificates behind their firewalls that do not
                    reveal their security topography by revealing all
                    nodes in the FQDN during CT logging.  In most cases,
                    it’s not practical to set up and maintain a private
                    root for use behind the firewall and push out the
                    private root to all users, including vendors and
                    contractors, so that is not a viable alternative for
                    many enterprises.  </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    It’s been suggested that publicly trusted certs
                    could be issued but not CT logged, but this is also
                    an unacceptable alternative for use with common
                    browser and application software because of the
                    constant browser warnings that would be displayed to
                    users (“not logged, not secure”) – at a minimum,
                    this could set up “warning fatigue” among users
                    causing them to ignore more serious warnings, which
                    is bad for security.
                  </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    It’s also been suggested that enterprises should
                    just use wildcard certificates everywhere – but that
                    could push users to using the same wildcard cert key
                    pair on hundreds of servers, which is bad for
                    security.  Likewise, using multiple identical
                    wildcard certs with different key pairs across
                    hundreds or thousands of servers with different
                    FQDNs could be incredibly hard to track and manage. 
                    That leaves redacted, publicly-trusted, CT logged
                    certs as the best security solution for these
                    website owners.</p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    Another reason for completing an RFC for Redaction
                    is the increasing use of certificates in IoT
                    devices.  There are good reasons why “things” that
                    connect to the internet (cars, baby monitors, etc.)
                    will want to use publicly trusted certificates that
                    work in common browsers and applications, but will
                    not want the device identity number hierarchy
                    publicly disclosed on CT logs for security
                    purposes.  While “things” could go to private roots,
                    going that direction could prevent interoperability,
                    and incompatibility with modern browser software
                    could cause IoT device software to rely on custom
                    software that doesn’t receive security updates (as
                    browser software does) and lead to the same kind of
                    frozen legacy root stores that can’t be updated that
                    we saw during SHA-1 deprecation problems.  </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    We think it’s in the security and commercial
                    interests of browsers to encourage IoT devices to
                    use publicly trusted certificates with their
                    software, but device makers might not do so if they
                    can’t use Redaction for security purposes.  See also
                    <a href="http://internetofthingsagenda.techtarget.com/blog/IoT-Agenda/Senate-IoT-security-bill-could-mandate-IoT-field-certificate-provisioning" target="_blank">
                      http://internetofthingsagenda.<wbr>techtarget.com/blog/IoT-Agenda<wbr>/Senate-IoT-security-bill-coul<wbr>d-mandate-IoT-field-certificat<wbr>e-provisioning</a>
                  </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    Tadahiko has provided even more specific IoT cases
                    where Redaction would be important for security:</p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.25in">(1) Customers may want to
                    use server certificates for surveillance cameras and
                    network attached storage.  The use of those
                    internet-connected devices will increase in the near
                    future.
                  </p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.25in"> </p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.25in">(2) In addition, in
                    vehicle-to-vehicle communications auto manufacturers
                    are planning to use some form of PKI, and likely
                    will want to externally control some of devices on
                    vehicles in future. 
                  </p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.25in">Although currently they’re
                    not using RFC 5280 certificates, some devices will
                    likely be externally controllable and will use
                    publicly trusted certs in the future. In that case,
                    they will want name redaction for obvious security
                    purposes.</p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.25in"> </p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.25in">(3) Other security
                    concerns about IoT devices include the following:</p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.25in"> </p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.5in">(a) For low-resource IoT
                    devices (cameras, sensors, some car uses, etc.), DOS
                    attacks are possible, and unredacted CT logs may
                    help the DOS attacker.</p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.5in"> </p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.5in">(b) For some IoT devices
                    (cameras, sensors, etc.), geo-location information
                    is very sensitive.  If the certificate is logged
                    with CT, there must be a mechanism like redaction to
                    anonymize.
                  </p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.5in"> </p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoPlainText" style="margin-left:.5in">(c) Manufacturers using IoT
                    certificates won’t want to show the number of
                    devices they have shipped, and redaction may help
                    keep this information private.</p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    For all these reasons, we plan to move forward in
                    the IETF TRANS Working Group on a new domain label
                    Redaction RFC. 
                  </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    Those in the Forum who want to support this effort
                    should contact Tadahiko, Rob, and me this week.</p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    <b><u>2. Resolving “recourse” policy issues in the
                        Baseline Requirements</u></b></p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal">The “recourse” issues were best
                    stated by Ryan Sleevi in this April 2016 message:
                    <span style="color:#222222"><a href="https://groups.google.com/a/chromium.org/d/msg/ct-policy/vsTzv8oNcws/imuC3iloBwAJ" target="_blank">https://groups.google.com/a/ch<wbr>romium.org/d/msg/ct-policy/vsT<wbr>zv8oNcws/imuC3iloBwAJ</a>
                    </span></p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    I think all of these scenarios outlined in the email
                    can be addressed by existing Certificate Problem
                    Report requirements under BR 4.9.1 through 4.9.3,
                    but can be improved by adding new provisions
                    something like the following (this is just
                    conceptual text, not a specific BR amendment
                    proposal at this time):</p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-left:.5in">“If a CA
                    uses redaction when CT logging a certificate, the CA
                    SHALL create and implement a process by which a
                    party (“Inquiring Party”) who owns or controls a
                    domain (“Subject Domain”) and sees a redacted
                    certificate (“Redacted Certificate”) for the Subject
                    Domain in a CT log or elsewhere may request
                    additional information about the Redacted
                    Certificate issued to a prior Applicant
                    (“Applicant”), and may also request revocation of
                    the Redacted Certificate if appropriate.  The CA
                    SHALL publicly post an email address, telephone
                    number, and general process (“Inquiry Process”) for
                    such requests.   The Inquiry Process SHALL include
                    the following elements:</p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoListParagraph" style="margin-left:1.0in">
                    <span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">      
                        </span></span></span>A format that may be used
                    by the Inquiring Party to request information about
                    a Redacted Certificate, including name and contact
                    information by which the CA may contact the
                    Inquiring Party;</p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoListParagraph" style="margin-left:1.0in">
                    <span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">      
                        </span></span></span>The manner by which the CA
                    will confirm that the Inquiring Party owns or
                    controls the Subject Domain.  The CA SHOULD offer
                    the Inquiring Party multiple options for
                    verification methods to confirm the Inquiring
                    Party’s ownership or control of the Subject Domain;</p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoListParagraph" style="margin-left:1.0in">
                    <span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">      
                        </span></span></span>The process the CA will
                    follow once the Inquiring Party has shown ownership
                    or control of the Subject Domain, including how the
                    CA will notify the Applicant about the Inquiring
                    Party’s inquiry and what information the CA will
                    provide to the Inquiring Party and the Applicant;
                    and</p>
                  <p class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027m_256102030277778133MsoListParagraph" style="margin-left:1.0in">
                    <span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">      
                        </span></span></span>If the Applicant objects to
                    the CA providing information about the Redacted
                    Certificate to the Inquiring Party, or if the
                    Inquiring Party requests revocation of the Redacted
                    Certificate, the general process the CA will follow
                    to adjudicate the dispute among the parties.”</p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    Because this process will chiefly be carried out by
                    CAs, we plan to first discuss this in the Forum to
                    get a workable proposal drafted for “recourse”
                    language, and then to post it to the TRANS WG for
                    public comments.  After that, we can consider a
                    specific ballot in the Forum to add appropriate
                    “recourse” provisions to the BRs.</p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                     </p>
                  <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                    Thanks for your attention to this new project (and
                    this long email).  Please let me know if you want to
                    join in.<span class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027HOEnZb"></span></p>
                  <span class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027HOEnZb"><font color="#888888">
                      <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                         </p>
                      <p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
                        Kirk</p>
                    </font></span></div>
              </div>
              <br>
              ______________________________<wbr>_________________<br>
              Public mailing list<br>
              <a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
              <a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/l<wbr>istinfo/public</a><br>
              <br>
            </blockquote>
          </div>
          <br>
          <br clear="all">
          <div><br>
          </div>
          -- <br>
          <div class="m_-8978535127674488176m_2902357201096008478m_4588915294031624305m_-3298282688485793027gmail_signature" data-smartmail="gmail_signature">
            <div dir="ltr">
              <div>
                <div dir="ltr">
                  <div>
                    <div dir="ltr">
                      <div>Eric Mill</div>
                      <div>Senior Advisor, <span style="font-size:12.8px">Technology
                          Transformation Services, GSA</span></div>
                      <div><span style="font-size:12.8px"><a href="mailto:eric.mill@gsa.gov" target="_blank">eric.mill@gsa.gov</a>, </span><a href="tel:%28617%29%20314-0966" value="+16173140966" target="_blank">+1-617-314-<wbr>0966</a></div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="m_-8978535127674488176mimeAttachmentHeader"></fieldset>
      <br>
      <pre>______________________________<wbr>_________________
Public mailing list
<a class="m_-8978535127674488176moz-txt-link-abbreviated" href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a>
<a class="m_-8978535127674488176moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
<br></blockquote></div><br></div>