On Wed, Nov 2, 2016 at 1:08 PM, Brian Smith <[email protected]> wrote: > 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.
Right, but why? If the log can fix it up on the fly, why not return a SCT? Why can a log not include a certificate it finds acceptable even if it can't link it back to a root? Why should a log have a separate store of certs for "future submission" instead of logging them directly? I see the worry about spam, but this would seem to be a greater risk for the log operator than anyone else. After all the log has to store all the data and transfer it to all the clients, so their bandwidth usage is far greater than any given client. Thanks, Peter _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
