If the purpose of the Web PKI is to bind a DNS name to a public key then why not allow the domain owner to decide if they accept a particular binding as expressed in a certificate?

It is clear that the Web PKI is only intended by the browsers to support TLS. Therefore retrospective changes to a certificate are irrelevant from the point of view of the client.

This would mean that for a validation failure re-verifying now would allow those subscribers to avoid the need to revoke a certificate. It would be possible for a subscriber in light of one of these incidents to submit the the same CSR again, meaning the revoked and replacement certificate convey the same binding making the revocation an exercise in compliance rather than removing a binding which is contrary to the intent of the person who controls the name.

The point of the Web PKI is to convey a public key approved by some party authorized represent some name to a client. The paperwork for CAs is to hopefully avoid them accepting a binding from anybody but the person who controls a name. If the person who controls a name is happy with a certain binding existing why is it anybody else's business what that binding is?

Another option would be to give these most likely large organisations with hard to replace certs a sub ca with critical name constraints, the BRs applicability should be re-scoped to stop at the sub-ca certificate. If the organisations chose to operate this sub-ca poorly then that is their problem as they cannot only affect the security of connections to their names.

For some organisations like banks I think it would in fact be preferable if they only the CA controlled by them could ever issue for their domains, as when you go to their domain what you want is your bank not whoever controls the domain name.

On 15/07/2024 22:22, 'Tim Hollebeek' via [email protected] wrote:
Hello,

I wanted to run an idea past the Mozilla community that's sort of
half-baked, but maybe the community can help flesh it out.  This is mostly a
personal idea of mine at this point, but if there is enough interest /
support it might become a DigiCert initiative.

The idea is motivated by the idea that it's absolutely impossible to
determine with any confidence whether a particular certificate can be
replaced within a 24 hour or a five day period (unlike many of the
participants whose experience here is hypothetical, I've done my time in the
trenches).  Many customers can safely replace, with various degrees of
expense and effort, but many customers can't replace safely, and the
incentives all point in the wrong direction, so getting reliable information
to make determinations is a real challenge, and very time consuming.  And as
much as I love crypto agility, not having anyone get hurt or die is also
pretty high on my priority list.  And there are some cases where that's
exactly what's on the table.

As I stated in Bergamo, instead of trying to apply band-aids to this very
broken process, I think we need to entirely rethink how we do things in
order to make any progress.  So I'm going to start throwing out some ideas
that might work, and maybe we'll eventually converge on a solution that has
a chance of working.  Because the current system doesn't.

This is just the first of a bunch of proposals, so here we go:

If a publicly-trusted certificate is difficult to replace, for various
regulatory or technical reasons, the real reasons do not magically appear
when rotation is necessary.  But a host of fake reasons are likely to arise
("we can't rotate certificates faster because it costs money we don't want
to spend").  Furthermore, making progress on this problem would be greatly
assisted by better information about exactly which certificates can't be
replaced, the timescale on which they CAN be replaced, and why.

The world would be better if we all knew, IN ADVANCE, which certificates are
automatically replaceable, and which aren't.  This would also greatly
streamline operations when replacements are necessary, as it removes the
burden on making the determinations with a ticking clock, which is a
situation that doesn't lend itself to careful and unbiased evaluations.

This would make things better in a number of ways:

1.      For organizations that do use automation, or are able to deal with
the agility requirements, the certificates just get revoked on the agreed
upon timelines.  No discussions, no exceptions.  This would be the standard
way certificates work going forward.
2.      For organizations that can't, we would have transparent information
about the existence of the issue, the nature of the problem, and the
severity (feasible timeline).  This would aid in efforts to evaluate an
implement methods to reduce the scope and severity of the WebPKI agility
issues.  Currently, we never find out about these issues until replacement
is needed, and at that time it's too late to do anything.
3.      Once the information is available, it will be much easier to have
reasonable discussions about the nature and distribution of problems, what
the root causes are, and how various regulations and industry practices can
be changed to encourage and enhance crypto agility, instead of holding it
back.
4.      And furthermore, it would be better if these disclosures came
directly from the subscribers, because they are the only ones in a position
to know the ground truth.  Subscribers could be held publicly accountable
for the accuracy and reasonableness of their determination and need.
5.      Hopefully, the need to declare their inability to rotate
certificates would "encourage" organizations to improve their crypto agility
until they no longer needed to appear on the list of people holding back
WebPKI agility.  It would also allow requirements to be written about what
practices are acceptable and what aren't, and compliance with timelines to
move away from questionable practices could be monitored easily.

The information could even be contained in a certificate extension, so that
the rotation practices of these organizations is transparent.  That would
then make it possible to track the effectiveness of initiatives to reduce
the barriers to rotation of WebPKI certificates.  There's even a chance we
could actually use the information to make revocation and rotation better,
instead of just arguing about it on internet forums!

One potential downside is that this would make critical certificates stick
out like a sore thumb, but I think on balance, the transparency is more
valuable than the disclosure risk.  I've never been a huge security by
obscurity fan, anyway.

I realize this would be a major change to how we do things, but we've been
having this exact same conversation about certificate replacement for pretty
much the entire decade I've been involved at CABForum, and I think it's time
for radical change.  If this isn't the right idea, it at least gives a sense
of the kind of change that is needed to make progress here, and I would love
to hear any other potential ideas for how we finally exit the traffic circle
and start moving forward again.

-Tim


--
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 on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/899b99cc-bf45-4670-82db-9a455c044b3d%40eigenvector.org.uk.

Reply via email to