Re: [Trans] Relaxing section 5.1

[Peter Bowen <[e-mail]>]

On Wed, Nov 2, 2016 at 1:08 PM, Brian Smith <[e-mail]> wrote:
> Peter Bowen <[e-mail]> 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