Peter Bowen <[email protected]> wrote: > Currently 6962bis section 5.1 says: > > "Logs MUST verify that each submitted certificate or precertificate > has a valid signature chain to an accepted trust anchor, using the > chain of intermediate CA certificates provided by the submitter. [...] > logs MUST reject submissions without a > valid signature chain to an accepted trust anchor. Logs MUST also > reject precertificates that do not conform to the requirements in > Section 3.2." > > Is there a reason this is enshrined as a MUST? It seems like it > should be up to the log operator to determine their policy.
The log can reject the submission (return a non-2xx response) and still incorporate the certificate into the log, especially if it can build its own path to a trust anchor it trusts. The only thing that the log is prohibited from doing is giving the submitter a 200 response with an SCT when the submitter supplies an incomplete/untrusted chain. In particular, the log can reject a submission (with a non-2xx response) but then re-submit the same certificate to itself with a different certificate chain (returning a 2xx response). A log can store rejected submissions in a holding bin for later self-submission when new intermediates are discovered and/or new roots are trusted. Note that when people query the log using get-entries, the log shouldn't return certificates it has never been able to build a valid chain for, by default, I think. Otherwise the system doing the querying might be DoS'd with untrusted certificates. But, it is probably a good idea to have a way to query rejected/not-yet-trusted submissions too. Cheers, Brian -- https://briansmith.org/
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
