On Wed, Nov 17, 2021 at 4:46 PM Ben Wilson <[email protected]> wrote:
> We are thinking of removing the reference to the "crt.sh ID" and > clarifying the instructions on providing the certificate fingerprints. > Instead of the crt.sh database ID, for instance, crt.sh currently supports > a lookup based on the SHA256 hash (https://crt.sh/?q=[sha256 hash]). > Currently, requiring a crt.sh ID implicitly ensures the full certificate data is actually available from a CT log. I find the portability and future-proofing argument for SHA256 fingerprints compelling, but I'm a bit concerned that in the rush to put an incident report together it'd be easy for a CA to copy-paste a fingerprint from an internal system into a crt.sh URL without ensuring the cert is actually logged and the URL actually works. This would primarily be an issue for CAs that only log precertificates and not final certificates to CT upon issuance. Without the final certificate's full data there's no way to map its fingerprint back to the corresponding precertificate, so other user agents' CT logging requirements do not mitigate this issue. Should it instead say, "The recommended way to provide this is to ensure > each certificate is logged to CT and then list the crt.sh fingerprint URL > for each certificate in the format 'https://crt.sh/?q=[sha256 hash]', > ...."? > It might be useful to clarify "logged to CT" - does it mean "logged to the CT log behind my sofa"? "logged to a CT log that crt.sh monitors"? "logged to a CT log trusted by $OTHER_USER_AGENT"? "viewable on crt.sh"? Like others, I can think of no compelling reason not to standardize on SHA256 fingerprints. Alex -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAN3-_m6V0sM09tWXu67-PErg52vfVbyyLHxw9NXe-AU9%2BuC_UA%40mail.gmail.com.
