Hi, all, Thank you for your feedback on this project. In order to address your comments, we have adjusted our design and implementation so that publicly-trusted certificates are no longer used and have modified our use of Certificate Transparency.
All certificates for encrypting data for Prio will be issued by Apple to the processors under our “semi-private” roots (i.e. https://crt.sh/?id=1160190 <https://crt.sh/?id=1160190>, https://crt.sh/?id=12727249 <https://crt.sh/?id=12727249>, https://crt.sh/?id=12728973 <https://crt.sh/?id=12728973>). These certificates will have a Key Usage of Key Agreement and an Extended Key Usage containing an Apple OID (1.2.840.113635.100.4.18). The Common Name will contain an entity name (expected to be an ISO 3166 country or region code, but will be defined by Apple during configuration of the processor) for the benefit of users reviewing the keys and certificates used to encrypt their data. Attached are certificate chains issued from our test roots under these profiles. The production certificates will include SCTs from CT logs usable on Apple’s platforms. In order to address concerns about the future direction of the CT ecosystem, Apple clients will maintain two distinct log lists of qualified logs — those that are permitted for TLS only and those that allow other EKUs. These new certificates will be qualified against the latter list, while TLS certificates will continue to be qualified against the former. Today these lists are the same, but we expect them to diverge as the CT ecosystem progresses. Thanks, Bailey > On Nov 4, 2020, at 2:12 PM, Jacob Hoffman-Andrews <j...@letsencrypt.org> > wrote: > > 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 >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
