On 16/04/2020 14:49, Kurt Roeckx via dev-security-policy wrote:
On 2020-04-16 14:56, Neil Dunbar wrote:
I would have thought that an OCSP-stapling implementation which got
an OCSP status code 'successful' (0) with a 'revoked' status for the
certificate would want to pass that on to the client, replacing any
prior OCSP successful/status-good report, whether that prior report
was still valid.
As owner of the certificate, I think you actually don't want to do
that, because things will stop working. If it's revoked you want to
get a new certificate, and as long as you don't have the new one, you
want to use the old certificate and staple the good OCSP response.
Really? Continue to use a certificate in the (more recent) knowledge
that the issuing CA has disavowed it? I know that will work from the
perspective of the TLS protocol, but it might be the sort of thing which
would run afoul of the owner's subscriber agreement. So, if the CA
operated on a purely customer-enforced OCSP-stapling approach (ie,
didn't publish the OCSP URI in the end certificate), that would mean the
relying party would have no reasonable way to validate whether the
certificate even _could_ be trusted.
I mean - I see what you're saying: you have a website which you want to
keep working until you replace your certificate and/or private key. But
if I had signed knowledge from the issuing CA that (for instance) my
private key was compromised, I don't think it would be terribly ethical
to continue its use; depending on your subscriber agreement it might not
even be lawful. It seems like you are materially misrepresenting the
state of your certificate to the detriment of your relying parties.
Regards,
Neil
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
