Thanks to all here for the useful feedback. We've decided not to issue publicly trusted TLS certificates carrying keys for use in ECIES.
On Thu, Oct 29, 2020 at 11:06 AM Jacob Hoffman-Andrews <j...@letsencrypt.org> wrote: > 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
