On Wed, Dec 26, 2018 at 9:10 AM Paul Wouters <[email protected]> wrote: > 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"?
You're misreading my text above. This text tells you *not* to log every certificate supplied to you. > 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. 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. > > 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. > 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. > > > 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 But there is a MUST here for clients, and so again, the boundaries of that MUST need to be clear. > > 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. -Ekr
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
