Hi Jacob, I’m chiming in in my official capacity as a member of Chrome’s root program and its Certificate Transparency lead.
Over the past several years, the narrowing of scope for both the web PKI and CT has been highly intentional. Great efforts have been made to ensure that use cases outside of TLS do not further ossify a system that often already struggles to meet the agility requirements of its primary use case. For this reason, we are generally opposed to adding external dependencies, such as the ones this feature creates, to both CT and the web PKI. With that being said, the specific requirements applicable to this situation include areas that are underspecified as well as some that are expressed in unclear terms, especially where the requirements involve interplay between the Baseline Requirements (BRs), multiple RFCs, and root program requirements. Our high-level concerns with this proposal include: * Adding external (non-TLS) dependencies to CT and the web PKI, which slows both the adoption of ecosystem improvements as well as the deprecation of problematic practices. * Requiring CAs to knowingly issue publicly-trusted TLS certificates for a definitively non-TLS use, calling into question what “misuse” means in the context of BR section 4.9.1.1. * Concerns with how the proposed certificate profile, including the semantics for the keyUsage and extendedKeyUsage, fit within the framework of BR section 7.1.2.4, particularly when the CA knowingly issues such certificates. While we believe that this proposal does not align with the intent of existing requirements, the proposed certificate usage is not unambiguously prohibited. Some of these requirements, such as the BRs, are already in the process of being updated to provide crisper guidance on what is and is not permitted. As maintainers of the Chrome root program and its CT policy, we will similarly work to provide greater clarity going forward by continuing to improve and update our policies. -Devon On Thursday, October 29, 2020 at 11:07:22 AM UTC-7, js...@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
