On Wed, 26 Dec 2018, Eric Rescorla wrote:
> 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.
Where do you think it says that? What I see is text about chaining to a trust
anchor, not about certificates signed directly by specific CAs. And in this
case, there would be a chain of signatures to a trust
anchor.
Ahh I understand our differences now. I was thinking in terms of CA
signed, and not in the proper terms of "anchors to a trust anchor".
As for path length, the draft states:
Logs SHOULD limit the length of chain they will accept. The maximum
chain length is one of the log's parameters (see Section 4.1).
As you poined out, additional text is needed to cover denial of service
possibilities by EE-certs and intermediate CA's signing CA/EE certs
at (and beyond) the root anchor's path length or log max chain.
> (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.
The relevant MUST is the requirement to *reject* certificates in the following
paragraph.
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 valid signature chain to an
accepted trust anchor. Logs MUST also reject precertificates that do
not conform to the requirements in Section 3.2.
And what must clearly be delineated is the boundaries of that MUST.
Right, so likely a sentence should be added like:
Intermediate CAs used for validation to an accepted trust anchor
MUST pass all RFC 5280 verification rules, such as the Basic
Constraint path length and CA flags. Certificates failing these
constraints could be valid to be accepted to the log themselves
(eg as a valid intermediate CA or EE-cert), but signatures
created by these certificates MUST NOT be accepted as a trusted
chain to the log's trust anchors and therefor MUST NOT be
logged. This prevents bogus certificates from spamming the log.
Although possibly, instead of MUST NOT we could say "MAY temporarilly reject"
like the other DoS case.
> > > 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
But there is a MUST here for clients, and so again, the boundaries of that MUST
need to be clear.
The MUST tells you to validate, not to tell you exactly what to do when
validation fails. So it tells you that you cannot skip validating the
3rd SCT even if you only needed two according to your client policy. So
I still do not understand why you think this case is a problem.
> 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.
Great. Then the text should say that.
I'm not asking for a complete client specification. What I am asking is that
every normative requirement in this specification be unambiguous, and I do not
believe that this one is.
I think it does, but I guess it won't harm to make it more explicit. I'll
leave that up to the authors.
Paul
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
