Hi all, ISRG is working with Apple and Google to deploy Prio, a "privacy-preserving system for the collection of aggregate statistics:" https://crypto.stanford.edu/prio/. Mozilla has previously demonstrated Prio for use with telemetry data: https://hacks.mozilla.org/2018/10/testing-privacy-preserving-telemetry-with-prio/ and https://blog.mozilla.org/security/2019/06/06/next-steps-in-privacy-preserving-telemetry-with-prio. Part of the plan involves using Web PKI certificates in an unusual way, so I wanted to get feedback from the community and root programs.
In Prio, clients (mobile devices in this case) generate "shares" of data to be sent to non-colluding processors. Those processors calculate aggregate statistics without access to the underlying data, and their output is combined to determine the overall statistic - for instance, the number of users who clicked a particular button. The goal is that no party learns the information for any individual user. As part of this particular deployment, clients encrypt their shares to each processor (offline), and then send the resulting encrypted "packets" of share data via Apple and Google servers to the processors (of which ISRG would be one). The encryption scheme here is ECIES ( https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme). The processors need some way to communicate their public keys to clients. The current plan is this: A processor chooses a unique, public domain name to identify its public key, and proves control of that name to a Web PKI CA. The processor requests issuance of a TLS certificate with SubjectPublicKeyInfo set to the P-256 public key clients will use to encrypt data share packets to that processor. Note that this certificate will never actually be used for TLS. The processor sends the resulting TLS certificate to Apple. Apple signs a second, non-TLS certificate from a semi-private Apple root. This root is trusted by all Apple devices but is not in other root programs. Certificates chaining to this root are accepted for submission by most CT logs. This non-TLS certificate has a CN field containing text that is not a domain name (i.e. it has spaces). It has no EKUs, and has a special-purpose extension with an Apple OID, whose value is the hash of the public key from the TLS certificate (i.e. the public key that will be used by clients to encrypt data share packets). This certificate is submitted to CT and uses the precertificate flow to embeds SCTs. The Prio client software on the devices receives both the TLS and non-TLS certificate from their OS vendor, and validates both, checking OCSP and CT requirements, and checking that the public key hash in the non-TLS certificate's special purpose extension matches the SubjectPublicKeyInfo in the TLS certificate. If validation passes, the client software will use that public key to encrypt data share packets. The main issue I see is that the processor (a Subscriber) is using the TLS certificate for a purpose not indicated by that certificate's EKUs. RFC 5280 says (https://tools.ietf.org/html/rfc5280#section-4.2.1.12): > 4.2.1.12. Extended Key Usage > If the extension is present, then the certificate MUST only be used > for one of the purposes indicated. The BRs say ( https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf): > 4.9.1.1 Reasons for Revoking a Subscriber Certificate > The CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days if one or more of the following occurs: > 2. The CA obtains evidence that the Certificate was misused; "Misused" is not defined here but I think a reasonable interpretation would be that a Subscriber would trigger the revocation requirement by violating the EKU MUST from RFC 5280. I also have a concern about ecosystem impact. The Web PKI and Certificate Transparency ecosystems have been gradually narrowing their scope - for instance by requiring single-purpose TLS issuance hierarchies and planning to restrict CT logs to accepting only certificates with the TLS EKU. New key distribution systems will find it tempting to reuse the Web PKI by assigning additional semantics to certificates with the TLS EKU, but this may make the Web PKI less agile. I've discussed the plan with Apple, and they're fully aware this is an unusual and non-ideal use of the Web PKI, and hope to propose a timeline for a better system soon. One of the constraints operating here is that Apple has already shipped software implementing the system described above, and plans to use it in addressing our current, urgent public health crisis. As far as I know, no publicly trusted Web PKI certificates are currently in use for this purpose. So, mdsp folks and root programs: Can a CA or a Subscriber participate in the above system without violating the relevant requirements? Thanks, Jacob _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
