Hi, Matt, We thought hard about the agility concerns for this particular application and the impact to the WebPKI and CT ecosystems. First, all certificates involved in this design are checked for expiration, revocation, and Certificate Transparency using all of the same logic that verifies TLS certificates on Apple platforms. Second, we are automating the entire process by which partners can submit their third-party-issued TLS certificates and the configuration is deployed to clients. Furthermore, the clients are able to get updated configuration within twenty-four hours. Additionally, as Jacob indicated, we consider this a relatively short-term solution in order to provide Public Health Authorities necessary statistics to respond to the current public health crisis and will be adopting a different solution in a future release. If you have specific question or concerns about how the agility of this architecture would negatively impact the WebPKI, I am happy to answer those.
We specifically chose not to issue Apple certificates for these keys because we did not want users to have to trust only Apple's assertion that this key is for a third party. Bailey On Thursday, October 29, 2020 at 4:30:19 PM UTC-7, Matt Palmer wrote: > On Thu, Oct 29, 2020 at 01:56:53PM -0500, Matthew Hardeman via > dev-security-policy wrote: > > 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_. > The way I read Jacob's description of the process, the subscriber is > "misusing" the certificate because they're not going to present it to TLS > clients to validate the identity of a TLS server, but instead they (the > subscriber) presents the certificate to Apple (and other OS vendors?) when > they know (or should reasonably be expected to know) that the certificate is > not going to be used for TLS server identity verification -- specifically, > it's instead going to be presented to Prio clients for use in some sort of > odd processor identity parallel-verification dance. > > Certainly, whatever's going on with the certificate, it most definitely > *isn't* TLS, and so absent an EKU that accurately describes that other > behaviour, > I can't see how it doesn't count as "misuse", and since the subscriber has > presented the certificate for that purpose, it seems reasonable to describe > it as "misuse by the subscriber". > > Although misuse is problematic, the concerns around agility are probably > more concerning, IMO. There's already more than enough examples where > someone has done something "clever" with the WebPKI, only to have it come > back and bite everyone *else* in the arse down the track -- we don't need to > add another candidate at this stage of the game. On that basis alone, I > think it's worthwhile to try and squash this thing before it gets any more > traction. > > Given that Apple is issuing another certificate for each processor anyway, I > don't understand why they don't just embed the processor's SPKI directly in > that certificate, rather than a hash of the SPKI. P-256 public keys (in > compressed form) are only one octet longer than a SHA-256 hash. But > presumably there's a good reason for not doing that, and this isn't the > relevant forum for discussing such things anyway. > > - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
