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