Re: PEM of root certs in Mozilla's root store
On 2020-10-15 04:52, Ryan Sleevi wrote: On Wed, Oct 14, 2020 at 7:31 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Only the CSV form now contains CSV artifacts. And it isn't really CSV either (even if Microsoft Excel handles it). Hi Jakob, Could you be more precise here? Embedded new lines within quoted values is well-defined for CSV. Realizing that there are unfortunately many interpretations of what “well-defined for CSV” here, perhaps you can frame your concerns in terms set out in https://tools.ietf.org/html/rfc4180 . This at least helps make sure we can understand and are in the same understanding. For example, embedded new lines are discussed in 2.6 and the ABNF therein. The one difference from RFC4180 is that CR and LF are not part of the alternatives for the inner part of "escaped". Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PEM of root certs in Mozilla's root store
On Wed, Oct 14, 2020 at 7:31 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Only the CSV form now contains CSV artifacts. And it isn't really CSV > either (even if Microsoft Excel handles it). Hi Jakob, Could you be more precise here? Embedded new lines within quoted values is well-defined for CSV. Realizing that there are unfortunately many interpretations of what “well-defined for CSV” here, perhaps you can frame your concerns in terms set out in https://tools.ietf.org/html/rfc4180 . This at least helps make sure we can understand and are in the same understanding. For example, embedded new lines are discussed in 2.6 and the ABNF therein. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PEM of root certs in Mozilla's root store
On 2020-10-15 00:16, Kathleen Wilson wrote: The text version has been updated to have each line limited to 64 characters. Text: https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Websites https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Email CSV: https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMCSV?TrustBitsInclude=Websites https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMCSV?TrustBitsInclude=Email 1. The reports that contain /only/ PEM data. I argue that the traditional format of concatenated PEM files (as used by e.g. the openssl command line tool) without CSV embellishments would be preferable, and that the reports in the latest post by Kathleen lacked the PEM line wrapping while still containing CSV artifacts. Jakob, please explain what you mean by "still containing CSV artifacts". Does the new version of the text report have the problem? Only the CSV form now contains CSV artifacts. And it isn't really CSV either (even if Microsoft Excel handles it). 2. The reports that contain other data in CSV format. ... Opening the CSV version of the reports in Excel and Numbers works fine for me. So I don't understand what the problem is with having this report be a direct extract of the PEM data that the CCADB has for each root certificate. However, it might also be reasonable that if these concerns aren't easily addressable, perhaps not offering the feed is another option, since it seems a lot of work for something that should be and is naturally discouraged. It's not a lot of work, just a matter of understanding what is most useful to folks. I think it would be good to have downstreams using current data, e.g. data published directly via the CCADB. I think that providing the data in an easily consumable format is better than having folks extract the data from certdata.txt. Thanks, Kathleen Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PEM of root certs in Mozilla's root store
The text version has been updated to have each line limited to 64 characters. Text: https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Websites https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Email CSV: https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMCSV?TrustBitsInclude=Websites https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMCSV?TrustBitsInclude=Email 1. The reports that contain /only/ PEM data. I argue that the traditional format of concatenated PEM files (as used by e.g. the openssl command line tool) without CSV embellishments would be preferable, and that the reports in the latest post by Kathleen lacked the PEM line wrapping while still containing CSV artifacts. Jakob, please explain what you mean by "still containing CSV artifacts". Does the new version of the text report have the problem? 2. The reports that contain other data in CSV format. ... Opening the CSV version of the reports in Excel and Numbers works fine for me. So I don't understand what the problem is with having this report be a direct extract of the PEM data that the CCADB has for each root certificate. However, it might also be reasonable that if these concerns aren't easily addressable, perhaps not offering the feed is another option, since it seems a lot of work for something that should be and is naturally discouraged. It's not a lot of work, just a matter of understanding what is most useful to folks. I think it would be good to have downstreams using current data, e.g. data published directly via the CCADB. I think that providing the data in an easily consumable format is better than having folks extract the data from certdata.txt. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PEM of root certs in Mozilla's root store
On 2020-10-13 16:32, Ryan Sleevi wrote: Jakob, I had a little trouble following your mail, despite being quite familiar with PEM, so hopefully you'll indulge me in making sure I've got your criticisms/complaints correct. Your objection to the text report is that RFC 7468 requires generators to wrap lines (except the last line) at exactly 64 characters, right? That is, the textual report includes the base-64 data with no embedded newlines, and this causes your PEM decoder trouble, despite being able to easily inject them programmatically after you download the file. I was commenting on the /general/ usability of the reports mentioned in the first message on this thread, by considering what naive parsers would do upon reading the files. As I have no direct need to parse these files, I have no actual parser failing to do so. My comments fell in two categories: 1. The reports that contain /only/ PEM data. I argue that the traditional format of concatenated PEM files (as used by e.g. the openssl command line tool) without CSV embellishments would be preferable, and that the reports in the latest post by Kathleen lacked the PEM line wrapping while still containing CSV artifacts. 2. The reports that contain other data in CSV format. I argue that those reports would be more useful without in-field line breaks, thus having the Base64 encoded certificates as long strings without PEM embellishments. Goal is to make them traditional CSV files with one record per line, commas only between fields and optional double quotes around non-numerical field values. A sample parser would be awk, cut or the perl command line option "-F,". Simply viewing each report in a basic text viewer should make the problematic format deviations clear. I'm not sure I fully understand the CSV objection, despite having inspected the file, so perhaps you can clarify a bit more. Perhaps the simplest approach would be that you could attach versions that look how you'd want. Here are the top 3 lines of IncludedCACertificateWithPEMReport.csv reformatted (but with extra line breaks every 68 chars for posting purposes): "Owner","Certificate Issuer Organization","Certificate Issuer Organ izational Unit","Common Name or Certificate Name","Certificate Seri al Number","SHA-256 Fingerprint","Subject + SPKI SHA256","Valid Fro m [GMT]","Valid To [GMT]","Public Key Algorithm","Signature Hash Al gorithm","Trust Bits","Distrust for TLS After Date","Distrust for S /MIME After Date","EV Policy OID(s)","Approval Bug","NSS Release Wh en First Included","Firefox Release When First Included","Test Webs ite - Valid","Test Website - Expired","Test Website - Revoked","Moz illa Applied Constraints","Company Website","Geographic Focus","Cer tificate Policy (CP)","Certification Practice Statement (CPS)","Sta ndard Audit","BR Audit","EV Audit","Auditor","Standard Audit Type", "Standard Audit Statement Dt","PEM Info" "AC Camerfirma, S.A.","AC Camerfirma SA CIF A82743287","http://www. chambersign.org","Chambers of Commerce Root","00","0C258A12A5674AEF 25F28BA7DCFAECEEA348E541E6F5CC4EE63B71B361606AC3","BC2FD9EA61581CB2 2BB859690D61430E7D222D1119E8C41649B9B1D556D439A4","2003.09.30","203 7.09.30","RSA 2048 bits","SHA1WithRSA","Email","","","Not EV","http s://bugzilla.mozilla.org/show_bug.cgi?id=261778","","Firefox 1","", "","","","http://www.camerfirma.com","Spain","","https://www.camerf irma.com/publico/DocumentosWeb/politicas/CPS_eidas_EN_1.2.12.pdf"," https://www.csqa.it/getattachment/Sicurezza-ICT/Documenti/Attestazi one-di-Audit-secondo-i-requisiti-ETSI/2020-03-CSQA-Attestation-CAME RFIRMA-rev-2-signed.pdf.aspx?lang=it-IT","https://bugzilla.mozilla. org/attachment.cgi?id=8995930","","CSQA Certificazioni srl","ETSI E N 319 411","2020.03.05","MIIEvTCCA6WgAwIBAgIBADANBgkqhkiG9w0BAQUFAD B/MQswCQYDVQQGEwJFVTEnMCUGA1UEChMeQUMgQ2FtZXJmaXJtYSBTQSBDSUYgQTgyN zQzMjg3MSMwIQYDVQQLExpodHRwOi8vd3d3LmNoYW1iZXJzaWduLm9yZzEiMCAGA1UE AxMZQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdDAeFw0wMzA5MzAxNjEzNDNaFw0zNzA 5MzAxNjEzNDRaMH8xCzAJBgNVBAYTAkVVMScwJQYDVQQKEx5BQyBDYW1lcmZpcm1hIF NBIENJRiBBODI3NDMyODcxIzAhBgNVBAsTGmh0dHA6Ly93d3cuY2hhbWJlcnNpZ24ub 3JnMSIwIAYDVQQDExlDaGFtYmVycyBvZiBDb21tZXJjZSBSb290MIIBIDANBgkqhkiG 9w0BAQEFAAOCAQ0AMIIBCAKCAQEAtzZV5aVdGDDg2olUkfzIx1L4L1DZ77F1c2VHfRt bunXF/KGIJPov7coISjlUxFF6tdpg6jg8gbLL8bvZkSM/SAFwdakFKq0fcfPJVD0dBm pAPrMMhe5cG3nCYsS4No41XQEMIwRHNaqbYE6gZj3LJgqcQKH0XZi/caulAGgq7YN6D 6IUtdQis4CwPAxaUWktWBiP7Zme8a7ileb2R6jWDA+wWFjbw2Y3npuRVDM30pQcakjJ yfKl2qUMI/cjDpwyVV5xnIQFUZot/eZOKjRa3spAN2cMVCFVd9oKDMyXroDclDZK9D7 ONhMeU+SsTjoF7Nuucpw4i9A5O4kKPnf+dQIBA6OCAUQwggFAMBIGA1UdEwEB/wQIMA YBAf8CAQwwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5jaGFtYmVyc2lnbi5vc mcvY2hhbWJlcnNyb290LmNybDAdBgNVHQ4EFgQU45T1sU3p26EpW1eLTXYGduHRooow DgYDVR0PAQH/BAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIABzAnBgNVHREEIDAegRxjaGF tYmVyc3Jvb3RAY2hhbWJlcnNpZ24ub3JnMCcGA1UdEgQgMB6BHGNoYW1iZXJzcm9vdE BjaGFtYmVyc2lnbi5vcmcwWAYDVR0gBFEwTzBNBgsrBgEEAYGHLgoDATA+MDwGCCsGA
