Subject: [Trans] Relaxing section 5.1

From: Peter Bowen <[email-masked]>
Date: Tue, 1 Nov 2016 19:19:40 -0700

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.  For
example, a log operator might want to add a feature to accept
certificates which have incomplete chains and have the log add the
missing links from data it already has or a log operator may want to
allow logging of certificates that are also published for DANE with
TLSA records with certificate usage 2 or 3.  It feels very restrictive
to require that every log only accept certificates that follow the
traditional hierarchical PKI model.

I can see value in providing guidance of what a log MAY want to do.
However requiring such seems to limit the potential of transparency in
undesirable ways.

Thanks,
Peter

---

From: Eran Messeri <[email-masked]>
Date: Wed, 2 Nov 2016 11:10:17 +0000

This is a really good question, in that I can see why some log operators
would like to set their own policies for accepting certificates into the
log.

Each of the potential policies I've personally encountered, though, seemed
unique - there wasn't a common set of parameters that could be standardized.

Not specifying, in a standard manner, which submissions should be accepted
by a log will make it difficult to (1) check a log implementation for spec
compliance (2) clients to figure out where they should submit their
certificates to or why submissions are rejected. The current text makes it
very straightforward for a client to figure out if their submission will be
accepted by a given log (overall makes the protocol very simple).

I think (and I may be wrong) that there's still flexibility in allowing the
log to control the accepted submissions in a fine-grained manner by being
selective about the trust anchors used - the trust anchors do not have to
be root certificates, they could be intermediates.

What I wrote above only applies to server certificates - with other uses,
such as DANE, there may be other aspects of 6962-bis that are not suitable.
Given lack of concrete interest in using Certificate Transparency logs* for
certificates other than server certificates I don't know how much sense
it'd make to account for them in 6962-bis.

To be clear: I am not opposed to relaxing section 5.1 (and there are
arguments for changing the MUST to a SHOULD so that a log that drops
submissions for DOS protection, for example, is not considered
non-compliant). My argument is that if we relax it, it should be done in a
well-defined way such that a client implementation will not have to rely on
unspecified knowledge / external metadata to figure out which logs will
accept its submissions.

Eran

* - There's plenty of interest in transparent logs / verifiable data
structures, but those projects utilize the underlying data structure and
general concepts, but are not tied to the -bis protocol/specification.

On Wed, Nov 2, 2016 at 2:19 AM, Peter Bowen <[email-masked]> wrote:

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 2 Nov 2016 05:39:16 -0800

Hi, all:

6962-bis has completed working group last call.  Minor editorial
changes are fine, but let's try to avoid major changes that would
require yet another WGLC.  If there's a need for an additional
document dealing with operational considerations or operational
specifications, we can do that.  If there's a major problem with
6962-bis, we can deal with that as well, but it would need to
be serious (i.e. goes to the correctness of the specification,
fixes something that's broken, etc.).

Thanks,

Melinda

---

From: Peter Bowen <[email-masked]>
Date: Wed, 2 Nov 2016 07:08:45 -0700

> fixes something that's broken, etc.).

I realize that 6962bis has passed WGLC, so I know there is a high bar
for changes.  However I think this might pass that bar.  The highly
restrictive language that imposes minimum policy for logs prevents
interoperability with other IETF RFCs on the standards track very
hard.  6962bis appears to assume that DANE (RFCs 7671 and 6698) will
never be implemented and that concepts like RFC 6091 will never come
to fruition.

By requiring all logs MUST accept any certificate that chains to a
root in the log's root list, 6962bis fails to allow log operators to
mitigate any Denial of Service attacks mounted by attempting to log
massive numbers of certificates that are not relevant to the log
scope.  For example, many existing certification authorities issue
both server authentication certificates and certificates for personal
identification.  For some roots, acquiring large numbers of these is
relatively easy (see discussion of fetching millions of Taiwanese
Citizen Digital Certificates in
https://smartfacts.cr.yp.to/smartfacts-20130916.pdf).  As written
today, a log MUST accept these.  There is no option for a log to
require that all certificates must meet some usability criteria.

I agree that a future additional document dealing with operational
considerations is fine, but as drafted today, 6962bis does not allow a
log to implement these considerations.

Thanks,
Peter

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 2 Nov 2016 12:51:18 -0700

> never be implemented and that concepts like RFC 6091 will never come

To further expand on Peter's question regarding Section 5.1, as
presently specified, it shifts a significant burden to log clients
submitted certificates that might otherwise be addressed by log
flexibility.

Consider a CA which it itself a trust anchor (root cert) and has a
certificate cross-signed by another trust anchor (cross-sign). One log
may directly support the root, another log may only support the CA
issuing of the cross-sign.

One interpretation of the text is that "using the chain of
intermediate CA certificates provided by the submitter" means that
only the first log can be used, and that the second log cannot perform
any path building to determine that the cross-sign exists. As such, a
client submitting certs must have full knowledge of the PKI graph,
prior to submission, to determine which logs it can use, and logs are
prevented from using their knowledge.

Another interpretation is that the chain of intermediates is merely a
'hint', and may be discarded by the log when evaluating the path. This
would at least resolve some of Peter's concerns, but not all. The core
of this is the question regarding the MUST level requirement, and
whether that language unduly restricts possible implementations in a
way that may prevent standards adoption.

---

From: Brian Smith <[email-masked]>
Date: Wed, 2 Nov 2016 10:08:43 -1000

Peter Bowen <[email-masked]> wrote:

> 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/

---

From: Peter Bowen <[email-masked]>
Date: Wed, 2 Nov 2016 18:29:57 -0700

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

---

From: Eran Messeri <[email-masked]>
Date: Thu, 3 Nov 2016 09:34:58 +0000

On Thu, Nov 3, 2016 at 1:29 AM, Peter Bowen <[email-masked]> wrote:

> own
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.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 3 Nov 2016 10:28:57 +0000

> However requiring such seems to limit the potential of transparency in

The problem this was designed to address was that a) knowing of a bad
certificate is not all that useful unless you also know who issued it, b)
without chaining to some responsible party, it is unclear how to prevent
DoS on the log by filling it with nonsense certificates.

