[cabfpub] New RFC on CT Domain Label Redaction

Dimitris Zacharopoulos jimmy at it.auth.gr
Mon Nov 13 05:35:07 UTC 2017

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.


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 
> <public at cabforum.org <mailto:public at cabforum.org>> 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
>     Public at cabforum.org <mailto:Public at cabforum.org>
>     https://cabforum.org/mailman/listinfo/public
>     <https://cabforum.org/mailman/listinfo/public>
> -- 
> Eric Mill
> Senior Advisor, Technology Transformation Services, GSA
> eric.mill at gsa.gov <mailto:eric.mill at gsa.gov>, +1-617-314-0966 
> <tel:%28617%29%20314-0966>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171113/6830b8a9/attachment-0003.html>

More information about the Public mailing list