On 18/04/2020 23:39, Nick Lamb via dev-security-policy wrote:
I'm sure the client does understand revoked, but it won't (and
certainly shouldn't) _accept_ it, hence Ryan's choice of language.
Clients also understand expired OCSP certificates, and they don't accept
those either.
I'm a bit confused. I'm not sure I understand the point being made here.
Expired OCSP responder certificates would be an example of an artifact
produced by the CA in error if no newer OCSP responses were produced.
The relying party software would not treat such a response as a valid
statement from the CA, and would thus rely on the last statement which
is still valid. But a revoked response as part of an OCSP staple should
be understood (and the TLS session stopped) if the signature on the
response is proper.
I suspect that I'm simply unclear what the term "accept" means in this
context.
Presumably failure to adhere to that
agreement could place you in some contractual jeopardy?
What does "contractual jeopardy" mean here?
I guess a CA representative might chime in here to tell us if they've
sued any subscribers for not treating OCSP responses as a legal notice
that they must desist using a Private Key ? My firm guess would be "No,
this has never happened".
Again, I'm still not sure what point you are making here. Apologies for
being a bit dim - but because a legal right or responsibility hasn't
been enforced through court action doesn't necessarily negate the
existence of such rights and responsibilities. Surely a CA's signature
on an artifact (certificate, CRL, OCSP response) has got to mean
_something_. I don't think a OCSP response validly issued and with a
"revoked" certificate status can be taken to mean "This certificate with
this serial number may, or may not be, revoked and should be treated as
advisory until earlier OCSP responses have expired and this becomes a
repeated signed artifact". However, I think that I've probably
misunderstood the point being made; if so, I apologise and would be
happy to be corrected.
I readily admit that CAs make mistakes - sometimes certificates which
should be revoked aren't (in a timely manner), and I'd bet that some CAs
have revoked certificates which were not meant to be revoked. Yet I
still hold that a signature indicating that a certificate has been
revoked is binding on the CA, and (probably) on the Subscriber via the
Subscriber Agreement, which all CAs are _required_ to have as legally
enforceable instruments between certificate holders and the issuing CA.
I didn't mean to imply that "contractual jeopardy" is some hard and fast
legal term: I just meant that if you don't adhere to a binding
agreement, the non-adhering party could be in danger of acting
unlawfully and potentially subject to damages (presumably if they can be
qualified). Sometimes some Subscriber Agreements allow the certificate
holder to display some sort of seal owned by the CA - again, failure to
adhere to the Subscriber Agreement (i.e. by using the certificate post
revocation when the holder knows that it has been revoked) would negate
the right to continued display of the seal. I very much doubt that this
has actually been litigated, but I'm also pretty certain that displaying
trademarks without authorisation has been litigated.
Regards,
Neil
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
