Re: [Trans] Relaxing section 5.1

On Thu, Nov 3, 2016 at 1:29 AM, Peter Bowen <pzbowen@gmail.com> wrote:

> On Wed, Nov 2, 2016 at 1:08 PM, Brian Smith <brian@briansmith.org> wrote:
> > Peter Bowen <pzbowen@gmail.com> 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?
>
My answer to those is protocol simplicity:  6962-bis specifies the minimum
necessary to build CT logs servers and protocol for clients such that
Certificate Transparency can be implemented.

I actually like the idea of a ct-log-like service that would take partial
submissions and fix them and would be happy to help specifying such a
service. The CT team here has some open-source code for fixing chains
<https://github.com/google/certificate-transparency/tree/master/go/fixchain> on
which such a service could be based. Such a service (when not constrained
by the CT log interface) could be expanded to return multiple valid chains,
for example.

(It could be combined with a proxy submission service - a log-like
interface that takes an add-chain/add-pre-chain submissions and submits
them in parallel to multiple log servers, returning the
SCTList/TransItemList to be embedded in the final certificate or served
alongside it).

My point is that I see the value in automatically fixing submissions and
would happy to collaborate on specifying/building such a service, simply
pointing out it could exist independently of the log specification in
6962-bis.

> 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
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>