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. 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. So I am not sure what else needs to be clarified on validity window?
How much of the RFC5280 rules do I need to follow?
I believe the WG wanted to accept _everything_ signed by the CA the log accepts certs from, irrespective of their invalidity or broken content. 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. The general case, log as much as you can even if it violates 5280 rules, should really be implemented, as we do want to see all those mis-issuances in the logs. That's what these distributed audit logs are for. I don't see what other clarifications or new text is needed.
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. 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? To me it seems prudent to fail the validation in that case. So the text seems correct and complete. Are there any implementers concerned that they would not detect this because they wouldn't look at the SCT if the policy doesn't require it? And so would prevent them from honoring the MUST in this section?
COMMENTS S 6.5. > o The TLS server sends a modified Certificate message (as described > in section 4.1 of [RFC7924]). > > If the "hash_value" of any "CachedObject" of type "ct_compliant" sent > by a TLS client is not 1 byte long with the value 0, the CT-using TLS > server MUST abort the handshake. Note: this isn't really a hash, so we should probably acknowledge that.
Sure, I think one of the author's can clarify that. Paul _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
