Hi Ben, Thanks for opening up this discussion.
Regarding your questions: *1) 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://crt.sh/?q=[sha256> hash]', ...."? * For those CA operators currently submitting crt.sh IDs, I would imagine the transition from ID to SHA256 hash would simplify the reporting process, and in turn, would be well received. >From a root program perspective, our interests are focused on allowing for an unambiguous method of identifying and facilitating access to problematic certificates. For some additional perspective, as I've been ramping up in my new role, I've appreciated how easy it's been to review historical incidents on Bugzilla and quickly follow crt.sh ID hyperlinks to the corresponding certificate records. If for whatever reason, crt.sh was unavailable or unavailable to serve specific records in the future *(hopefully just a hypothetical situation)*, the historical value of past these discussions, at least as I've observed them, would be diminished. In this regard, the transition to using the SHA256 hash as an identifier from crt.sh ID would at least offer some degree of future-proofing. *2) Should the SHA1 fingerprint also be allowed?* +1 to Corey's comment regarding standardizing on SHA256. Thanks again! - Ryan On Thu, Nov 18, 2021 at 9: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/MW4PR17MB4729197679DA013A8677EBEDAA9B9%40MW4PR17MB4729.namprd17.prod.outlook.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729197679DA013A8677EBEDAA9B9%40MW4PR17MB4729.namprd17.prod.outlook.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/CADEW5O8EJ4sw7sP7wEP2X3fJVRgzd63RsUsgGyi%2B0tb3C17MtA%40mail.gmail.com.
