Hi Mike,
On Fri, 13 Jun 2025, Mike Shaver wrote:
Right now there is nothing punitive about a CA?s responsibilities in the
face of CPS-related misissuance: the things required of them are
strictly remedial, being simply to correct the error they imposed on the
WebPKI's collection of valid certs. They don't even require revocation,
if the CA has chosen to structurally mitigate the risk of misissuance by
issuing Short-Lived certificates. There is nothing inflicting harm as an
attempt to balance the possible operational disincentive a
poorly-organized CA might have against performing appropriate
remediation. Even the prospect of distrust is remedial: if the CA can't
be trusted, they shouldn't be trusted.
What you're proposing is that we add something punitive, which means
that, I assume, you believe that we would need something to motivate
action that the CA might otherwise not take without the prospect of that
punishment. That motivational effect would not be equal across all CAs,
which means that the calculus of be-careful-or-pay would not be a
reliable means to get back to the important state: the WebPKI's corpus
of valid certificates being trustable *in all their details* by relying
parties. (I think that the focus on there being some commercial element
to issuance and trust would not age well either, given that a large and
quickly-growing portion of the web's certs are not issued on a
commercial basis. Who would get credits from Microsoft for their recent
misissuance? Another part of Microsoft?)
And - I'm sorry this is so long, but whatever - the proposed punitive
measure doesn't even make the PKI whole! You would still have certs
floating around with incorrect information, but the subscriber would
have a trivial credit against their next webinar about automation.
I understand how you get to that perspective, as there is a punitive
effect, undoubtedly. But then, forced revocation for an extra second of
validity just because the CP/CPS state "90 days" is also a punitive
effect. As you rightly state, there is no punitive intention to this
mechanism currently, and through my lense, there isn't one on the idea I'm
suggesting to explore.
To phrase it in what is hopefully a clearer way of expressing it, what I
am suggesting to explore is whether there would be benefits for Relying
Parties and as such the WebPKI ecosystem as a whole if we allowed CP/CPS
statements with the following structure:
Certificates conform to the BRs AND (X or Y).
Where X is a rather concrete statement about the certificate, and Y
describes what happens in a situation where a cert not conforming to X was
issued against the communicated intention of the CA. The totality of the
statement would still be enforced and subject to scrutiny as any CP/CPS
statement is today. And X and Y would have to be chosen in such a way to
not diminish the possible scrutiny.
The current model suggests something very binary. Certs conform, and if
they don't, they'll be revoked if detected. This already introduces a
margin of error.
My thought is that having a statement structured as proposed above gives
those Relying Parties who consume the CP/CPS for their trust decisions
additional data and signal. Indeed, it would be even less binary, but a
Relying Party going through the trouble of consuming the CP/CPS might use
this to gauge if this gives them sufficient trust in the likelihood of a
certificate conforming to X, as backed by Y, to accept the remaining
possibility of the certificate not conforming to X.
I don't presume what the outcome of that judgement would be for Relying
Parties, but I would assume it actually depends on their trust needs.
This is no more meant to introduce a punitive component than the forced
revocation is, instead it is meant to give Relying Parties additional,
possibly useful signal. It might be a bad idea, and I am thankful for
being able to discuss it here. But in my mind, it doesn't have the shape
you prescribe to it.
In fact statements of such form might well introduce additional signal to
the WebPKI ecosystem as a whole, and Browser Root Store Programs. The X
would show us what CAs consider possibly important constraints for their
subscribers, and the Y tells us their level of confidence in being able to
reliably adhere to it. I can't promise that it will be, but I'm proposing
it might be extremely useful, and by allowing CAs to make such statements
even in cases where they're not entirely confident would thus allow for
more (suggestedly useful) signal for Relying Parties, Browser Root
Programs and the WebPKI ecosystem in general.
If it is in the CA's interest to provide additional voluntary
constraints on their issuance, then it is because it is somehow in their
interest to do so. That could be because they are chartered to improve
the security of the web (would that they all were, tbh), or to
distinguish themselves in a competitive marketplace. They should not
pursue those things in ways that undermine the fundamental guarantee of
the WebPKI: the attributes of the certificate are true. Either way,
those constraints don't matter unless they can be relied on by RPs. And
if they are to be relied on then they need to hold for all valid
certificates, so?
Well they could be relied upon, but only in their totality:
Cert conforms to the BR AND (X or Y). That's not different. What's
different would only be the shape of the constraint.
CAs can - maybe, we'll try! - exceed BRs on their own initiative,
without any interaction with the BRs or its remedial mechanisms; just
don't put it in the CPS. Maybe the CAB/F can give out ribbons for effort
on the social event cruise, or provide badges for CAs to put on their
web sites and in email signatures. "__321__ days since a
commitment(*)-breaking issuance!"
And that's the point. As we have heard in this discussion, some CAs do. I
think that's something to welcome and support, and to possibly allow this
to take a form that's possibly even more accessible and useful to Relying
Parties than warm words and a ribbon on a CABF social event cruise.
But, again, I think this is a molehill and not a mountain. At best an
amusing distraction from pursuits that might actually *improve* the
reliability of the WebPKI, rather than make it even more complicated for
relying parties to navigate.
The state of WebPKI is indeed frustrating, and at times, the dynamic
between Broswers, the WebPKI community at large, mdsp participants and CAs
can definitely be described as antagonistic. And often, Browsers and the
community must stand firm to protect what's left of its integrity.
However, I am exploring if this is a case where that might not be
necessary. Even though it might not be our biggest problem, it might be
something where we can create progress without further fueling into that
antagonism, even if it might not be the biggest problem.
That said, I can appreciate that subscribers might not just fail to
understand why their certificates have to be revoked and replaced with new
ones which - as far as they can tell - seem substantially identical, but
even get angered by it. I can understand that CAs, when faced with such
subscriber's lack of understanding, ultimately know nothing better to do
than to point at the CA/Browser Forum, or Browser Root Programs. I can
understand that that's an uncomfortable position to be in. I can
understand that CAs want to avoid that through minimizing the commitments
they make. Again, my question is just: Can Relying Parties, Browser Root
Programs and the ecosystem as a whole benefit from making it possible for
CAs to make reduced but maybe still useful commitments in a transparent,
enforceable, and "weighted" fashion. And if we think that would be the
case - how would it need to be structured to avoid this turning into a
regression, because indeed, I wouldn't want to see actually meaningless PR
statements in a CP/CPS either.
Tobi
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/83bb127f-8ed1-7d8d-00e1-7762940113c4%40opera.com.
