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
