<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>