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.
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.
Dimitris.
On 13/11/2017 5:49 πμ, Eric Mill via Public wrote:
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.
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.
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.
There are at least 3 ways that redaction would reduce internet
security if implemented in CT:
* Increasing the complexity and bug surface of SCT-consuming clients
(such as browsers and monitors) and SCT-producing systems (such as CAs).
* 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.
* 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.
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.
-- Eric
On Fri, Nov 3, 2017 at 7:23 PM, Kirk Hall via Public
<[email protected] <mailto:[email protected]>> wrote:
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.
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.
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.
*_1. New IETF effort on completing Redaction specifications via a
new RFC_*
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.
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.
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.
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.
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.
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
http://internetofthingsagenda.techtarget.com/blog/IoT-Agenda/Senate-IoT-security-bill-could-mandate-IoT-field-certificate-provisioning
<http://internetofthingsagenda.techtarget.com/blog/IoT-Agenda/Senate-IoT-security-bill-could-mandate-IoT-field-certificate-provisioning>
Tadahiko has provided even more specific IoT cases where Redaction
would be important for security:
(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.
(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.
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.
(3) Other security concerns about IoT devices include the following:
(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.
(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.
(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.
For all these reasons, we plan to move forward in the IETF TRANS
Working Group on a new domain label Redaction RFC.
Those in the Forum who want to support this effort should contact
Tadahiko, Rob, and me this week.
*_2. Resolving “recourse” policy issues in the Baseline Requirements_*
The “recourse” issues were best stated by Ryan Sleevi in this
April 2016 message:
https://groups.google.com/a/chromium.org/d/msg/ct-policy/vsTzv8oNcws/imuC3iloBwAJ
<https://groups.google.com/a/chromium.org/d/msg/ct-policy/vsTzv8oNcws/imuC3iloBwAJ>
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):
“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:
·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;
·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;
·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
·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.”
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.
Thanks for your attention to this new project (and this long
email). Please let me know if you want to join in.
Kirk
_______________________________________________
Public mailing list
[email protected] <mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public
<https://cabforum.org/mailman/listinfo/public>
--
Eric Mill
Senior Advisor, Technology Transformation Services, GSA
[email protected] <mailto:[email protected]>, +1-617-314-0966
<tel:%28617%29%20314-0966>
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
