On Thu, Oct 29, 2020 at 6:30 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
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. > To my knowledge, caching/storing a leaf certificate isn't misuse. While they appear to be presenting it in some manner other than via a TLS session, I don't believe there's any prohibition against such a thing. Would it cure the concern if they also actually ran a TLS server that does effectively nothing at the host name presented in the SAN dnsName? > > 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". > Not all distribution of a leaf certificate is "use", let alone "misuse". There are applications which certificate PIN rather than key PIN. Is that misuse? > > 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. > My question is by what rule do you squash this thing that doesn't also cover a future similar use by a third-party relying party that makes "additional" use of some subscriber's certificate. > > 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. > Presumably this is so that the data processors can choose a key for the encryption of their data shards and bind that to a DNS name demonstrated to be under the data processor's control via a standard CA issuance process without abstracting the whole thing away to certificates controlled by Apple and/or Google. To demonstrate that the fractional data shard holder's domain was externally validated by a party that isn't Apple or Google. People scrape and analyze other parties' leaf certificates all the time. What those third parties do with those certificates (if anything) is up to those third parties. If a third party can do things which causes a subscriber's certificate to be revokable for misuse without having derived or acquired the private key, I hesitate to call that ridiculous, but it is probably unsustainable. Extending upon that, if the mere fact that the subscriber and the author of the relying party validation agent are part of the same corporate hierarchy changes the decision for the same set of circumstances, that's suspect. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
