[Trans] Certificate verification

[Linus Nordberg <[e-mail]>]

Hi list,

6962bis-4 says that logs may log and publish invalid certificates as
long as the chain ends in a known cert. It then lists three examples of
what can be accepted, all related to time.

   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.  If a certificate is accepted and an SCT issued, the
   accepting log MUST store the entire chain used for verification,
   including the certificate or Precertificate itself and including the
   root certificate used to verify the chain (even if it was omitted
   from the submission), and MUST present this chain for auditing upon
   request.  This chain is required to prevent a CA from avoiding blame
   by logging a partial or empty chain.  (Note: This effectively
   excludes self-signed and DANE-based certificates until some mechanism
   to limit the submission of spurious certificates is found.  The
   authors welcome suggestions.)

Since the purpose of the log is to put light on bad certificates, would
it make sense to instead have text 1) specifying a minimum of checks to
be done (i.e. the chain) and 2) encouraging logging and publishing of
all other certificates?


On a minor note, I think that "trusted" in the very first sentence
should be changed to "known. Should I use the issue tracker?