Hi Ben, Comments inline.
> 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=%5bsha256> hash]', ...."? The current language on the Wiki doesn’t explicitly “encourage” the use of crt.sh (one can list fingerprints and not provide them in a crt.sh URL), whereas this proposal does. Not to besmirch crt.sh (it’s a great tool), but I don’t think we should recommend the use of a single tool over an interoperable solution. Namely, we should encourage listing SHA256 fingerprints and leave it to the reader to supply those fingerprints to the tool of their choice, whether that be crt.sh, Censys, or something else. > Should the SHA1 fingerprint also be allowed? I think we should encourage the use of SHA256 fingerprints and discourage other hash algorithms. Popular tooling (crt.sh, Censys, etc.) supports SHA256 fingerprints, whereas support for other algorithms may not be as universal. > What is the preferred method, and which other alternatives should be allowed > for unambiguously reporting / locating the certificates or their "complete > certificate data"? An alternative method would be to allow the specification of a CT log’s base URI and the entry number of the affected certificate. Uptime of CT logs is monitored by at least one Root Program, which provides assurance that the certificate can be retrieved. Additionally, retrieving the certificate is done in a documented, standard manner (any CT client can fetch the certificate). Thanks, Corey From: [email protected] <[email protected]> On Behalf Of Ben Wilson Sent: Wednesday, November 17, 2021 5:47 PM To: [email protected] <[email protected]> Subject: Use of crt.sh ID in Incident Reports 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 <https://crt.sh/?q=%5bsha256> 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://crt.sh/?q=%5bsha256> 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] <mailto:[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://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/DM6PR14MB218664FE438472CE45649A52929B9%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
