Subject: [Trans] Section 5.1 (Accepting Submissions) revision

From: Peter Bowen <[email-masked]>
Date: Sat, 4 Jun 2016 12:01:19 -0700

Section 5.1 has a requirement that a log MUST only accept certificates
(or precertificates) that include a full valid chain to a trusted root
in the submission.  This appears to exclude any option for a log to
have a priori knowledge of intermediate CAs and accept submissions
with incomplete chains.  It also means that the log cannot decide to
accept certificates that are incorrectly constructed by the CA.

I would suggest the following alternative for the first paragraph of 5.1:

Logs SHOULD 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 accept certificates and precertificates that are fully valid
according to <xref target="RFC5280">RFC 5280</xref> verification rules
and are submitted with such a chain. Logs MAY accept certificates and
precertificates that have expired, are not yet valid, have been
revoked, or are otherwise not fully valid according to RFC 5280
verification rules in order to accommodate quirks of CA
certificate-issuing software. However, logs MUST reject submissions
without a known valid signature chain to an accepted trust anchor.
Logs SHOULD also reject precertificates that do not conform to the
requirements in <xref target="Precertificates"/>.  Logs MAY accept
objects other than certificates and precertificates that have a known
valid signature chain to an accepted trust anchor.

Thanks,
Peter

---

From: Ben Laurie <[email-masked]>
Date: Sat, 4 Jun 2016 23:17:07 +0100

> valid signature chain to an accepted trust anchor.

I think this is all getting too complicated and in the wrong direction.

The intent of this section was that logs should have some mechanism to
control spam. We (the authors) had decided that the mechanism was going to
be "issued by a trusted CA" for some value of "trusted", which is fine, but
should not have been enshrined.

The intent is that logs should contain information that may or may not be
of interest to you. They are not arbiters of truth or correctness (other
than their own honesty). Spam makes logs difficult to use, so they need a
spam control mechanism. But we should not mandate what that mechanism is.

Yes, I am saying my own I-D is wrong. :-)

I think the fix is to say that logs should take measures to limit their
size, e.g. "chains up to a trusted CA", but not mandate what that mechanism
is.

Browsers, monitors, etc, can make up their own minds what a reasonable size
for a log is. Presumably something not wildly different from the size of
the set of certs they are interested in.

> Thanks,
> Peter
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Paul Wouters <[email-masked]>
Date: Sat, 4 Jun 2016 18:19:52 -0400

As long as it chains to a valid root, wouldn't we want to log it? So we become aware of previously unknown intermediates?

Paul

Sent from my iPhone

> On Jun 4, 2016, at 15:01, Peter Bowen <[email-masked]> wrote:
>

---

From: Peter Bowen <[email-masked]>
Date: Sat, 4 Jun 2016 15:50:22 -0700

On Sat, Jun 4, 2016 at 3:17 PM, Ben Laurie <[email-masked]> wrote:
> The intent is that logs should contain information that may or may not be of
> interest to you. They are not arbiters of truth or correctness (other than
> their own honesty). Spam makes logs difficult to use, so they need a spam
> control mechanism. But we should not mandate what that mechanism is.
>
> for a log is. Presumably something not wildly different from the size of the
> set of certs they are interested in.

Ah, good.  My preference is that the I-D/RFC only discuss the
technical details and leave policy to the log operator.  Given that
the doc is in last call, I was trying to take a compromise approach by
leaving in most of the existing text.

What about just removing the whole first paragraph?

Thanks,
Peter

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Jun 2016 15:59:30 -0400

Ben,

I disagree with the suggestion to relegate all "spam" control mechanisms to
per-log, locally-determined controls. This is another example of 6269-bis
not being written as a standard, but as just a set of guidelines. Allowing
another way for logs to behave in a fashion that is not predictable by 
log clients,
except, perhaps, by trial and error, is not, IMHO, a good idea.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 8 Jun 2016 12:45:52 +0100

On 7 June 2016 at 20:59, Stephen Kent <[email-masked]> wrote:

> another way for logs to behave in a fashion that is not predictable by log
> clients,

The point here is to allow logs to be more liberal in what they accept,
which is surely a benefit? Logs should still be required to accept
well-formed chains to known roots, that I definitely agree with.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Jun 2016 14:41:38 -0400

Ben,

Jon Postel's adage is generally a good idea for interoperability, in 
general.
I thought the suggestion here was to suggest that logs may impose other 
criteria
on submissions, e.g., chain length to a set of known (hopefully 
advertised) trust anchors,
and that these criteria would not be easily known by submitters.

perhaps I misunderstood the suggestion.

Steve

>
> ...
>
> The point here is to allow logs to be more liberal in what they 
> accept, which is surely a benefit? Logs should still be required to 
> accept well-formed chains to known roots, that I definitely agree with.