Fantastic! I will say that Let's Encrypt used this format for our recent reports and going into the process knowing that we had a well-specified format that didn't require querying crt.sh for unique IDs made putting together the lists of affected certs very nice.
Aaron On Fri, Feb 18, 2022 at 10:29 AM Ben Wilson <[email protected]> wrote: > > I have updated the wiki instructions to read (new text in bold): > > 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. *It is also recommended that you use this form > in your list "https://crt.sh/?sha256=[sha256-hash] > <https://crt.sh/?sha256=[sha256-hash]>", unless circumstances dictate > otherwise.* > > https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report > > Ben > > On Thu, Nov 18, 2021 at 7:34 AM Rob Stradling <[email protected]> wrote: > >> > 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 >> <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]. >> 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/CA%2B1gtaahx1sifJ2uBKFiDn1Zvc1ijVohActmeHwxx2NCdW4TAg%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaahx1sifJ2uBKFiDn1Zvc1ijVohActmeHwxx2NCdW4TAg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEmnErfpnTpT7UKndn7Uk9yUUaBT2Hx-wcZ7-i627pE4NeWyhw%40mail.gmail.com.
