On Mon, 24 Dec 2018, Eric Rescorla wrote:
> IMPORTANT
> S 4.2.
> > To ensure that logged certificates and precertificates are
> > attributable to a known trust anchor, and to set clear
expectations
> > for what monitors would find in a log, and to avoid being
overloaded
> > by invalid submissions, the log MUST NOT accept any submission
until
> > it has verified that the submitted certificate or precertificate
> > chains to an accepted trust anchor.
>
> I think the rules still have to be clarified a bit here. E.g., does it
> have to be within validity windows?
The goal was to log as much as possible.
Logging as much as possible would involve logging every certificate, valid or
not. In fact, this text explicitly tells you *not* to do that, even if you
practically could do so.
Where does it "explicitely tell you" to "log every certificate"? All
of this is predicated on logging the behaviour of one or more CAs. So
that's clearly a limiting factor on what to accept.
The log is meant to log _everything_ signed by the CAs for which it logs.
Any data that is so bogus that you cannot determine if the CAs your log
for have signed it, can obviously be rejected.
The only exception to not logging data that has been signed by the CA,
is during a denial of service attacks on the log. So all the reasons
to refuse have to do with the _amount_ of logging, not the _content_
of what is logged.
It does not say "validated an SCT or certificate" based on acceptable
content. It says "until it has verified [...] chains to an accepted
trust anchor".
The text states:
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.
Ah, I thought I remembered this text but didn't see it. What about chains in
which a properly-issued EE cert signs another EE cert?
The logs will only log data signed by certain CAs. If the CA signed the
EE cert, it goes in. If that EE cert signed another EE cert, it was not
signed by the CAs being audited and does not go in. Just like
self-signed EE-certs don't go in.
If there is enough structure to check the signature and it validates, it
should be logged. Possibly for the above quoted reasons, if the validity
times cannot be read from the data, it is probably safe to not add it to
the log to prevent spamming the log. Especially since browsers that
cannot read the validity would also never accept the certificate. But
a log may temporarilly halt submissions from a new CA as well:
(A log may decide, for example, to
temporarily reject valid submissions to protect itself against
denial-of-service attacks).
So perhaps this corner can be left to local policy of the log operator.
Unfortunately, no. This is a 2119 MUST and therefore the boundaries of the
mandate need to be precisely delineated.
The MUST is not violated by _temporarilly_ halting logging as the text
describes.
> S 8.1.3.
> >
> > In addition to normal validation of the server certificate and
its
> > chain, CT-using TLS clients MUST validate each received SCT for
which
> > they have the corresponding log's parameters. To validate an
SCT, a
> > TLS client computes the signature input by constructing a
"TransItem"
> > of type "x509_entry_v2" or "precert_entry_v2", depending on the
SCT's
>
> How do I proceed if I have an invalid SCT but by policy I would accept
> the certificate if the SCT had been omitted.
The section quoted tells you what to do with invalid SCT's, namely fail
the validation.
This text does not tell you to fail validation of the certificate; it tells you
you MUST validate all the SCTs and then doesn't tell you how to behave if one
does not validate.
I believe the actions of what to do on validation failure are a local
policy. It could be a total rejection, a popup etc. While 6962bis gives
guidance for CT-using TLS clients, it is not a client specification
document. See also: https://trac.ietf.org/trac/trans/ticket/15
I suspec your real question is if that is the right thing to do when
SCT's were not mandatory as policy for the CT-using clients?
No, that's not my question. Consider the case where my policy is that there
must be 2 valid SCTs and the server supplies 3 but only 2 validate. I'm
required to validate all of them, but I could conform with
this text by validating all three, logging the failure, and moving on.
That behaviour is up to the client implementation and/or local policy.
To me it
seems prudent to fail the validation in that case. So the text seems
correct and complete.
Well, you and I seem to disagree about the meaning of this text, so apparently
not.
Anyone can make any statement for any arbitrary line of text, so tis argument
is a non sequitur.
Speaking as an individual, I still do not see any text requiring changes.
Speaking as co-chair, we did try to get a client behaviour document
started, but at first waited for the bis document to be in better shape,
and later on there was not enough interest at the time. For example,
there is this expired draft:
https://tools.ietf.org/html/draft-dseomn-trans-browsers-01
Although that one also does not answer your question:
However, A TLS client that is a browser MAY discriminate against a
certificate presented for a web site if the certificate is not
accompanied by an SCT, e.g., providing an indication of this via the
user interface. The details of such discrimination are outside the
scope of this specification.
Paul
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
