> 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]', ...."? Should > the SHA1 fingerprint also be allowed?
Hi Ben. This post is really just a comment about crt.sh usage rather than a substantive response to your question. For a general-purpose 'q=' search, crt.sh uses the following heuristic approach to determine the type of the search term: - if the search term can be parsed as a 64-bit integer, it performs an 'id=' search for a crt.sh ID; otherwise... - if the search term can be parsed as a "hex string" that represents precisely 20 bytes, it performs a 'sha1=' search for a SHA-1 certificate fingerprint; otherwise... - if the search term can be parsed as a "hex string" that represents precisely 32 bytes, it performs a 'sha256=' search for a SHA-256 certificate fingerprint; otherwise... - it performs an 'identity=' search. So 'https://crt.sh/?q=[sha256 hash]' will indeed find a (pre)certificate whose SHA-256 fingerprint matches '[sha256 hash]'; however, when a specific type of search term is intended, I encourage folks to quote crt.sh URLs that use the most specific search type that is applicable. In this case, what I mean is that I would encourage the use of 'https://crt.sh/?sha256=[sha256 hash]' URLs instead of 'https://crt.sh/?q=[sha256 hash]'. I'm not bothered about the extra CPU cycles that it takes for crt.sh to execute the heuristic approach described above. Rather, ISTM that a "?sha256=" URL is more self-descriptive than a "?q=" URL, and clarity is important. ________________________________ From: [email protected] <[email protected]> on behalf of Ben Wilson <[email protected]> Sent: 17 November 2021 22:46 To: [email protected] <[email protected]> Subject: Use of crt.sh ID in Incident Reports CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. All, In an incident report recently, there was discussion about the right way to report the certificates involved in the incident. See https://bugzilla.mozilla.org/show_bug.cgi?id=1736064<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1736064&data=04%7C01%7Crob%40sectigo.com%7Ca0ec7c114f9e448f306308d9aa1c28c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637727860185254459%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C7oayhfrH%2B9P5A0V3Y47e4HevY8FjMVyCOoaxxA7UeA%3D&reserved=0> In section 5 of https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.mozilla.org%2FCA%2FResponding_To_An_Incident%23Incident_Report&data=04%7C01%7Crob%40sectigo.com%7Ca0ec7c114f9e448f306308d9aa1c28c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637727860185264411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fcagnhsu5ARyhauQaptG%2BGcCDQUa9VN1cPN32ZKs4%2B0%3D&reserved=0>, it currently says, "5. In a case involving TLS server certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem." 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrt.sh%2F%3Fq%3D%5Bsha256&data=04%7C01%7Crob%40sectigo.com%7Ca0ec7c114f9e448f306308d9aa1c28c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637727860185264411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZedHWqgwh5ov8wi3QjTw4YOjxlw8xXZ6cHqo%2FTdQP6M%3D&reserved=0> hash]). 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrt.sh%2F%3Fq%3D%5Bsha256&data=04%7C01%7Crob%40sectigo.com%7Ca0ec7c114f9e448f306308d9aa1c28c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637727860185274367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rgeWfZVSlXzfkYeNBLcMg9vnoRVGGXiew9SWLbjjZcE%3D&reserved=0> hash]', ...."? Should the SHA1 fingerprint also be allowed? What is the preferred method, and which other alternatives should be allowed for unambiguously reporting / locating the certificates or their "complete certificate data"? Thanks, Ben -- 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]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaY5t3yMs2bVoGy-F%3D2_Tph__G%2BfLARXD3TxBZ7MJK97sw%40mail.gmail.com<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCA%252B1gtaY5t3yMs2bVoGy-F%253D2_Tph__G%252BfLARXD3TxBZ7MJK97sw%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Crob%40sectigo.com%7Ca0ec7c114f9e448f306308d9aa1c28c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637727860185274367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EsiLZ4nMkthhiCzRc7IaP9wdQe%2FVB%2F%2BkRekYmX0DgCI%3D&reserved=0>. -- 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/MW4PR17MB4729197679DA013A8677EBEDAA9B9%40MW4PR17MB4729.namprd17.prod.outlook.com.
