On 2020-10-30 01:50, Matthew Hardeman wrote:
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.
Cryptographically, I think the concern is this:
In this scheme, the authenticated server B will use the corresponding
private key in a mathematically complex protocol that is neither TLS nor
CMS. It is conceivable that said protocol may have a weakness that
allows a clever opponent M to exchange traffic with B in order to
discover B's private key.
Thus using a WebPKI "Server Authentication" certificate to bind a public
key used by party A to identify party B in the "prio" protocol creates a
potential risk of creating a family of certificates with easily
compromised keys.
Thus it makes sense for the involved CAs (such as Let's Encrypt) to
issue these certificates with a unique EKU other than the generic
"Server Authentication" traditionally associated with TLS.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
