Without agreeing with some parts of the justification around OCSP, I
support the proposed changes and I believe they capture a fair meaning
of Firewall and router "activities".
I assume that the original authors couldn't decide on a minimum list of
specific events that should be kept by CAs regarding firewalls and
routers. For example, a router's CPU usage is a router activity, and
some CAs monitor and produce graphs of CPU usage, just like they do for
servers. However, there is no explicit requirement to capture the CPU
usage for Certificate Systems, therefore listing explicit events that
should be kept for firewalls and routers is very useful.
Thanks,
Dimitris.
On 13/9/2023 12:00 μ.μ., Martijn Katerbarg via Servercert-wg wrote:
Hi all,
During our last WebTrust audit cycle it became clear that our
interpretation of “Firewall and router activities” and CPA Canada’s
interpretation were meaningfully different. In particular it came to
light that in its most aggressive possible interpretation, the actual
logging of a firewall activity would itself constitute a firewall
activity, which would itself require logging, as would the log of the
log entry of that log entry, the log of this newest log entry, and
etcetera into infinity. In our opinion, too much “valid traffic”
logging, makes it harder to find “bad traffic”.
We offer a simple rewrite to reflect the difference between valuable
and necessary logged information and unproductive (and potentially
absurd) logging.
Similarly, several Certificate Consumers have expressed the wish to
move away from OCSP, while, depending on interpretation of the
language, CAs that do support OCSP may need to log every GET/POST
request for OCSP responses, and keep this data for at least 2 years.
The requirement for CAs to monitor OCSP requests is the product of a
different time, when thinking around OCSP was very different. As
privacy concerns and other structural weaknesses move the community
away from its position on OCSP, it no longer makes sense to include
requirements for CAs to watch and record OCSP requests.
Ballot SC-063 v4 madeit optional for CAs to provide OCSP at all. (We
recognize that there is still a root program requirement that
pragmatically prevents CAs from eliminating OCSP, but within the scope
of CABF requirements this is a critical change.) For the BRs to
strongly recommend (via this SHOULD requirement) monitoring OCSP is
incongruous and out of keeping with current thinking.
Even if we did want such monitoring to take place, any such
requirement would present serious and perhaps insurmountable technical
challenges:
For a typical OCSP responder that is only aware of unexpired
certificates, it's impossible to tell the difference between an
"unused" serial number and the serial number of an expired
certificate. To disambiguate would require the ongoing
cross-referencing of OCSP responder logs against the CA's cert
issuance logs, requiring additional code development and maintenance
and significant production overhead.
Furthermore, as most OCSP services are fronted by CDNs, there's no
guarantee that the CA will even have access to the full OCSP request
logs. If the CA can't enumerate all the IP addresses of OCSP clients
that send requests for "unused" serial numbers, then this vastly
diminishes whatever value we attribute to this monitoring requirement.
Our proposed changes are available for review on
https://github.com/cabforum/servercert/compare/main...XolphinMartijn:servercert:LoggingRequirements.
With this email I’m hoping to receive feedback and thoughts on this
proposal.
Regards,
Martijn
Sectigo
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