Technically, I guess, the requirement could be that what is _logged_ MUST
blah blah, but then that leaves open the question of how to construct such
a chain (which is not standardised).

In any case, it seems to me that if a log operator wanted to offer a
service to construct chains, it would be trivial to have a different
end-point that would accept partial chains, attempt to fix them, then
submit them to the log.

Also, we do provide code for repairing chains:
https://github.com/google/certificate-transparency/tree/master/go/fixchain.

Which fixes your first case. The second case sounds more like a job for
DNSSEC Transparency...

---

From: Ben Laurie <[email-masked]>
Date: Thu, 3 Nov 2016 10:31:50 +0000

> require that all certificates must meet some usability criteria.

The requirement is to reject certs that don't meet the criteria, not
to accept those that do.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 3 Nov 2016 10:33:47 +0000

BTW, its probably smart to design a more general transparency standard
and then have profiles for different use cases. But we did decide not
to do that until we had other examples of transparency (I'm building
one right now, as it happens, and it is not the only one I am aware
of).

---

From: Peter Bowen <[email-masked]>
Date: Thu, 3 Nov 2016 07:01:02 -0700

> The requirement is to reject certs that don't meet the criteria, not

So the root list is just "advisory" -- I could include roots where my
local policy results in rejecting all certs chained to that root?  Or
I could follow Brian's template and reject all and later add to the
log via some other API (or have some rule like "client IP address must
be 127.0.0.1" in order to get a cert logged)?  These would all be
6962bis compliant?

Thanks,
Peter

---

From: Ben Laurie <[email-masked]>
Date: Fri, 4 Nov 2016 13:33:09 +0000

> be 127.0.0.1" in order to get a cert logged)?  These would all be

I was just reading what the language you quoted says. I don't actually
have the whole of 6962bis in my head right now.

The bit you didn't quote does say they the log has to accept valid
certs, tho: "Logs MUST accept certificates and precertificates that
are fully valid according to RFC 5280 [RFC5280] verification rules and
are submitted with such a chain."

---

From: Peter Bowen <[email-masked]>
Date: Fri, 4 Nov 2016 07:07:50 -0700

> are submitted with such a chain."

Sorry about that.  So the three MUSTs together are:

- 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 accept certificates and precertificates that are fully
valid according to RFC 5280 verification rules and are submitted with
such a chain.

When I read these together, I read that Logs must accept _any_
certificate that is fully valid according to RFC 5280 verification
rules and chains to any root the log trusts and logs must _only_ log
such certificates (and no others).

If this is accurate, we need to account for all types of certificates
being logged, as a log cannot choose to reject certificates for usages
other than server authentication and the log cannot reject
certificates that have personal information (e.g. an server
authentication certificate that states which human requested the
certificate in the subject).

This seems like a very strong assertion of policy rather than a
technical discussion of how the CT protocol works.  I would again ask
the WG to reconsider the requirement levels specified in this section.

Thanks,
Peter

---

From: Ben Laurie <[email-masked]>
Date: Fri, 4 Nov 2016 15:42:23 +0000

> the WG to reconsider the requirement levels specified in this section.

FWIW, I tend to agree. I would also note that operationally, we have
already discussed options for logs that are incompatible with these
requirements, for example:

* sharded logs (e.g. by hash(cert) mod n).

* logs that only accept short or long lifetime certificates (this
would allow the working set to be reduced in size for CAs that issue a
lot of short-lived certs).

---

From: Eran Messeri <[email-masked]>
Date: Wed, 16 Nov 2016 11:00:31 +0900

My proposed compromise at the trans workgroup meeting yesterday was to
change the MUST in the following paragraph to a SHOULD:
"Logs MUST accept certificates and precertificates that are fully valid
according to RFC 5280 verification rules and are submitted with such a
chain."

I believe that this change allows creating logs that can reject valid
submissions under some circumstances while complying with 6962-bis. And we
wouldn't have to go through WGLC again for such a change.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 16 Nov 2016 11:26:26 +0000

> wouldn't have to go through WGLC again for such a change.

This seems like a reasonable plan (mildly surprised such a change can
be made without WGLC, tho!).

---

From: Eran Messeri <[email-masked]>
Date: Thu, 17 Nov 2016 21:21:39 +0900

FYI this is the change to the draft:
https://github.com/google/certificate-transparency-rfcs/commit/bf6603e10affbee97b07e33265494efbd07c833f

In addition to the change from MUST to SHOULD, I've added an example as to
why the a log may chose to reject valid submissions.

Eran