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
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
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]
https://cabforum.org/mailman/listinfo/public
