On Sun, Mar 01, 2020 at 11:14:12PM -0500, Ryan Sleevi wrote:
> On Sun, Mar 1, 2020 at 9:49 PM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > The BRs, in s4.9.1.1, say:
> >
> > > The CA SHALL revoke a Certificate within 24 hours if one or more of the
> > > following occurs:
> > >
> > > [...]
> > > 3. The CA obtains evidence that the Subscriber's Private Key
> > > corresponding to the Public Key in the Certificate suffered a Key
> > > Compromise
> >
> > I've come to have some concerns about this clause of the BRs, in that it
> > seems very much up to the CA to decide what constitutes valid "evidence" of
> > key compromise, and there doesn't appear to be anything (other than
> > possible
> > mdsp censure, after the fact) preventing a CA using "your evidence is
> > insufficient" as a way of delaying revocation, potentially indefinitely.
>
> That’s not quite correct. They also have to convince their auditor,
> although whether or not you see that as a barrier depends.
No, I don't see auditors as a barrier to anything.
> However, I get the feeling that you don’t put much stock into incident
> reports and browsers dim view of shenanigans. That might be worth expanding
> upon, if you believe the incident reporting process is not adequately
> protecting users or balancing tradeoffs.
No, it's not that. I like the incident report system, and Mozilla does a
reasonable job of enforcing what rules there already are. It's just that CAs
often argue that they didn't *know* that doing a bad thing was bad because
the rules didn't *say* that it was a bad thing, and when I started operating
in this area I found something that I thought was potentially a loophole,
and I wanted to discuss it before standing up and shouting "HOUSTON WE HAVE
AN INCIDENT!" -- because *that* is the sort of thing that devalues the
incident reporting system.
> > In my specific case, I've been providing a JWS[1] signed by the compromised
> > private key, and CAs are telling me that they can't (or won't) work with a
> > JWS, and thus no revocation is going to happen. Is this a reasonable
> > response?
>
> Honestly? Yes.
Fair enough. Your honesty is appreciated.
> There’s no reason to expect a CA to be prepared to support Arbitrary Format
> Foo. While my distaste for the JOSE suite of boondoggles is deeply
> entrenched, I do think there’s benefit in using common PDUs that CA tooling
> already deals with. As discussed in the past, the CSR approach is not
> without merit.
I found the argument that it was risky to use anything that could possibly
be mistaken for a "real" web PKI artifact, to be quite compelling. That is
why I kept away from using a CSR, self-signed cert ("poisoned" or
otherwise), or anything of that nature.
At any rate, it is at least easy enough to test whether CAs are able to
handle a CSR any better than a JWS. There's plenty of fish still in the
barrel; I'll pull a few keys out of cold storage, generate CSRs from them,
and see if CAs are able to process those any easier.
> > Relatedly, if a CA were to receive a key compromise notification which
> > truly *doesn't* have sufficient evidence of compromise, but which at
> > least has some degree of legitimacy (rather than "I haxxed teh keys to
> > your CA, better pay me dogecoin!!!11!one!"), is there (or should there
> > be) any onus on the CA to respond to that notification within a certain
> > timeframe?
>
> CAs are required to make a preliminary incident report available within 24
> hours, including the “sod off your report is garbage”, as covered in 4.9.5.
Aha, I'd forgotten about that bit. That's pretty cut and dried.
> I ask this because I accidentally sent a couple of compromise notifications
> > with an incorrect URL. While one notification got what appeared to be a
> > human saying "we'll look into it" (which itself was sent more than 24 hours
> > after I received the corresponding auto-ack), others have been greeted with
> > complete radio silence (other than the auto-ack). This seems...
> > sub-optimal.
>
> Did you use the CPS documented problem reporting mechanism?
I've been using the "Report a problem" data from crt.sh, which is populated,
I believe, from CCADB. I just checked the CPS of the two CAs at issue, and
in both cases the initial reports were sent to the correct e-mail address.
- Matt
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
