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.
