Hi, I am in support of sha256 only for uniformity and universal support.
+1 for Rob's comment regarding use of the "sha256" query string parameter for crt.sh URLs. I do think "https://crt.sh/?sha256=[hash]"; should probably be the recommended formatting, however simply specifying the sha256 hash should be allowed as to not require use of a specific website. I would suggest to disallow any other websites unless they use similarly obvious URL formats with a sha256 hash, or even disallow any outside of a list of approved log sites. (that could include crt.sh, censys, etc) The thinking I had here was that with something like the crt.sh URLs or just a list of hashes, it would be trivial to translate into your favorite cert viewer of choice with a simple regex or whatever. (in the case of list of multiple certs that could be annoying to deal with by hand) -Cynthia On Wed, Nov 17, 2021, 23:46 Ben Wilson <[email protected]> wrote: > 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 > > In section 5 of > https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report, 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 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 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://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaY5t3yMs2bVoGy-F%3D2_Tph__G%2BfLARXD3TxBZ7MJK97sw%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/CAKw1M3MrmGdEQRL838%2Botg0wxZvwRtLX0cj1b81HGgzVxxJ__w%40mail.gmail.com.
