IFF the publicly trusted certificate for the special domain name is acquired in the normal fashion and is issued from the normal leaf certificate profile at LE, I don't see how the certificate could be claimed to be "misused" _by the subscriber_.
To the extent that there is misuse in the described use-case, it would be "misuse" on the part of the relying party software agent (which would be trusting the certificate with a purpose and role in conflict with the EKUs), but not misuse on the part of the certificate subscriber. Publication of a leaf certificate (via various mechanisms) is not unusual nor cause for alarm or revocation. People public key PIN, though unwise people also certificate PIN. A key compromise would be different, but that's not described here. Would you revoke a properly issued certificate upon proof that some new-fangled scheme employed by a third-party application acquires a copy of a TLS Server leaf certificate, chases its validity (save for EKU impropriety) correctly, and then utilizes the certificate's subject public key in an unanticipated way? Any competent software developer with basic PKI understanding and some rules lawyering could get any certificate revoked at any time in that picture. I would submit that this can not be the correct analysis, not pragmatically. The mere fact that a single entity is both the Subscriber and the author of the Relying Party agent is inconsequential, is it not? Quite separately, I'm most confused by what kind of aggregate statistics Prio is purported to be sending and its urgency as a public health matter. I think I am likely to be unpleased by whatever this thing is, but I suppose that's not at all germane to the WebPKI question. On Thu, Oct 29, 2020 at 1:07 PM Jacob Hoffman-Andrews via dev-security-policy <dev-security-policy@lists.mozilla.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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
