Re: Audit Reminder Email Summary
Forwarded Message Subject: Summary of May 2020 Audit Reminder Emails Date: Tue, 19 May 2020 19:00:17 + (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: LuxTrust Root Certificates: LuxTrust Global Root 2 Standard Audit: https://www.lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_11085-124_V10.pdf Standard Audit Period End Date: 2019-03-29 BR Audit: https://www.lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_11085-124_V10.pdf BR Audit Period End Date: 2019-03-29 EV Audit: https://www.lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_11085-124_V10.pdf EV Audit Period End Date: 2019-03-29 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: Autoridad de Certificacion Firmaprofesional Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 Standard Audit: https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-FP_v4%20c.pdf Standard Audit Period End Date: 2019-03-27 BR Audit: https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-FP_v4%20c.pdf BR Audit Period End Date: 2019-03-27 EV Audit: https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-FP_v4%20c.pdf EV Audit Period End Date: 2019-03-27 CA Comments: null Mozilla: Audit Reminder CA Owner: AC Camerfirma, S.A. Root Certificates: Chambers of Commerce Root Chambers of Commerce Root - 2008 Global Chambersign Root Global Chambersign Root - 2008 Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230425 Standard Audit Period End Date: 2019-04-13 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995930 BR Audit Period End Date: 2018-04-13 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9072794 BR Audit Period End Date: 2019-03-28 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236204 BR Audit Period End Date: 2019-04-13 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9072794 EV Audit Period End Date: 2019-03-28 CA Comments: null Mozilla: Overdue Audit Statements CA Owner: certSIGN Root Certificates: certSIGN ROOT CA** ** Audit Case in the Common CA Database is under review for this root certificate. 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: Audit statements provided, waiting for Seals to be provided by CPA Canada. Mozilla: Audit Reminder CA Owner: Sectigo Root Certificates: COMODO RSA Certification Authority USERTrust ECC Certification Authority AAA Certificate Services AddTrust Class 1 CA Root AddTrust External CA Root COMODO Certification Authority COMODO ECC Certification Authority USERTrust RSA Certification Authority Standard Audit: https://bug1472993.bmoattachments.org/attachment.cgi?id=9078178 Standard Audit Period End Date: 2019-03-31 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231163 BR Audit Period End Date: 2019-03-31 BR Audit: BR Audit Period End Date: EV Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231164 EV Audit Period End Date: 2019-03-31 CA Comments: null Mozilla: Audit Reminder CA Owner: Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) Root Certificates: EC-ACC Standard Audit: https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-2%20PSC-CAOC_v4.pdf Standard Audit Period End Date: 2019-03-28 BR Audit:
Re: Digicert issued certificate with let's encrypts public key
On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton wrote: > So, I request and encourage that CABForum members consider populating > clause 3.2.1 of the Basic Requirements, so that Proof-of-Possession be > mandated. > I don't mean to beat a dead horse, and without addressing the merits of trying to consider a leaf certificate issued over a particular public key as proof-of-possession/control of the corresponding private key, I add one further practical problem: The standard use of the most common way of communicating the public key and the purported proof-of-possession of the private key to the CA, the CSR, does not provide replay protection and yet is frequently NOT treated as a security impacting element should it be disclosed post-issuance. As such, one must question if an arbitrary CSR which contains a valid signature produced using the private key which corresponds to the subject public key in same said CSR is really qualified to be considered proof-of-possession (or proof of control) of said private key. I submit that it is not. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Status of the bugzilla bug list
On Tue, May 19, 2020 at 2:22 PM Matthias van de Meent wrote: > I agree that for any one bug, this metadata is not anything to make > decisions over, but when looking over e.g. the last 3 years, you can > start making more informed guesses on the metadata only. E.g. when you > find that a CA has consistently had 4-8 compliance issues open with > only sporadic updates, although this doesn't tell anything about this > CA in and of itself, it does give a (basic) sense of concern. But, as > I've heard, the metadata is even less precise than I'd previously > expected, and thus this road to knowledge is yet to be built. Exactly, for better or worse. I'm not sure, even in our idealized world, we'd necessarily /want/ Bugzilla to be this. Historically, the approach has been to systematize patterns (e.g. https://wiki.mozilla.org/CA:Symantec_Issues , https://wiki.mozilla.org/CA:PROCERT_Issues , https://wiki.mozilla.org/CA:WoSign_Issues ), to try and provide that information distilled in a way that's useful to decision making and policy stakeholders. It's difficult to see that purely encapsulated in the bug metadata, because there's issues where something seemingly small can be quite eye opening, and something seemingly major can be actually quite benign. The dimension of severity is subjective across a number of dimensions, and so there's no quick and pert way of summarizing that. I'm not trying to defend the status quo, to be sure. There's a lot I would love to see improved here, it's just not the highest priority in the overall set of issues. For example, I'd rather see things like ALV for intermediates, improvements to auditor qualifications, improvements to audits themselves, structural improvements to the BRs (for which I have many in-flight pull requests), etc. Similarly, I'm concerned about patterns of CAs simply not responding in a timely fashion ( e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1563579 ), and would love to improve the tooling to detect and alert on this. Or, for that matter, better tooling to help us digest and correlate responses across CAs, or identify when an issue is a duplicate (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1638898 ) or not yet revoked (e.g. http://misissued.com ). I have a long list of things that could be improved, for sure, but alas, time and resource limited :) > To continue on your metaphor: I do not expect Tier 1, but maybe more > like somewhere between Tier 2 en Tier 3? A biweekly, monthly or any > regular check for open compliance issues waiting for a reply from > Mozilla would already improve the (observed) situation tremendously. I don't disagree on room for improvements, for sure, but I'm still going to push back on a Mozilla obligation here, because I don't think that's reasonable. The interesting thing about this particular situation is that if CAs consistently adhered to their existing expectations, it does tend to end up resolved quicker. The ball is placed consistently in the CA's court to drive this to resolution, and they're expected to be continually doing that. This is, in part, due to how Bugzilla searching, filtering, and alerting works. This again goes back to where there's room for improvement here, if you're passionate, and help is welcome :) This goes back to workflow. If CAs followed the defined workflow, "it works". You're right that CAs aren't following the defined workflow, and so it's not working as ideally as possible, and that makes some of the data you want more difficult. Should Mozilla start removing CAs that don't adhere to that work flow? In some extreme cases (e.g. see above), it's probably justified, if not outright necessary. In other cases, that may be seen as extreme. The important thing here, for setting expectations, is that the CA is expected to be continually driving things. That they aren't is an issue, and it's one I'm fully supportive of filing incidents against CAs to improve. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Status of the bugzilla bug list
On Tue, 19 May 2020 at 16:22, Ryan Sleevi wrote: > > On Tue, May 19, 2020 at 5:53 AM Matthias van de Meent > wrote: >> >> One of the reasons I did this research was to check the track record >> of CAs with regards to compliance and solving compliance issues. As >> you might expect, this is quite difficult when the issues are not >> updated regularly. > > I’m not sure I see the connection. For this scenario, it’s actually necessary > to read the bugs. We do not use the bug metadata (e.g. opened, last updated, > closed date) as part of our own analysis and processing, instead relying on > reading the bugs themselves. I agree that for any one bug, this metadata is not anything to make decisions over, but when looking over e.g. the last 3 years, you can start making more informed guesses on the metadata only. E.g. when you find that a CA has consistently had 4-8 compliance issues open with only sporadic updates, although this doesn't tell anything about this CA in and of itself, it does give a (basic) sense of concern. But, as I've heard, the metadata is even less precise than I'd previously expected, and thus this road to knowledge is yet to be built. >> The distinction closed / open is, (although skewed) a decent >> indication for a CAs compliance track record and their readiness to >> improve, especially when tracking open issues over time. When the >> issue state is not linked to the actual solving of the compliance >> issue, the skewed indication becomes even worse. > > > Thanks. I don’t think we intend for it to be used as such, and so perhaps > it’s not surprising that you find the current data unsatisfying. I would > disagree that it’s a decent approximation, in part because that’s not > something we guarantee, as you can see. > > I say this not to disagree that it “could” be useful, but it’s considerably > more work and effort, and places the burden back on the Mozilla community to > guarantee, for something that isn’t essential for our efforts or necessary > for our tasks. > > For lack of a better comparison, it is a bit like asking why AIX or BeOS > aren’t a tier 1 configuration ( > https://firefox-source-docs.mozilla.org/build/buildsystem/supported-configurations.html > ). The answer is because it’s significant burden for limited return. Thanks, I had not quite considered this part of the equation. >> The MRSP section 2.4 asks the CA to promptly provide an incident >> report, and regularly update this report until it is closed. My >> opinion is that in this section Mozilla also has an implicit duty to >> the CA - to mark issues as resolved when Mozilla and the CA agree that >> the compliance issue has been resolved. > > > Thanks. I don’t agree with that implicit duty assertion, and I think the only > reason it comes up here is because it’s tied to a use case which is not > presently supported. > > To use the previous metaphor, this is a bit like saying that if AIX/BeOS, > then Mozilla has an implicit duty not to break the build. However, that > ignores the notion of support tiers, and what guarantees, if any, are > provided. I believe this is a bad metaphor for what I understand is Mozillas role in handling Incident Report bugs. MRSP 2.4 specifically calls out that a Mozilla representative must eventually close the bug (or not?), and that until that moment (or forever?) the CA must continue regularly updating this Incident Report. Although I do agree that Mozilla is not responsible for actively driving the Incident Report towards closure (that is as I understand it the role of the CA), I do believe that Mozilla still should take action when the CA is convinced the Incident Report is complete and can be closed or asks for extra guidance - be it resolving the bug, be it responding and asking for missing information. I do believe that a CA has some right to "reasonable" response times when they believe the incident has been handled, just like Mozilla asks for "regular updates" on Incident Reports. Note that I, similar to the MRSP, do not mention what time frames to expect when talking about "reasonable" or "regular" in this context. To continue on your metaphor: I do not expect Tier 1, but maybe more like somewhere between Tier 2 en Tier 3? A biweekly, monthly or any regular check for open compliance issues waiting for a reply from Mozilla would already improve the (observed) situation tremendously. >> Currently, I cannot see the forest for the trees due to so many issues >> waiting to be closed, or having their next-update-by -windows long >> passed, or just plain lack of communication about what is going on. >> This makes it even more difficult to make informed decisions about >> those CAs based on compliance track record. > > > To close this out unambiguously: Using purely the bug metadata (i.e. the > status, last modified date, etc) will not tell you this story. What you are > trying to do is not presently supported. > > Would it be nice? Yes, I have no doubt. But that
Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours
On Tue, May 19, 2020 at 12:38 PM sandybar497--- via dev-security-policy wrote: > I actually submitted this post 6 days ago and was only just approved today.. > is there a lack of resources approving blog posts? just don't see how it's > helpful when posts show up so late. It looks like you may be posting through Google Groups, which can cause moderation delays if you're not signed up through https://lists.mozilla.org/listinfo/dev-security-policy (Groups is largely Archives, with some mirroring for posting that can have hiccups, as you can see) Certainly, you can always report issues through Bugzilla, as noted at https://wiki.mozilla.org/CA/Incident_Dashboard , which doesn't have the same moderation queue. > As noted, I sampled the OCSP responder well after 24 hours and the cert had > not been revoked yet. I don't have a signed copy to share as i didn't save it > but I don't think it's necessary since it still took GoDaddy over 24 hours to > revoke. Not trying to suggest it's not the case, but these statements alone aren't necessarily enough to demonstrate non-compliance. Signed responses or other evidence are useful, especially when things are "on the cusp" > If you compare report timestamp with ocsp timestamp the difference is > approximately 28hrs and 48mins. Can you provide the original message with headers? Either to this or as an attachment to Bugzilla? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours
On Friday, May 15, 2020 at 7:30:45 AM UTC+10, Ryan Sleevi wrote: > Do you have a copy of the OCSP response? > > With such issues, we may need signed artifacts to demonstrate > non-compliance. For example, it shows as revoked via both OCSP and CRL > for me. > > On Thu, May 14, 2020 at 4:32 PM sandybar497--- via dev-security-policy > wrote: > > > > On 7 May 2020 at 12:07:07 PM UTC I reported a certificate to GoDaddy at > > practi...@starfieldtech.com as having its private key compromised. > > > > I received the automated acknowledgement confirmation, however, as of > > 2020-05-09 03:39:36 UTC (well after 24 hours), OCSP still shows the > > certificate as being "Good" > > > > The unrevoked certificate is https://crt.sh/?id=2366734355 > > > > I believe this is a breach of the CA-BR [4.9.1.1. Reasons for Revoking a > > Subscriber Certificate] - > > > > "The CA SHALL revoke a Certificate within 24 hours if one or more of the > > following occurs""The CA obtains evidence that the Subscriber's Private > > Key corresponding to the Public Key in the Certificate suffered a Key > > Compromise" > > > > I would like to request GoDaddy revoke the certificate and provide an > > incident report on this matter. > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy I actually submitted this post 6 days ago and was only just approved today.. is there a lack of resources approving blog posts? just don't see how it's helpful when posts show up so late. As noted, I sampled the OCSP responder well after 24 hours and the cert had not been revoked yet. I don't have a signed copy to share as i didn't save it but I don't think it's necessary since it still took GoDaddy over 24 hours to revoke. If you compare report timestamp with ocsp timestamp the difference is approximately 28hrs and 48mins. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Digicert issued certificate with let's encrypts public key
On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton wrote: > With proof of possession, these situations can be detected and raised as > being not-just-theoretical, and the CAs (or whoever wants to search the CT > logs) can notify the entities involved that they probably want to change > their keys. In the case of CA keys potentially being duplicated, this is an > incredibly important capacity. In the case of EV certificate keys being > duplicated, it can be a reportable event for the certified entities (such > as banks) if copies of their private key are found to be in the possession > of anyone else. > How, precisely? Today, the vast majority of certificates lack any end-entity identifying factors other than some number of SAN dnsName entries. In modern CDNs (example: CloudFlare), a single certificate might represent a plurality of entirely unrelated websites run by entirely unrelated entities who happen to share a service provider in common. In as far as that these sites are already sharing a TLS concentrator -- while it is not the practice of anyone I know of -- such a service provider could have quite a number of TLS concentrator elements sharing (access to) a public/private key pair and might choose to provision quite a number of unrelated certificates with the same key. Two certificates issued at two different times containing the same public key is not proof one way or the other. It does not prove two entities are definitely related. It does not prove that they are not. But the fact that proof of possession isn't required increases the plausibility that it does not prove a relationship. I wonder if the attendant ambiguity has saved anyone's head from rolling. On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton wrote: > CABForum's current Basic Requirements, section 3.2.1, is titled "Method to > prove possession of private key". > > It is currently blank. > > A potential attack without Proof of Possession which PKIX glosses over > could involve someone believing that a signature on a document combined > with the non-possession-proved certificate constitutes proof of possession, > and combined with external action which corroborates the contents of the > document could heuristically evidence the authority to issue the document. > (Yes, this would be a con job. But it would be prevented if CAs actually > had the applicant prove possession of the private key.) > > Regardless of that potential con, though, there is one very important > thing which Proof of Possession is good for, regardless of whether any > credible attacks are "enabled" by its lack: it enables identification of a > situation where multiple people independently generate and possess the same > keypair (such as what happened in the Debian weak-key fiasco). Regardless > of how often it might be seen in the wild, the fact is that on every key > generation there is a chance (small, but non-zero) that the same key will > be generated again, probably by someone different than the person who > originally generated it. (With bad implementations the chance gets much > larger.) > > With proof of possession, these situations can be detected and raised as > being not-just-theoretical, and the CAs (or whoever wants to search the CT > logs) can notify the entities involved that they probably want to change > their keys. In the case of CA keys potentially being duplicated, this is an > incredibly important capacity. In the case of EV certificate keys being > duplicated, it can be a reportable event for the certified entities (such > as banks) if copies of their private key are found to be in the possession > of anyone else. > > Non-zero probability of duplication is not zero probability of > duplication, and relying on it being "close enough to zero" is eventually > going to bite us all. It's up to those who work for CAs to put in > mitigations for when that day ultimately arrives, or else risk the > viability of not only their businesses but every other CA business they > compete with. > > So, I request and encourage that CABForum members consider populating > clause 3.2.1 of the Basic Requirements, so that Proof-of-Possession be > mandated. > > -Kyle H > > On Sun, May 17, 2020, 22:23 Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> > In particular, there must have been some authorisation carried out at >> some >> > point, or perhaps that wasn't carried out, that indicates who requested >> the >> > cert. What I'm trying to discover is where the gap was, and what's >> > required >> > to fix it in the future. >> > >> >> What gap, exactly? There’s not a risk here. >> >> I don’t think it’s been codified that private key possession or control >> has >> to be demonstrated. >> >> I think it would be plausible for a CA to allow submission of a public key >> in lieu of a CSR and that nothing would be wrong about it. >> ___ >> dev-security-policy mailing list >>
Re: Digicert issued certificate with let's encrypts public key
On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton wrote: > A potential attack without Proof of Possession which PKIX glosses over > could involve someone believing that a signature on a document combined > with the non-possession-proved certificate constitutes proof of possession, > and combined with external action which corroborates the contents of the > document could heuristically evidence the authority to issue the document. > (Yes, this would be a con job. But it would be prevented if CAs actually > had the applicant prove possession of the private key.) > Could you explain how this is different from other stretches of fitness for purpose? For example, I can use Lipton's tea leaves as guidance dictates - for making a beverage purportedly fit for human consumption. I can also try to diving events of the future by finding meaning in the patterns of the tiny dregs of tea leaf left in the bottom of my mug. But I should expect to get laughed at by Lipton customer service if I ask for assistance with this or appear to be taking these predictions seriously. On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton wrote: > CABForum's current Basic Requirements, section 3.2.1, is titled "Method to > prove possession of private key". > > It is currently blank. > > A potential attack without Proof of Possession which PKIX glosses over > could involve someone believing that a signature on a document combined > with the non-possession-proved certificate constitutes proof of possession, > and combined with external action which corroborates the contents of the > document could heuristically evidence the authority to issue the document. > (Yes, this would be a con job. But it would be prevented if CAs actually > had the applicant prove possession of the private key.) > > Regardless of that potential con, though, there is one very important > thing which Proof of Possession is good for, regardless of whether any > credible attacks are "enabled" by its lack: it enables identification of a > situation where multiple people independently generate and possess the same > keypair (such as what happened in the Debian weak-key fiasco). Regardless > of how often it might be seen in the wild, the fact is that on every key > generation there is a chance (small, but non-zero) that the same key will > be generated again, probably by someone different than the person who > originally generated it. (With bad implementations the chance gets much > larger.) > > With proof of possession, these situations can be detected and raised as > being not-just-theoretical, and the CAs (or whoever wants to search the CT > logs) can notify the entities involved that they probably want to change > their keys. In the case of CA keys potentially being duplicated, this is an > incredibly important capacity. In the case of EV certificate keys being > duplicated, it can be a reportable event for the certified entities (such > as banks) if copies of their private key are found to be in the possession > of anyone else. > > Non-zero probability of duplication is not zero probability of > duplication, and relying on it being "close enough to zero" is eventually > going to bite us all. It's up to those who work for CAs to put in > mitigations for when that day ultimately arrives, or else risk the > viability of not only their businesses but every other CA business they > compete with. > > So, I request and encourage that CABForum members consider populating > clause 3.2.1 of the Basic Requirements, so that Proof-of-Possession be > mandated. > > -Kyle H > > On Sun, May 17, 2020, 22:23 Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> > In particular, there must have been some authorisation carried out at >> some >> > point, or perhaps that wasn't carried out, that indicates who requested >> the >> > cert. What I'm trying to discover is where the gap was, and what's >> > required >> > to fix it in the future. >> > >> >> What gap, exactly? There’s not a risk here. >> >> I don’t think it’s been codified that private key possession or control >> has >> to be demonstrated. >> >> I think it would be plausible for a CA to allow submission of a public key >> in lieu of a CSR and that nothing would be wrong about it. >> ___ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Digicert issued certificate with let's encrypts public key
On Tue, May 19, 2020 at 12:35 AM Kyle Hamilton wrote: > > > On Mon, May 18, 2020, 19:46 Ryan Sleevi wrote: > >> On Mon, May 18, 2020 at 7:55 PM Kyle Hamilton via dev-security-policy >> wrote: >> >> > Regardless of that potential con, though, there is one very important >> thing >> > which Proof of Possession is good for, regardless of whether any >> credible >> > attacks are "enabled" by its lack: it enables identification of a >> situation >> > where multiple people independently generate and possess the same >> keypair >> > (such as what happened in the Debian weak-key fiasco). Regardless of how >> > often it might be seen in the wild, the fact is that on every key >> > generation there is a chance (small, but non-zero) that the same key >> will >> > be generated again, probably by someone different than the person who >> > originally generated it. (With bad implementations the chance gets much >> > larger.) >> >> This argument doesn't hold water. This is an argument not about proof >> of possession about private key, but about the public key itself. >> Multiple parties possessing the same key pair are revealed by the >> public key. Proof of possession provides zero value. >> > > So... taking this argument to its logical end, Let's Encrypt should have > immediately revoked its public key when it was found to have been issued to > another entity by another member of CABF, which is supposed to operate > within the constraints of identification embedded in the Basic > Requirements. (i.e., another entity was certified as being able to make > signatures which could be technically attributed to the Let's Encrypt CA, > which qualifies as "loss of control of the CA private key". A private key > is not a device, or an authorized or unauthorized copy of a PKCS#8 or > PKCS#12 structure. A private key is a sequence of bits which encodes a > value which, when operated upon in accordance with the rules of the > algorithm it was generated under, will generate a value which can be > verified (and possibly decrypted, in the case of RSA) with its > corresponding public key value. Random generation means that the > independent generation of a keypair is always a potential risk. The reason > we have a uniform and large key space and generation process is to minimize > the risk that this will happen, but a non-zero risk is not a zero risk.) > This is a strawman argument based on fundamental misunderstanding, not the logical end. You’ve directly conflated public and private key, and confused the ability to create a signature with attribution. In short: this is utter nonsense. I’m disappointed to even need to point out how unsound the statement of “another entity was certified as being able to make signatures which could be technically attributed to the Let's Encrypt CA” is. This doesn’t hold water at all. The Issuing CA is not certifying a proof of possession of a private key, so naturally you can’t (and shouldn’t) conclude it is a proof of possession of a private key. This is basic. > In this case, it becomes even more important for CAs to prove that the > private key is held by every person who claims it as being their public key > -- again, to change it from a theoretical/potential/too-expensive-to-act-on > threat to an actual key compromise scenario that mandates pushing the big > red button and holding a new key generation ceremony and regenerating the > PKI infrastructure and getting the new root key installed in browsers and > operating systems as soon as possible. > This is, continuing, nonsense. This is entirely unnecessarily precisely because it *isn’t* a proof of possession of private key. > (or, if it's an intermediate, generating a new intermediate, contacting > all legitimate recipients and having them change their certificate chains, > and revoking the one that had its key independently discovered.) > > Unfortunately, you can't have it both ways. What's more important, > correct certificate issuance (the issuance is by the entity trusted to > issue the certificate), or lack of disruption? The CA has always been > expected to err on the side of correct issuance (which is why, for example, > the Netherlands PKIOverheid intermediate was distrusted). > Again, you’re trying to call it both ways. You’re right to point out the logical absurdity of having your cake and eating it to, but you’re missing that you’re the one making that claim. The concerns you raise are there only if you believe it is a PoP. As I’ve said, repeatedly, it is not, nor should it be. These concerns entirely disappear. A TLS Certificate is an expression of authorization, by the domain holder, to allow a public key to be used for their domain. The domain holder is permitted to express whatever public key(s) they want, with all the attendant risk, and the certificate is an expression that the CA has verified that assertion and expression by the domain holder. Similarly, in the case of OV/EV, it’s similarly an expression
Re: Status of the bugzilla bug list
On Tue, May 19, 2020 at 5:53 AM Matthias van de Meent < matthias.vandeme...@cofano.nl> wrote: > Hi Ryan, > > On Tue, 19 May 2020 at 00:47, Ryan Sleevi wrote: > > > > Hi Matthias, > > > > We're aware of this. Could you explain what issue or issues this > > presents to you? > > One of the reasons I did this research was to check the track record > of CAs with regards to compliance and solving compliance issues. As > you might expect, this is quite difficult when the issues are not > updated regularly. I’m not sure I see the connection. For this scenario, it’s actually necessary to read the bugs. We do not use the bug metadata (e.g. opened, last updated, closed date) as part of our own analysis and processing, instead relying on reading the bugs themselves. The distinction closed / open is, (although skewed) a decent > indication for a CAs compliance track record and their readiness to > improve, especially when tracking open issues over time. When the > issue state is not linked to the actual solving of the compliance > issue, the skewed indication becomes even worse. Thanks. I don’t think we intend for it to be used as such, and so perhaps it’s not surprising that you find the current data unsatisfying. I would disagree that it’s a decent approximation, in part because that’s not something we guarantee, as you can see. I say this not to disagree that it “could” be useful, but it’s considerably more work and effort, and places the burden back on the Mozilla community to guarantee, for something that isn’t essential for our efforts or necessary for our tasks. For lack of a better comparison, it is a bit like asking why AIX or BeOS aren’t a tier 1 configuration ( https://firefox-source-docs.mozilla.org/build/buildsystem/supported-configurations.html ). The answer is because it’s significant burden for limited return. The MRSP section 2.4 asks the CA to promptly provide an incident > report, and regularly update this report until it is closed. My > opinion is that in this section Mozilla also has an implicit duty to > the CA - to mark issues as resolved when Mozilla and the CA agree that > the compliance issue has been resolved. Thanks. I don’t agree with that implicit duty assertion, and I think the only reason it comes up here is because it’s tied to a use case which is not presently supported. To use the previous metaphor, this is a bit like saying that if AIX/BeOS, then Mozilla has an implicit duty not to break the build. However, that ignores the notion of support tiers, and what guarantees, if any, are provided. Currently, I cannot see the forest for the trees due to so many issues > waiting to be closed, or having their next-update-by -windows long > passed, or just plain lack of communication about what is going on. > This makes it even more difficult to make informed decisions about > those CAs based on compliance track record. To close this out unambiguously: Using purely the bug metadata (i.e. the status, last modified date, etc) will not tell you this story. What you are trying to do is not presently supported. Would it be nice? Yes, I have no doubt. But that will require significantly more tooling and effort, on the part of Mozilla, and significant improvements by CAs. These are things that can be done, but are not zero cost, and are not on the most pressing of issues. It’s important to remember what this system replaced: threads on this mailing list. Threads which, by definition, are not “closed”, and which require reading with and examining in order to extract the timeline and structural data. The current use of Bugzilla is, for better or worse, a slight improvement on that system to help distinguish those threads and provide clearer signals to the CA with fewer messages, but it is not currently a full replacement for a structural, machine-readable timeline extraction. If you’d like to volunteer and contribute to the efforts to improve that, I’m happy to highlight areas for how additional tooling can help improve. This is certainly something we’ve discussed as a “nice to have”, but nowhere near the top of any of our priority lists. Patches to support this workflow would certainly be welcome. Hopefully that helps recalibrate expectations about what is currently supported, as it sounds like your use case is outside what’s supported. Also, hopefully it’s clearer that it’s not an unintentional decision, but an intentional one based on priorities and needs. Much like supporting an esoteric platform, there are non-trivial initial costs and startup costs, and as open source maintainers, sometimes the answer needs to be “No” ( https://blog.jessfraz.com/post/the-art-of-closing/ ). Again, if this is something that’s important to you, and you’re passionate about it, we’re happy to provide further details about how you can directly contribute to those efforts, so that at some point, in the future, it may be easier to support what you want it to be. >
Future of Certlint / CABLint (was Re: ZLint 2.1.0-RC1 and announcement list)
In other linter news... It has become clear that the original certlint/cablint repository (https://github.com/awslabs/certlint) is no longer being maintained. At Sectigo we still use cablint as one of our preissuance linters, and we've been running into more and more problems with cablint's stale PSL data and one or two out-of-date lints. We think it's useful to have multiple, independent certificate linting implementations, and so we believe that certlint/cablint still has value. Consequently, Sectigo Management has asked me to maintain a fork of the certlint/cablint repository. Here it is: https://github.com/certlint/certlint Collaborators would be very welcome! BTW, crt.sh is now using this new certlint fork. On 13/05/2020 17:23, Zakir Durumeric via dev-security-policy wrote: Hi all, Earlier this year, we began publishing semantically versioned ZLint releases based on several requests from CAs. Yesterday, we tagged 2.1.0-RC1 (https://github.com/zmap/zlint/releases/tag/v2.1.0-rc1), which includes the first batch of Mozilla Root Store Policy lints. We have created a new minimal-traffic announcement list, which is where we will be announcing releases and other major project updates in the future: https://groups.google.com/forum/#!forum/zlint-announcements. Thanks, Zakir -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Status of the bugzilla bug list
Hi Ryan, On Tue, 19 May 2020 at 00:47, Ryan Sleevi wrote: > > Hi Matthias, > > We're aware of this. Could you explain what issue or issues this > presents to you? One of the reasons I did this research was to check the track record of CAs with regards to compliance and solving compliance issues. As you might expect, this is quite difficult when the issues are not updated regularly. The distinction closed / open is, (although skewed) a decent indication for a CAs compliance track record and their readiness to improve, especially when tracking open issues over time. When the issue state is not linked to the actual solving of the compliance issue, the skewed indication becomes even worse. > Understanding that different projects can and do use different > workflows to address their needs, it's not immediately clear to me > what impact, if any, this might have for you, and it's unclear why the > distinction between an open bug and a closed bug should be something > you're concerned about. The MRSP section 2.4 asks the CA to promptly provide an incident report, and regularly update this report until it is closed. My opinion is that in this section Mozilla also has an implicit duty to the CA - to mark issues as resolved when Mozilla and the CA agree that the compliance issue has been resolved. Concerns start to appear when both the CA and Mozilla do not adhere to the policy that they agreed to, be it explicit (the CA) or implicit (Mozilla), as all I see is a slippery slope. Although I know there is no clear timeframe asked for in the MRSP, I do want to ask the related parties to at least improve upon the current 4w+ timescale, and/or add realistic next update dates to their compliance issues. > Understanding what problem(s) you're trying to solve seems more > productive/useful way to get them addressed. What difference does the > distinction make for you? I expect that an open issue is open-ended, has missing information or has incomplete tasks and thus tells an incomplete story, and that a closed issue provides an understanding of what the compliance issue was, and how it was solved. When this open/closed distinction becomes less clear due to the not closing of issues, it takes longer to provide an indication that the issue has been solved, and any lessons learned take longer to propagate to other interested parties (as I see it). Currently, I cannot see the forest for the trees due to so many issues waiting to be closed, or having their next-update-by -windows long passed, or just plain lack of communication about what is going on. This makes it even more difficult to make informed decisions about those CAs based on compliance track record. With regards, Matthias ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
