Logs MUST verify that the submitted end-entity certificate or
Precertificate has a valid signature chain leading back to a trusted
root CA certificate, using the chain of intermediate CA certificates
provided by the submitter. Logs MAY accept certificates that have
expired, are not yet valid, have been revoked, or are otherwise not
fully valid according to X.509 verification rules in order to
accommodate quirks of CA certificate-issuing software. However, logs
MUST refuse to publish certificates without a valid chain to a known
root CA.
Some clarifications would be useful:
Can a log reject a certificate for an EKU (e.g. rejecting code-signing or clientAuth certificates) as a means of reducing the risk of PII being logged.
How does a long a determine there is a 'valid' chain if one or more intermediates have been revoked?
Can a log define policies, such as validity period, to appropriately scope the growth of a log?
Can a log restrict or limit the use of name-constrained subCAs, to prevent spam/abuse?
RFC 6962, Section 3.1 states:
Some clarifications would be useful: