On Mon, Dec 24, 2018 at 3:52 PM Paul Wouters <[email protected]> wrote: > On Mon, 24 Dec 2018, Eric Rescorla wrote: > > Speaking as individual, > > > 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. 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? 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. > > 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 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. > 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. -Ekr
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
