Re: Audit Reminder Email Summary
Forwarded Message Subject: Summary of April 2020 Audit Reminder Emails Date: Tue, 21 Apr 2020 19:00:09 + (GMT) Mozilla: Audit Reminder CA Owner: Global Digital Cybersecurity Authority Co., Ltd. (Formerly Guang Dong Certificate Authority (GDCA)) Root Certificates: GDCA TrustAUTH R5 ROOT Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229546 Standard Audit Period End Date: 2019-02-28 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229547 BR Audit Period End Date: 2019-02-28 EV Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229548 EV Audit Period End Date: 2019-02-28 CA Comments: null Mozilla: Audit Reminder CA Owner: SK ID Solutions AS Root Certificates: EE Certification Centre Root CA Standard Audit: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019051701_SK_EE_Certification_Centre_Root_CA_s.pdf Standard Audit Period End Date: 2019-03-01 BR Audit: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019051701_SK_EE_Certification_Centre_Root_CA_s.pdf BR Audit Period End Date: 2019-03-01 CA Comments: null Mozilla: Audit Reminder CA Owner: certSIGN Root Certificates: certSIGN ROOT CA Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229553 Standard Audit Period End Date: 2019-02-08 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229551 BR Audit Period End Date: 2019-02-08 CA Comments: null Mozilla: Audit Reminder CA Owner: Cybertrust Japan / JCSI Root Certificates: SecureSign RootCA11** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229662 Standard Audit Period End Date: 2019-02-28 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229661 BR Audit Period End Date: 2019-02-28 CA Comments: null Mozilla: Audit Reminder CA Owner: Entrust Root Certificates: Entrust Root Certification Authority - EC1 Entrust Root Certification Authority - G2 Entrust Root Certification Authority - G4 AffirmTrust Commercial AffirmTrust Networking AffirmTrust Premium AffirmTrust Premium ECC Entrust Root Certification Authority Entrust.net Certification Authority (2048) Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230012 Standard Audit Period End Date: 2019-02-28 Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230013 Standard Audit Period End Date: 2019-02-28 BR Audit: https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ecs/2019-entrust-baseline-requirements-report.pdf BR Audit Period End Date: 2019-02-28 BR Audit: https://www.affirmtrust.com/wp-content/uploads/2019-AFT-Baseline-Requirements-report.pdf BR Audit Period End Date: 2019-02-28 EV Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230012 EV Audit Period End Date: 2019-02-28 EV Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230013 EV Audit Period End Date: 2019-02-28 CA Comments: null Mozilla: Overdue Audit Statements CA Owner: Trustis Root Certificates: Trustis Limited - Trustis FPS Root CA** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9047305 Standard Audit Period End Date: 2019-01-15 BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9047305 BR Audit Period End Date: 2019-01-15 CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1623472 Mozilla: Audit Reminder CA Owner: Asseco Data Systems S.A. (previously Unizeto Certum) Root Certificates: Certum Trusted Network CA 2 Certum CA Certum Trusted Network CA Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234363 Standard Audit Period End Date: 2019-03-04 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234364 BR Audit Period End Date: 2019-03-04 EV Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234365 EV Audit Period End Date: 2019-03-04 CA Comments: null ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Make readable CPSes easier to find
On Tue, Apr 21, 2020 at 8:24 AM Wojtek Porczyk wrote: > This statement, snipped from above: > > > This is exactly the sort of case CCADB is supremely positioned to solve, > > efficiently. In fact, all of these problems can be addressed by CCADB > > improvements, providing programmatically readable data while also making > > use of efficiencies and economies of scale. > > makes me curious: do you think CCADB could be leveraged to provide such > a list? To make it recommended (or even mandatory) to link to > CCADB-provided > query mechanism for such documents. To support embedding? No, the goal is to get stuff out, not add stuff. The CCADB absolutely could be the place for CAs to disclose the base URL for such a service, and some CAs already do approaches like this for providing supplemental details of revocation not covered by CRLs/OCSP, but that information doesn’t need to be conveyed in the certificate. The goal here should be moving to a model closer to Secondary Certs or DANE here, or the other drafts in IETF exploring compact certificate profiles, albeit without the CBOR nonsense, in making sure only the essential information is conveyed in band on every connection. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Make readable CPSes easier to find
On Tue, Apr 21, 2020 at 01:23:49AM -0400, Ryan Sleevi via dev-security-policy wrote: > On Mon, Apr 20, 2020 at 10:04 PM Matt Palmer via dev-security-policy > wrote: > > 2. Make the cPSuri actually point to the relevant CPS > > That doesn’t really capture what a CPS is. There can be many relevant CPSes > to a single certificate, both for a single path and multiple paths. That’s > literally how audits came to be - to support the model of multiple CPSes. > > So a statement like “the relevant CPS” is going to be flawed, for better or > worse. That’s a much bigger change to make (in how policies are managed). > Despite the merits of forbidding the policy-based approach proposed by the > ABA PAG, the problem reporting email is probably the least compelling > reason for scrapping that :( > > However, that seems moot if addressed as above? I don't see the contradiction. CA could embed values like https://ca.example/cps?serial=123abc and make sure that only documents relevant to the certificate in question are listed. This statement, snipped from above: > This is exactly the sort of case CCADB is supremely positioned to solve, > efficiently. In fact, all of these problems can be addressed by CCADB > improvements, providing programmatically readable data while also making > use of efficiencies and economies of scale. makes me curious: do you think CCADB could be leveraged to provide such a list? To make it recommended (or even mandatory) to link to CCADB-provided query mechanism for such documents. -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> signature.asc Description: PGP signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Make readable CPSes easier to find
On Tue, Apr 21, 2020 at 1:48 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > That ship sailed so very, very long ago, though. No it hasn’t. These are much easier to remove than to add new dependencies. We’re already seeing progress in addressing some of the ambiguities in the base certificate profiles in the CABF (via the validation WG), and while that effort is not necessarily to remove things, it does make it easier to make sure everyone is on the same page about what is permitted and good. Part of the goal is to make sure it’s clear precisely when and where flexibility exists, so we can make sure that flexibility balances all of the stakeholder needs. > 2. Make the cPSuri actually point to the relevant CPS > > > > That doesn’t really capture what a CPS is. There can be many relevant > CPSes > > to a single certificate, both for a single path and multiple paths. > That’s > > literally how audits came to be - to support the model of multiple CPSes. > > >From what I can see in a CSV o' Doom, a CA can only provide a single CPS > link for a given intermediate. That does rather suggest that there's only > one CPS for a given certificate. That’s something Kathleen is literally in the process of fixing :) > Do you disagree? If Mozilla Policy made normative that there be some form > > of binding problem reporting statement for each issuer certificate, would > > that address your problem or not? > > Not particularly, because while problem reporting addresses are the major > part of why I have gone looking for CPSes in the recent past, it is not the > only reason. Not as helpful as a reply ;) What are the other reasons, so we can better understand the challenges you’re facing, and find solutions that balance those needs better? :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
