his seems to be getting a lot closer. I have a few small issues remaining. 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? How much of the RFC5280 rules do I need to follow? 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. 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.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
