Re: CA Problem Reporting Mechanisms
On Wednesday, May 17, 2017 at 11:24:54 AM UTC, Gervase Markham wrote: > Well, such contacts are normally per CA rather than per root. I guess we > could add it on the CA's entry. Tbh, I'm not really familiar with your salesforce setup, I was just using this as a stand-in for "place where CA can be made to keep it current". :-) > Well, I want to make sure that people who want to report e.g. a bad cert > found in the wild know where to go. This was triggered by an event where > Microsoft wanted to report something to GoDaddy (IIRC) but using the > wrong contact. So the intent was really: How can an external entity (= not the certificate owner or authorized party) report a security issue, abuse scenario or policy violation with regards to certificates you issued? Specifically, what contact email address or webpage can be used to ensure a timely and competent response? (plainly: how to reach "tech" or "compliance", not sales/marketing/customer-support/general/...) > > IMHO, a wiki page with manually copied info has a good chance to get > > stale as CAs change their documents, websites, primary domains, etc. > > It's true, but the other option is "dig in my CP/CPS". But there could be more "other options": dig yourself << community collected and maintained info < CA verified community info < info CAs are "forced" to maintain, policed by community So I guess my second choice - after getting CAs to unbundle this specific info from their pdfs and maintain it via the CCADB (or wherever else it makes sense) - would be to go ahead with the manually created wiki page and make them confirm it regularily via CA communications. Then there is still a degree of accountability for the correctness. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
TrustCor root inclusion request
This request from TrustCor is to include the “TrustCor RootCert CA-1”, “TrustCor RootCert CA-2”, and “TrustCor ECA-1” root certificates and enable the Websites and Email trust bits. TrustCor, located in Canada, is a commercial organization that develops privacy protection services and issues certificates to its customers in support of such services. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1231853 BR Self Assessment is here: https://bugzilla.mozilla.org/attachment.cgi?id=8860163 Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8868831 * Root Certificate Download URL: http://www.trustcor.ca/certs/root/ca1.pem http://www.trustcor.ca/certs/root/ca2.pem http://www.trustcor.ca/certs/root/eca1.pem * All documents are in English. Document Repository: https://www.trustcorsystems.com/resources/ CP: http://www.trustcor.ca/resources/cp.pdf CPS: http://www.trustcor.ca/resources/cps.pdf * CA Hierarchy: The “TrustCor RootCert CA-1” and “TrustCor RootCert CA-2” root certificates issue internally-operated intermediate certificates that sign SSL and S/MIME certificates. These root certs will not have any externally-operated subCAs. The Enterprise Root Certificate, “TrustCor ECA-1”, is the only root allowed to issue externally-operated subCAs. * This request is to turn on the Websites and Email trust bit. EV treatment is not requested. ** CP 3.2.5 Validation of authority TrustCor CA, or any authorized external RA, must verify the evidence accompanying a certificate request according to the following certificate types: - DV SSL Certificates - the domain name registrar must list the applicant as part of the WHOIS record; or effective control of the domain shall be demonstrated by the applicant or communication satisfying BR 3.2.2.4 shall be obtained. - OV SSL Certificates - In addition to the communications as per DV SSL Certificates, the CA/RA must also be satisfied that such assurances as per BR 3.2.2.2 and BR 3.2.2.3 have been completed. Specifically, reliable data sources such as government registries of incorporation shall be consulted to verify that the organizational identity can be reasonably asserted in the certificate subject. - S/MIME Certificates - the requestor must demonstrate control over receiving and sending messages from the specified email address. - Level 2 Individual-Organizational Certificates - the CA must possess communication delivered using a reliable method that the individual has an ongoing association with the organization; and that this communication must be sourced from someone in the organization 29 with the ability to speak authoritatively for its associations (e.g. an HR representative, the signatory to a contract of employment, etc.) * EV Policy OID: Not Requesting EV treatment * Test Websites RootCert CA-1 valid: https://catest1.trustcor.ca/ RootCert CA-1 revoked: https://catest1-revoked.trustcor.ca/ RootCert CA-1 expired: https://catest1-expired.trustcor.ca/ RootCert CA-2 valid: https://catest2.trustcor.ca/ RootCert CA-2 revoked: https://catest2-revoked.trustcor.ca/ RootCert CA-2 expired: https://catest2-expired.trustcor.ca/ ECA1-External valid: https://valid.epki.external.trustcor.ca/ ECA1-External revoked: https://revoked.epki.external.trustcor.ca/ ECA1-External expired: https://expired.epki.external.trustcor.ca/ * CRL URLs: CA1 - http://crl.trustcor.ca/root/ca1.crl CA1 - http://crl.trustcor.ca/root/ca2.crl ECA1 - http://crl.trustcor.ca/root/eca1.crl * OCSP URLs: CA1 - http://ocsp.trustcor.ca/root/ca1 CA2 - http://ocsp.trustcor.ca/root/ca2 ECA1 - http://ocsp.trustcor.ca/root/eca1 Maximum expiration time of OCSP responses: 4 days * Audit: Annual audits are performed by Princeton Audit Group (PAG) according to the WebTrust for CA and BR audit criteria. https://cert.webtrust.org/SealFile?seal=2169&file=pdf https://cert.webtrust.org/SealFile?seal=2163&file=pdf * Forbidden or Problematic Practices (https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices) ** Delegation of Domain / Email Validation to Third Parties ** Allowing External Entities to Operate Subordinate CAs *** CPS section 1.3.1: The Enterprise Root Certificate (ECA-1) - used as the ultimate root for enterprise PKIs issuing credentials to their principals in restricted namespaces. ... TrustCor CA undertakes to ensure that all operations conducted using these certificates, including registration of entities, validation of same, issuance and revocation of certificates are performed in accordance with the strictures of this document, the governing CP. Note that Enterprise Subordinate CA certificates are still TrustCor CA certificates, and TrustCor CA is responsible for their issuance, insofar as the enterprise subscriber agreements is obeyed. TrustCor CA is responsible for revoking an enterprise subordinate CA should it discover substantive violations of
Re: Certigna Root Renewal Request
All, I will greatly appreciate your help in reviewing and commenting on this root inclusion request from Certigna. Thanks, Aaron ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 17/05/17 15:49, Rob Stradling wrote: > The "Listed Here Since" timestamps for the 24 intermediates currently in > this category are set to today, because I don't have a time machine to > go back and find out how long they've actually been listed in this > category. ;-) Lack of time machine is unfortunate but forgiveable. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 17/05/17 15:21, Gervase Markham via dev-security-policy wrote: On 17/05/17 15:15, Rob Stradling wrote: Shall I add the same two fields to https://crt.sh/mozilla-disclosures#disclosureincomplete as well? Yes, why not? :-) Gerv Done. The "Listed Here Since" timestamps for the 24 intermediates currently in this category are set to today, because I don't have a time machine to go back and find out how long they've actually been listed in this category. ;-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 17/05/17 15:15, Rob Stradling wrote: > Shall I add the same two fields to > https://crt.sh/mozilla-disclosures#disclosureincomplete as well? Yes, why not? :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 17/05/17 15:12, Gervase Markham via dev-security-policy wrote: On 17/05/17 13:32, Rob Stradling wrote: I've just added two columns to https://crt.sh/mozilla-disclosures#undisclosed: - "Earliest SCT". - "Listed Here Since". Lovely! Now we just need a cert to be on the list so we can see what it looks like ;-) Shall I add the same two fields to https://crt.sh/mozilla-disclosures#disclosureincomplete as well? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 17/05/17 13:32, Rob Stradling wrote: > I've just added two columns to > https://crt.sh/mozilla-disclosures#undisclosed: > - "Earliest SCT". > - "Listed Here Since". Lovely! Now we just need a cert to be on the list so we can see what it looks like ;-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 17/05/17 15:08, Rob Stradling wrote: > Incidentally, it's true that Mozilla have said that they don't care > about the Code Signing trust bit any more, but the > CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt. Bug? Yes, but a low priority one. Feel free to file :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On 17/05/17 12:55, Jakob Bohm wrote: > That is /human readable/ information, not /computer readable/ data that > can be imported by other libraries when those are used with the Mozilla > root program. Yes, indeed. But you asked where in certdata.txt those things are, and that page explains pretty clearly that they aren't in certdata.txt, and why. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 17/05/17 14:43, Kurt Roeckx via dev-security-policy wrote: On 2017-05-17 14:40, Rob Stradling wrote: On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote: On 2017-05-11 19:05, Gervase Markham wrote: On 11/05/17 12:46, Rob Stradling wrote: There's a "Created by" field (Username, Timestamp) and a "Last Modified By" field (Username, Timestamp) in the CCADB, but neither of these fields are currently provided in the public CSV reports that Mozilla publishes. Rob: do you think you could enhance https://crt.sh/mozilla-disclosures#undisclosed to give the number of days a certificate has been on the list? Rob, Hi Kurt. Could you also split the "Technically Constrained", into those that are really technically constrained, and those that are out of scope for the CCADB? What's your definition of "really technically constrained"? For instance https://crt.sh/?id=12729339 is out of scope because it's code signing. https://crt.sh/?id=8951039 because it's client / email. They're out of scope because they're Technically Constrained in accordance with Section 5.3.1 of the Mozilla Root Store Policy v2.4.1 [1] Or maybe it just needs to be renamed? I'm really not sure what "it" you'd like to see categorized differently. I seem to have been confused. For some reason I was under the impression that only those that can be used for server auth were required to be disclosed when I was reading it last week. It didn't really make sense to me at the time, and now I can't find anything that suggests that. The impression you were under is correct. Any intermediate that is EKU-constrained to not permit serverAuth, or that permits serverAuth but is appropriately name-constrained, is considered to be "Technically Constrained" and is therefore not subject to the current disclosure requirement. And it seem that only an EKU is needed with the current policy for email and code signing to be considered constrained. Correct. But you could argue that for email you can't say for sure that it's constrained or not, which I guess is why we have https://github.com/mozilla/pkipolicy/issues/69 Correct. See also https://github.com/mozilla/pkipolicy/issues/73, which proposes that even Technically Constrained intermediates should fall under the disclosure requirement. I guess with code signing we have the situation that Mozilla doesn't care about it, but requires you to disclose them anyway. Where does it say that code signing intermediates need to be disclosed? That's not my understanding of section 5.3.1 of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Incidentally, it's true that Mozilla have said that they don't care about the Code Signing trust bit any more, but the CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt. Bug? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 2017-05-17 14:40, Rob Stradling wrote: On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote: On 2017-05-11 19:05, Gervase Markham wrote: On 11/05/17 12:46, Rob Stradling wrote: There's a "Created by" field (Username, Timestamp) and a "Last Modified By" field (Username, Timestamp) in the CCADB, but neither of these fields are currently provided in the public CSV reports that Mozilla publishes. Rob: do you think you could enhance https://crt.sh/mozilla-disclosures#undisclosed to give the number of days a certificate has been on the list? Rob, Hi Kurt. Could you also split the "Technically Constrained", into those that are really technically constrained, and those that are out of scope for the CCADB? What's your definition of "really technically constrained"? For instance https://crt.sh/?id=12729339 is out of scope because it's code signing. https://crt.sh/?id=8951039 because it's client / email. They're out of scope because they're Technically Constrained in accordance with Section 5.3.1 of the Mozilla Root Store Policy v2.4.1 [1] Or maybe it just needs to be renamed? I'm really not sure what "it" you'd like to see categorized differently. I seem to have been confused. For some reason I was under the impression that only those that can be used for server auth were required to be disclosed when I was reading it last week. It didn't really make sense to me at the time, and now I can't find anything that suggests that. And it seem that only an EKU is needed with the current policy for email and code signing to be considered constrained. But you could argue that for email you can't say for sure that it's constrained or not, which I guess is why we have https://github.com/mozilla/pkipolicy/issues/69 I guess with code signing we have the situation that Mozilla doesn't care about it, but requires you to disclose them anyway. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 12/05/17 16:37, Kurt Roeckx via dev-security-policy wrote: On 2017-05-11 19:05, Gervase Markham wrote: On 11/05/17 12:46, Rob Stradling wrote: There's a "Created by" field (Username, Timestamp) and a "Last Modified By" field (Username, Timestamp) in the CCADB, but neither of these fields are currently provided in the public CSV reports that Mozilla publishes. Rob: do you think you could enhance https://crt.sh/mozilla-disclosures#undisclosed to give the number of days a certificate has been on the list? Rob, Hi Kurt. Could you also split the "Technically Constrained", into those that are really technically constrained, and those that are out of scope for the CCADB? What's your definition of "really technically constrained"? For instance https://crt.sh/?id=12729339 is out of scope because it's code signing. https://crt.sh/?id=8951039 because it's client / email. They're out of scope because they're Technically Constrained in accordance with Section 5.3.1 of the Mozilla Root Store Policy v2.4.1 [1] Or maybe it just needs to be renamed? I'm really not sure what "it" you'd like to see categorized differently. [1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 11/05/17 18:05, Gervase Markham via dev-security-policy wrote: On 11/05/17 12:46, Rob Stradling wrote: There's a "Created by" field (Username, Timestamp) and a "Last Modified By" field (Username, Timestamp) in the CCADB, but neither of these fields are currently provided in the public CSV reports that Mozilla publishes. Rob: do you think you could enhance https://crt.sh/mozilla-disclosures#undisclosed to give the number of days a certificate has been on the list? Hi Gerv. I've just added two columns to https://crt.sh/mozilla-disclosures#undisclosed: - "Earliest SCT". - "Listed Here Since". Note that if an intermediate cert goes out of scope for disclosure (i.e., all trust paths become revoked) but then comes back into scope for disclosure (i.e., a new trust path is discovered), then its "Listed Here Since" timestamp will be reset. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On 17/05/2017 13:29, Gervase Markham wrote: On 16/05/17 18:04, Jakob Bohm wrote: Could you please point out where in certdata.txt the following are expressed, as I couldn't find it in a quick scan: 1. The date restrictions on WoSign-issued certificates. 2. The EV trust bit for some CAs. I am surprised you are engaging in a discussion on this topic without being pretty familiar with: https://wiki.mozilla.org/CA/Additional_Trust_Changes That is /human readable/ information, not /computer readable/ data that can be imported by other libraries when those are used with the Mozilla root program. 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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption
On 2017-05-17 13:23, Michael Casadevall wrote: On 05/17/2017 05:04 AM, Kurt Roeckx wrote: If the key is compromised, you can't rely on any date information anymore, you need to revoke it completely and break things. Won't that only be true in certificates without SCTs? Once you have a SCT, you have an independent timestamp you can check beside the NotBefore value, and can independently confirm since CT logs are append-only. (Granted, I realize nothing actually checks the SCT in this way to my knowledge, but the idea itself may be on semi-solid ground). Yes, and I guess that's the reason why with code signing they also use a timestamp service. And I guess we could require either an SCT or a timestamp if they want signatures to remain valid. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On 16/05/17 18:04, Jakob Bohm wrote: > Could you please point out where in certdata.txt the following are > expressed, as I couldn't find it in a quick scan: > > 1. The date restrictions on WoSign-issued certificates. > > 2. The EV trust bit for some CAs. I am surprised you are engaging in a discussion on this topic without being pretty familiar with: https://wiki.mozilla.org/CA/Additional_Trust_Changes Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Problem Reporting Mechanisms
On 16/05/17 02:26, userwithuid wrote: > After skimming the responses and checking a few CAs, I'm starting to > wonder: Wouldn't it be easier to just add another mandatory field to > the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via > policy and just use that to provide a public list? Well, such contacts are normally per CA rather than per root. I guess we could add it on the CA's entry. > It seems to me that most revocation related procedures are very > specific to CA-customers (e.g. log in and use the revoke button) and > often not even TLS related (e.g. send a document signed with key you > want to revoke, use the revocation password you got when creating the > email cert, ...). I think it's not your intention for the wiki page > to capture that, or is it? Well, I want to make sure that people who want to report e.g. a bad cert found in the wild know where to go. This was triggered by an event where Microsoft wanted to report something to GoDaddy (IIRC) but using the wrong contact. > IMHO, a wiki page with manually copied info has a good chance to get > stale as CAs change their documents, websites, primary domains, etc. It's true, but the other option is "dig in my CP/CPS". Also, I had hoped that the question itself would remind CAs that this information needed to be there, and prompt any for which it wasn't there to fix it :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/17/2017 05:04 AM, Kurt Roeckx wrote: > If the key is compromised, you can't rely on any date information > anymore, you need to revoke it completely and break things. > Won't that only be true in certificates without SCTs? Once you have a SCT, you have an independent timestamp you can check beside the NotBefore value, and can independently confirm since CT logs are append-only. (Granted, I realize nothing actually checks the SCT in this way to my knowledge, but the idea itself may be on semi-solid ground). Michael -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJZHDLHAAoJEHM+GkLSJHY5rnAP/A7Y7x0B5yr/t3ft5Ua4k5BP P1EKD/Oguwf2QqTiBYgvuKOvdc8aCkOCoVXcq9awyERUzxpW/Pcvz5bOfLLyYY8v qLLFTAXylJSJvFCSlw8+M1aiFEcTzeVptOUl51yQbBxxooWh4Oc8BrhvBZsCZqO3 j5KEWKo7kGLN0pAfocXDHBktb3DVJBnQnyakrUFooz0BgoH+cfJ2te/dSSSNspvw TfPfydWC/ANg7FBkvuc4cZrH3PSGEfpnR7kcvFTfD56Pg2Q90i46gS3ikGdqHaA0 F3GOQ456J0sFpM3wjmIVvLV6OKnQG0jBNicrkyYOydw+YHTVwyhJN12VT7kAlYdc HUVdl18T+Fx2waf/J8sQLyrYoE8QQ0nEZ+8DC4/XXe7gkxwxSFfvD8fUTLnYRI8F TNfq1D+DnIQIQsEDEX5PYfgRAgNohKhzy6L+btLeyqLsqI1Vxak3cCJ40Zl68Pj8 NpTSvPchlSiUZNPRDD6moRIJdsSIfEGPDn6jjOntw4Go3gwg67jPl8btePBM3VWD 9WRAy6KGdX5rRWsrvH1Zrrmeqjsqe8kQ6t3vGbuU0Qcd7hDT4EoDWWTRafy8Nsbc BIag3UXSWtF27LLpw/0C+6wPDT9krdl01JMTPwc0li0tYYL8h7W3FfHe8jMvnOmT Z0bUn1hiBjaFftVpdlM0 =RWD4 -END PGP SIGNATURE- ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
在 2017年5月17日星期三 UTC+8下午5:18:59，Rob Stradling写道： > On 12/05/17 06:51, wangsn1206--- via dev-security-policy wrote: > > 在 2017年5月11日星期四 UTC+8下午5:58:00，Rob Stradling写道： > >> On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote: > >> > * CPS Appendix1: Certificate information of the publicly trusted CAs: > Most > of the listed CAs can't be found in crt.sh - it would be great to get > them > CT logged. > > >>> Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation > >>> cannot be done for the other two ROOTs as we have not yet applied for the > >>> inclusion of these two. > >> > >> Hi. > >> > >> Would you like me to add your other two roots to the list of roots that > >> are accepted by the Comodo Dodo log? > >> > >> If so, please either submit a pull request on GitHub (see > >> https://github.com/Comodo-CA/CTLogs-AcceptedRoots) or send me the two > >> root certs. > >> > >> The Comodo Dodo log isn't trusted by Chrome, but it is monitored by crt.sh. > > > > Hi Rob, > > > > Thanks for your kind assistance, we have e-mailed our roots to you for this > > purpose. > > Our Dodo log now accepts the "GDCA TrustAUTH E5 ROOT" and "数安时代 R5 根 CA" > root certificates, and I've submitted both of them to Dodo. You can see > them here: > > https://crt.sh/?id=139646527 > https://crt.sh/?id=139646529 > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online Thanks Rob. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
On 12/05/17 06:51, wangsn1206--- via dev-security-policy wrote: 在 2017年5月11日星期四 UTC+8下午5:58:00，Rob Stradling写道： On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote: * CPS Appendix1: Certificate information of the publicly trusted CAs: Most of the listed CAs can't be found in crt.sh - it would be great to get them CT logged. Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation cannot be done for the other two ROOTs as we have not yet applied for the inclusion of these two. Hi. Would you like me to add your other two roots to the list of roots that are accepted by the Comodo Dodo log? If so, please either submit a pull request on GitHub (see https://github.com/Comodo-CA/CTLogs-AcceptedRoots) or send me the two root certs. The Comodo Dodo log isn't trusted by Chrome, but it is monitored by crt.sh. Hi Rob, Thanks for your kind assistance, we have e-mailed our roots to you for this purpose. Our Dodo log now accepts the "GDCA TrustAUTH E5 ROOT" and "数安时代 R5 根 CA" root certificates, and I've submitted both of them to Dodo. You can see them here: https://crt.sh/?id=139646527 https://crt.sh/?id=139646529 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption
On 2017-05-16 14:24, Michael Casadevall wrote: Maybe a bit out there, but an interesting thought none the less. It would definitely go a good way at preventing one root certificate from underpinning a large chunk of the internet. My thought here is if a large "Too Big to Fail" CA's private key was compromised/factored/physically stolen, our only recourse would be to remove them from the root store, and deal with half the internet breaking. Would be nice if that could not be a thing. If the key is compromised, you can't rely on any date information anymore, you need to revoke it completely and break things. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
