Re: Symantec response to Google proposal
On 20/06/17 01:21, Jakob Bohm wrote: > 2. For any certificate bundle that needs to be incorporated into the > Mozilla root stores, a significant period (3 to 6 months at least) > will be needed between acceptance by Mozilla and actual trust by > Mozilla users. Not if the roots were cross-signed by the old PKI. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable
On Monday, June 19, 2017 at 11:40:22 PM UTC-5, Tom Ritter wrote: > So at what point does the CA become culpable to misissuance in a case > like this? Is it okay that we let them turn a blind eye to issuing or > reissuing certificates where they have a strong reason to believe the > private key will be published in firmware? Pretty much any DV validated certificate could be used the way Cisco's software used this one... Unless we want to create new burdens for every DV validating CA out there, I don't think it's practical to pre-suppose that a similar certificate will get similar misuse. The right balance is probably revoking when misuse is shown. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable
On 19 June 2017 at 08:28, Samuel Pinder via dev-security-policy wrote: > Therefore the newly re-issued > certificate *will* end up with it's private key compromised *again*, > no matter how well it may be obfuscated in the application, it is > still against the very principle. I'm pretty confused by this as well. First off, while people have proposed multiple solutions to this problem, they are not trivially implementable, nor are they widespread. I think if you shook the tree with some automation, you'd find on the order of 50 or more publicly trustable private keys embedded in firmware pretty quickly. So at what point does the CA become culpable to misissuance in a case like this? Is it okay that we let them turn a blind eye to issuing or reissuing certificates where they have a strong reason to believe the private key will be published in firmware? Clearly we wouldn't require them to vet every use of every certificate they issue, but if they revoke a certificate for being used in this fashion, it seems reasonable for them to ask the customer to at least give them an explanation of how they've changed things such that a newly issue certificate for the same domain will not be used in the exact same way. Is it reasonable for us to ask a CA to do this (that is, to ask their customer)? Is it reasonable to require it? -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable
On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via dev-security-policy wrote: > If you should find such an issue again in a Cisco owned domain, please > report it to ps...@cisco.com and we will ensure that prompt and proper > actions are taken. I don't know, this way seems to have worked Just Fine. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec response to Google proposal
Notes on your below suggested timeline: 1. I see no reason to have that many new root bundles from Symantec. Ideally, there would be just two bundles: A transitional root bundle which signs the outsourced SubCAs only, and a final bundle intended to become the new long-term Symantec roots. The transitional root bundle would be made in a subset of the current Symantec infrastructure, while the final bundle would be generated in the new higher security infrastructure isolated from any historic bugs in the old infrastructure. 2. For any certificate bundle that needs to be incorporated into the Mozilla root stores, a significant period (3 to 6 months at least) will be needed between acceptance by Mozilla and actual trust by Mozilla users. This would involve time to complete the following: 2.1 Adding the new roots to the NSS store source code. 2.2 Actually incorporating that updated NSS store into release candidate builds of all Mozilla products. 2.3 Releasing those builds of Mozilla products to the general public 2.4a Waiting for the majority of users (especially those with telemetry and other phone-home behavior disabled) to install the updated Mozilla products. 2.4b Waiting for enterprise users to incorporate the updated Mozilla products into new system images and rolling out those system images. 2.4c Waiting for users to migrate beyond Firefox ESR 52 due to disrupting non-PKI changes (feature removals) made at that point. Similar for future feature-disrupting Mozilla product changes. (Note this is not a complaint about the breaking changes beyond Fx ESR 52, just an observation that such actions by other Mozilla teams can cause a significant delay in the deployment of NSS root store changes). On 16/06/2017 14:43, Peter Kurrasch wrote: My thoughts: 2) Timeline. I agree with Symantec that Google's original deadlines are far too aggressive, for 2 reasons. First, I do not think Symantec can move quickly without causing further damage. Second, I do not think Symantec's customers can move quickly at all given that a majority of them are large corporations that have to coordinate budgets, staff, outsourcing firms, and so forth. These customers also need time to familiarize themselves with the new rules and identify a course of action that makes sense for their business environments and their user base. Even though I understand the desire to move quickly, in this situation it seems imprudent to do so. Many will find this next bit unacceptable, but in the interest of providing an alternative, let me suggest a timeline of 6 different dates over the next 2 years (in case it really does take that long): the 21st day of February, May, and August of 2018 & 2019. Each of these dates represent a different milestone for changes in policy enforcement, certificate validation, software and systems, and whatever is identified as a deliverable in these ongoing discussions. The dates here are chosen specifically to acknowledge that many businesses operate on a quarterly system while avoiding complications that inevitably take place at the end of a quarter and the end of the year. And, yes, that would imply no action taken before Feb of next year. 1) Scope of Distrust First a question: is removing the EV entitlements from the Symantec roots something that is still on the table for Mozilla products or has that been dismissed for some reason? I ask because it hardly seems appropriate that a CA under sanction be entitled to all the benefits that are extended to CA's which are not under sanction. Doing so also inflicts some pain on Symantec (without breaking the global economy) until such time as they've resolved their issues to Mozilla's satisfaction. Regarding the expiration of certificates, I do not agree that CT logging engenders trust so I disagree with Symantec on that. Frankly I don't entirely agree with Google on the phased dis-trust and CT logging items. Those seem to increase complexity in the PKI ecosystem (which carries its own risk) without necessarily improving the ecosystem, but it's very likely I've missed some important details. As to scope itself, my understanding is that Mozilla will eventually remove trust from all current Symantec roots (the "ubiquitous roots") and in its place use a set of "new roots", some of which will be under the purview of Symantec competitors. These new roots will be cross-signed to those ubiquitous roots so that new certs that chain up to these new roots will still validate properly on products that have not or cannot be updated to use the new roots. (If my understanding is incorrect, I hope someone will correct me.) To put it another way, all existing certs that chain up to the ubiquitous roots will eventually stop working--many before their date of normal expiration. As such, there needs to be a ramp up of new cert issuing capacity while at the same time a phasing out of the existing
Re: [EXT] Mozilla requirements of Symantec
On 12/06/2017 22:12, Nick Lamb wrote: On Monday, 12 June 2017 17:31:58 UTC+1, Steve Medin wrote: We think it is critically important to distinguish potential removal of support for current roots in Firefox versus across NSS. Limiting Firefox trust to a subset of roots while leaving NSS unchanged would avoid unintentionally damaging ecosystems that are not browser-based but rely on NSS-based roots such as code signing, closed ecosystems, libraries, etc. Abusing NSS to support code signing or "closed ecosystems" would be an error regardless of what happens to Symantec, it makes no real sense for us to prioritize supporting such abuse. To the extent that m.d.s.policy represents consumers of NSS certdata other than Firefox, they've _already_ represented very strongly that what they want is for this data to follow Mozilla's trust decisions more closely not less. I believe you are exaggerating in that assertion. NSS until fairly recently was in fact used for code signing of Firefox extensions using the public PKI (this is why there is a defunct code signing trust bit in the NSS root store). I also believe that the current checking of "AMO" signatures is still done by NSS, but not using the public PKI. This makes it completely reasonable for other users of the NSS libraries to still use it for code signing, provided that the "code signing" trust bits in the NSS root store are replaced with an independent list, possibly based on the CCADB. It also makes it likely that systems with long development / update cycles have not yet deployed their own replacement for the code signing trust bits in the NSS root store, even if they have a semi-automated system importing changes to the NSS root store. That would of cause be a mistake on their part, but a very likely mistake. 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: Unknown Intermediates
On Monday, 19 June 2017 20:57:28 UTC+1, Tavis Ormandy wrote: > I noticed there's an apparently valid facebook.com certificate in there > (61b1526f9d75775c3d533382f36527c9.pem). This is surprising to me, that > seems like it would be in CT already - so maybe I don't know what I'm doing. > > Let me know if I've misunderstood something. > > Tavis. Thanks for uploading these. I submitted that one in particular which can now be seen here: https://crt.sh/?id=157454198 This is the certificate for a precertificate which was already in the CT logs: https://crt.sh/?id=81124044 (crt.sh handily has links in both directions between both certificates now that it knows about both) and the issuance is therefore "known" already, but the final signed certificate was not seen by any logs. It is useful to have the final certificate now as well. I haven't looked at any of the others, but I imagine this case only covers a small percentage of the total. When someone here with a more automated approach to submitting the certificates (along with their intermediates) analyses them I imagine we will see some interesting results. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ETSI auditors still not performing full annual audits?
On Monday, June 19, 2017 at 12:21:46 PM UTC-7, Peter Bowen wrote: > It seems there is some confusion. The document presented would appear > to be a Verified Accountant Letter (as defined in the EV Guidelines) > and can used as part of the process to validate a request for an EV > certificate. It is not an audit report and is not something normally > submitted to browsers. Yet, it is the document that was provided to root store operators as the annual audit statement. And there has been plenty of time in Bug #1142323 for that to have been rectified. As reference, here is the audit statement that was provided in 2016: https://bug343756.bmoattachments.org/attachment.cgi?id=8781268 It says: "KPMG has executed a main certification audit in year 2013, and surveillance certification audits in 2014 and 2015..." "We were engaged to conduct the annual examinations, with the objective of which would be the expression of an opinion on the application for Extended Validation (EV) Certificates. Accordingly we do express our positive opinion and provide you confirmation that the requirements were fulfilled during the annual certification audits... " In the audit statement in question (https://bug1142323.bmoattachments.org/attachment.cgi?id=8853299) it says: "KPMG has executed a main certification audit in year 2017..." So I took that to mean that this was intended to be their annual audit statement, and the format is very similar to the audit statement from the previous year. But as I read through it I noticed phrases like "point in time audit". And then it said: "We were not engaged to and did not conduct an examination, the objective of which would be the expression of an opinion on the Application for Extended Validation (EV) Certificate. Accordingly, we do not express such an opinion. Had we performed additional procedures, other matters might have come to our attention that would have been reported to you." This is very different from the statement the previous year. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable
I wonder if the device intercepts DNS queries within the LAN for that address and substitutes in the IP of the appliance instead of 127.0.0.1. Is it often deployed as the customer premise NAT/router in addition to serving video purposes? I'm thinking they probably wanted some other devices or browsers on the local LAN to access, via https, the appliance on the LAN. And they wanted it to have a trusted cert for that purpose. They just didn't want to have to deal with unique name and cert per device. Which, as has been pointed out repeatedly is a violation of the CA <-> subscriber agreement, because the baselines require that the CA <-> subscriber agreement forbid this. It looks to me like someone wanted to avoid the need to have a unique certificate issued for each device. The easy way forward would be for them to create a new domain, run their own dynamic DNS service for each device on that domain (get said domain on the PSL) and develop software for it to fetch and update valid certificates for these IoT devices. Presumably they could roll their own DNS infrastructure and even use something like Let's Encrypt, though I'm not certain whether Let's Encrypt is on the record as to what they'd think of such a use case. In as far as Cisco has requested a new drmlocal.cisco.com certificate Why? They can't use it the new certificate in the same way again (or it would just get revoked again) and the real drmlocal.cisco.com record points to 127.0.0.1, so it's not like they have a real central drmlocal.cisco.com site that needs a certificate. I think the "local" part of the name is probably most telling. They likely came up with that name because ciscodrm.local would have been impossible to get a valid cert for. Matt Hardeman ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Principles and Goals
I think it might be useful to take a step back and remind ourselves of Mozilla's mission, principles and goals with regard to resolving the situation with Symantec. These will be useful as we flesh out the details of the consensus proposal, particularly concerning dates. First, a quick reminder on goals, anti-goals and non-goals. Goal: something you specifically want to achieve. Anti-goal: something you specifically want to not achieve. Non-goal: something you are explicitly not trying to achieve. Non-goals differ from anti-goals in that you will try hard not to achieve an anti-goal, but you don't mind either way whether a non-goal happens or not. In deciding what is a goal, anti-goal or non-goal, we need to establish our principles, which in this case I will define as higher-level things we believe and are trying to achieve with our root program which are not specific to this particular situation. Mozilla's principles relating to this situation all flow from our overarching mission to do good to and for the Web, and the manifesto principle that the security of web citizens is essential. More specifically, I would characterise our principles here as follows: Root Program Principles --- 1) Maintain the public's trust in the WebPKI as a whole. 2) In any change, minimise disruption to websites and web end-users. 3) Make decisions for the benefit of Mozilla and its mission first. 4) Operate in a transparent, consultative and open way. In this case, we are attempting to maintain trust in the WebPKI by executing the sub-task of eliminating hierarchies, systems and/or issuers who have lost trust. So our goals in this particular situation, where we no longer have trust in Symantec's "old" (current) PKI, are therefore: Symantec Remediation Goals -- A) Remove the roots relating to the old Symantec PKI from our root store as quickly as possible. B) Before we can do so, take interim steps to minimise risk by reducing the scope of trust in their old PKI, such as: * not trusting new Symantec-controlled issuance; * not trusting certs without proof of publication; and/or * not trusting certs issued before a certain date; all as quickly as possible. C) Make sure that those certificate users with a hard dependency on Symantec's old PKI and also a requirement for public trust have, or mostly have, sufficient transition time to eliminate that dependency. Something which is a non-goal is that Symantec be able to continue issuing all the same types of certs at the same volumes to all of their customers without interruption. This will almost certainly be a goal for Symantec, but it's not a goal for Mozilla. It must be pointed out that it's not an anti-goal either - we are not _aiming_ to affect Symantec's business. But we are not going to take decisions which treat maintaining those capabilities unchanged as a goal. This point will become important when Symantec publishes the results of the process they are currently going through to find CAs to work with them on taking over issuance from their old PKI. Their plans and the dates associated with them will, no doubt, be predicated on that goal, which is not our goal (but to repeat, is not an anti-goal), and will need to be evaluated in that light. Symantec also need to be clear that "we signed a contract to meet this goal" is not an argument which will cause that goal to become Mozilla's goal. Any set of dates we require which are not "as long as you need" will inevitably have a level of arbitrariness about them. Why not a week more? Why not a week less? I think it would be unhelpful, therefore, to get into a date-based "negotiation". We need to make our best estimate of how long it would take Symantec and their partners to put in place systems which allow our goals to be met, and choose deadlines accordingly. The only other thing which might modify our requirements is the fact that this is a consensus proposal we are implementing. Consensus is a good thing for the WebPKI and for Symantec, who I'm sure would not welcome the prospect of implementing several different remediation plans at the same time. Therefore, we should also take into account the published principles and goals of other root store operators who are part of the consensus, and how the proposal might need to be written to also meet their goals. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Unknown Intermediates
I noticed there's an apparently valid facebook.com certificate in there (61b1526f9d75775c3d533382f36527c9.pem). This is surprising to me, that seems like it would be in CT already - so maybe I don't know what I'm doing. Let me know if I've misunderstood something. Tavis. On Mon, Jun 19, 2017 at 12:41 PM, Tavis Ormandy wrote: > Thanks Alex, I took a look, it looks like the check pings crt.sh - is > doing that for a large number of certificates acceptable Rob? > > I made a smaller set, the certificates that have 'SSL server: Yes' or 'Any > Purpose : Yes', there were only a few thousand that verified, so I just > checked those and found 551 not in crt.sh. > > (The *vast* majority are code signing certificates, many are individual > apple developer certificates) > > Is this useful? if not, what key usage is interesting? > > https://lock.cmpxchg8b.com/ServerOrAny.zip > > Tavis. > > On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor wrote: > >> If you're interested in playing around with submitting them yourself, or >> checking if they're already submitted, I've got some random tools for >> working with CT: https://github.com/alex/ct-tools >> >> Specifically ct-tools check will get what you >> want. It's all serial, so for 8M certs you probably want to Bring Your Own >> Parallelism (I should fix this...) >> >> Alex >> >> On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote: >>> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote: >>> >>> Is there an easy way to check which certificates from my set you're > missing? (I'm not a PKI guy, I was collecting unusual extension OIDs > for fuzzing). > > I collected these from public sources, so can just give you my whole > set if you already have tools for importing them and don't mind > processing them, I have around ~8M (mostly leaf) certificates, the > set with isCa will be much smaller. > Please do post the whole set. I suspect there are several people on this list (including myself and Rob) who have the tools and experience to process large sets of certificates and post them to public Certificate Transparency logs (whence they will be fed into crt.sh). It would be useful to include the leaf certificates as well, to catch CAs which are engaging in bad practices such as signing non-SSL certs with SHA-1 under an intermediate that is capable of issuing SSL certificates. Thanks a bunch for this! >>> >>> +1 >>> >>> Tavis, please do post the whole set. And thanks! >>> >>> -- >>> 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 >>> >> >> > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Unknown Intermediates
Thanks Alex, I took a look, it looks like the check pings crt.sh - is doing that for a large number of certificates acceptable Rob? I made a smaller set, the certificates that have 'SSL server: Yes' or 'Any Purpose : Yes', there were only a few thousand that verified, so I just checked those and found 551 not in crt.sh. (The *vast* majority are code signing certificates, many are individual apple developer certificates) Is this useful? if not, what key usage is interesting? https://lock.cmpxchg8b.com/ServerOrAny.zip Tavis. On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor wrote: > If you're interested in playing around with submitting them yourself, or > checking if they're already submitted, I've got some random tools for > working with CT: https://github.com/alex/ct-tools > > Specifically ct-tools check will get what you > want. It's all serial, so for 8M certs you probably want to Bring Your Own > Parallelism (I should fix this...) > > Alex > > On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote: >> >>> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote: >>> >> >> >>> Is there an easy way to check which certificates from my set you're missing? (I'm not a PKI guy, I was collecting unusual extension OIDs for fuzzing). I collected these from public sources, so can just give you my whole set if you already have tools for importing them and don't mind processing them, I have around ~8M (mostly leaf) certificates, the set with isCa will be much smaller. >>> >>> Please do post the whole set. I suspect there are several people on >>> this list (including myself and Rob) who have the tools and experience >>> to process large sets of certificates and post them to public >>> Certificate Transparency logs (whence they will be fed into crt.sh). >>> >>> It would be useful to include the leaf certificates as well, to catch >>> CAs which are engaging in bad practices such as signing non-SSL certs >>> with SHA-1 under an intermediate that is capable of issuing SSL >>> certificates. >>> >>> Thanks a bunch for this! >>> >> >> +1 >> >> Tavis, please do post the whole set. And thanks! >> >> -- >> 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 >> > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ETSI auditors still not performing full annual audits?
On Mon, Jun 19, 2017 at 12:14 PM, Kathleen Wilson via dev-security-policy wrote: > I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1374381 about an > audit statement that I received for SwissSign. I have copied the bug > description below, because I am concerned that there still may be ETSI > auditors (and CAs?) who do not understand the audit requirements, see below. > > ~~~ > SwissSign provided their annual audit statement: > https://bug1142323.bmoattachments.org/attachment.cgi?id=8853299 > > Problems noted in it: > -- "Agreed-upon procedures engagement" - special words for audits - does not > necessarily encompass the full scope > -- "surveillance certification audits" - does not necessarily mean a full > audit (which the BRs require annually) > -- "point in time audit" -- this means that the auditor's evaluation only > covered that point in time (note a period in time) > -- "only intended for the client" -- Doesn't meet Mozilla's requirement for > public-facing audit statement. > -- "We were not engaged to and did not conduct an examination, the objective > of which would be the expression of an opinion on the Application for > Extended Validation (EV) Certificate. Accordingly, we do not express such an > opinion. Had we performed additional procedures, other matters might have > come to our attention that would have been reported to you." -- some of the > included root certs are enabled for EV treatment, so need an EV audit as well. > > > According to section 8.1 of the CA/Browser Forum's Baseline Requirements: > "Certificates that are capable of being used to issue new certificates MUST > ... be ... fully audited in line with all remaining requirements from this > section. > ... > The period during which the CA issues Certificates SHALL be divided into an > unbroken sequence of audit periods. An audit period MUST NOT exceed one year > in duration." > > So, a full period-in-time audit is required every year. > > After I voiced concern > (https://bugzilla.mozilla.org/show_bug.cgi?id=1142323#c27) the CA provided an > updated audit statement to address the concerns I had raised in the bug: > https://bugzilla.mozilla.org/attachment.cgi?id=8867948 > I do not understand how the audit statement can magically change from > point-in-time to a period-in-time. > ~~~ > > I will greatly appreciate thoughtful and constructive input into this > discussion about what to do about this SwissSign audit situation, and if this > is an indicator that ETSI auditors are still not performing full annual > audits that satisfy the CA/Browser Forum's Baseline Requirements. Kathleen, It seems there is some confusion. The document presented would appear to be a Verified Accountant Letter (as defined in the EV Guidelines) and can used as part of the process to validate a request for an EV certificate. It is not an audit report and is not something normally submitted to browsers. I suspect someone simply attached the wrong document to an email or uploaded the wrong document. This makes no sense to be part of an audit report. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
ETSI auditors still not performing full annual audits?
I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1374381 about an audit statement that I received for SwissSign. I have copied the bug description below, because I am concerned that there still may be ETSI auditors (and CAs?) who do not understand the audit requirements, see below. ~~~ SwissSign provided their annual audit statement: https://bug1142323.bmoattachments.org/attachment.cgi?id=8853299 Problems noted in it: -- "Agreed-upon procedures engagement" - special words for audits - does not necessarily encompass the full scope -- "surveillance certification audits" - does not necessarily mean a full audit (which the BRs require annually) -- "point in time audit" -- this means that the auditor's evaluation only covered that point in time (note a period in time) -- "only intended for the client" -- Doesn't meet Mozilla's requirement for public-facing audit statement. -- "We were not engaged to and did not conduct an examination, the objective of which would be the expression of an opinion on the Application for Extended Validation (EV) Certificate. Accordingly, we do not express such an opinion. Had we performed additional procedures, other matters might have come to our attention that would have been reported to you." -- some of the included root certs are enabled for EV treatment, so need an EV audit as well. According to section 8.1 of the CA/Browser Forum's Baseline Requirements: "Certificates that are capable of being used to issue new certificates MUST ... be ... fully audited in line with all remaining requirements from this section. ... The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration." So, a full period-in-time audit is required every year. After I voiced concern (https://bugzilla.mozilla.org/show_bug.cgi?id=1142323#c27) the CA provided an updated audit statement to address the concerns I had raised in the bug: https://bugzilla.mozilla.org/attachment.cgi?id=8867948 I do not understand how the audit statement can magically change from point-in-time to a period-in-time. ~~~ I will greatly appreciate thoughtful and constructive input into this discussion about what to do about this SwissSign audit situation, and if this is an indicator that ETSI auditors are still not performing full annual audits that satisfy the CA/Browser Forum's Baseline Requirements. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Unknown Intermediates
If you're interested in playing around with submitting them yourself, or checking if they're already submitted, I've got some random tools for working with CT: https://github.com/alex/ct-tools Specifically ct-tools check will get what you want. It's all serial, so for 8M certs you probably want to Bring Your Own Parallelism (I should fix this...) Alex On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote: > >> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote: >> > > >> Is there an easy way to check which certificates from my set you're >>> missing? (I'm not a PKI guy, I was collecting unusual extension OIDs >>> for fuzzing). >>> >>> I collected these from public sources, so can just give you my whole >>> set if you already have tools for importing them and don't mind >>> processing them, I have around ~8M (mostly leaf) certificates, the >>> set with isCa will be much smaller. >>> >> >> Please do post the whole set. I suspect there are several people on >> this list (including myself and Rob) who have the tools and experience >> to process large sets of certificates and post them to public >> Certificate Transparency logs (whence they will be fed into crt.sh). >> >> It would be useful to include the leaf certificates as well, to catch >> CAs which are engaging in bad practices such as signing non-SSL certs >> with SHA-1 under an intermediate that is capable of issuing SSL >> certificates. >> >> Thanks a bunch for this! >> > > +1 > > Tavis, please do post the whole set. And thanks! > > -- > 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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable
There's more than just a clue in the name drmlocal.cisco.com , if one looks up this address in the DNS it returns the loopback IP 127.0.0.1 . http://dnstools.ws/tools/lookup.php?host=drmlocal.cisco.com&type=A This can only mean that this address is fully intended to be referred to only by one's own machine that the NowTV software is running on. There's probably an architectural reason why a publicly trusted certificate is used. But the way it's been implemented clearly does mean that the private key ends up being shipped, which, even if it didn't break the Baseline Requirements, it goes against the very principle of PKI cryptography. Therefore the newly re-issued certificate *will* end up with it's private key compromised *again*, no matter how well it may be obfuscated in the application, it is still against the very principle. Is a publicly-trusted certificate even needed here? Another this could have been done is what anti-virus programs often resort to doing: installing a self-signed root into the OS (and other browser stores) as part of the client installation process and generating certificates on-the-fly directly off of it. But then that would mean that if anyone compromised the key for that, it could potentially put many users whom use NowTV at risk unless that self-signed root was constrained in some way. *However* this would mean at least, it no longer breaks the Baseline Requirements as it would no longer be within it's scope. I'm no expert here at all, and I do dislike the idea of this kind of behaviour completely (and I could be completely wrong about why drmlocal.cisco.com is used). NowTV might want to consider their options here, but shipping a private key and trusted certificate with an application, really isn't the way. In summary: I believe a compromise will happen again as it is clear drmlocal.cisco.com is deliberately intended to refer to one's own machine. Sam On Mon, Jun 19, 2017 at 1:50 PM, Nick Lamb via dev-security-policy wrote: > On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com wrote: >>The compromised certificate for drmlocal.cisco.com serial number >> 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked. A new certificate >> is being reissued to drmlocal.cisco.com and we will work with the developers >> of the YES video player to ensure that the issue does not happen again. > > Troy, the name makes me suspicious, what - other than this trick which isn't > a permissible use - was the drmlocal.cisco.com name ever for in the first > place? If it doesn't have any legitimate use, there was no purpose in seeking > a re-issue of the certificate. > > The right way to approach this problem will be to issue unique keys and > certificates to individual instances of the system, this both satisfies the > BRs and (which is why) achieves the actual security goal of partitioning each > customer so that they can't MitM each other. > > It is a little surprising to me that (at least so far as I know) no > manufacturer has an arrangement with a CA to issue them large volumes of > per-device certificates in this way. I expect that Comodo (to name one which > definitely has business issuing very large volumes) would be able to > accommodate a deal to issue say, a million certificates per year with an > agreed suffix (say, .nowtv.cisco.com) for a fixed fee. The first time it's > attempted there would be some engineering work to be done in production and > software for the system, but nothing truly novel and that work is re-usable > for future products. > ___ > 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: Private key corresponding to public key in trusted Cisco certificate embedded in executable
Nick, We do exactly that for some device producers already. Robin Alden, Comodo. (Sent from my phone) Nick Lamb via dev-security-policy wrote >On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com wrote: >>The compromised certificate for drmlocal.cisco.com serial number >> 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked. A new certificate >> is being reissued to drmlocal.cisco.com and we will work with the developers >> of the YES video player to ensure that the issue does not happen again. > >Troy, the name makes me suspicious, what - other than this trick which isn't a >permissible use - was the drmlocal.cisco.com name ever for in the first place? >If it doesn't have any legitimate use, there was no purpose in seeking a >re-issue of the certificate. > >The right way to approach this problem will be to issue unique keys and >certificates to individual instances of the system, this both satisfies the >BRs and (which is why) achieves the actual security goal of partitioning each >customer so that they can't MitM each other. > >It is a little surprising to me that (at least so far as I know) no >manufacturer has an arrangement with a CA to issue them large volumes of >per-device certificates in this way. I expect that Comodo (to name one which >definitely has business issuing very large volumes) would be able to >accommodate a deal to issue say, a million certificates per year with an >agreed suffix (say, .nowtv.cisco.com) for a fixed fee. The first time it's >attempted there would be some engineering work to be done in production and >software for the system, but nothing truly novel and that work is re-usable >for future products. >___ >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: Private key corresponding to public key in trusted Cisco certificate embedded in executable
On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com wrote: >The compromised certificate for drmlocal.cisco.com serial number > 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked. A new certificate > is being reissued to drmlocal.cisco.com and we will work with the developers > of the YES video player to ensure that the issue does not happen again. Troy, the name makes me suspicious, what - other than this trick which isn't a permissible use - was the drmlocal.cisco.com name ever for in the first place? If it doesn't have any legitimate use, there was no purpose in seeking a re-issue of the certificate. The right way to approach this problem will be to issue unique keys and certificates to individual instances of the system, this both satisfies the BRs and (which is why) achieves the actual security goal of partitioning each customer so that they can't MitM each other. It is a little surprising to me that (at least so far as I know) no manufacturer has an arrangement with a CA to issue them large volumes of per-device certificates in this way. I expect that Comodo (to name one which definitely has business issuing very large volumes) would be able to accommodate a deal to issue say, a million certificates per year with an agreed suffix (say, .nowtv.cisco.com) for a fixed fee. The first time it's attempted there would be some engineering work to be done in production and software for the system, but nothing truly novel and that work is re-usable for future products. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Unknown Intermediates
On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote: On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote: Is there an easy way to check which certificates from my set you're missing? (I'm not a PKI guy, I was collecting unusual extension OIDs for fuzzing). I collected these from public sources, so can just give you my whole set if you already have tools for importing them and don't mind processing them, I have around ~8M (mostly leaf) certificates, the set with isCa will be much smaller. Please do post the whole set. I suspect there are several people on this list (including myself and Rob) who have the tools and experience to process large sets of certificates and post them to public Certificate Transparency logs (whence they will be fed into crt.sh). It would be useful to include the leaf certificates as well, to catch CAs which are engaging in bad practices such as signing non-SSL certs with SHA-1 under an intermediate that is capable of issuing SSL certificates. Thanks a bunch for this! +1 Tavis, please do post the whole set. And thanks! -- 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: Private key corresponding to public key in trusted Cisco certificate embedded in executable
Section 9.6.3, Items 2, 4, and 5, of Baseline Requirements 1.4.5 (current version) On Sun, Jun 18, 2017 at 11:36 AM, Eric Mill via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > One question though, is whether the key was compromised at the time of > intentionally shipping it in a distributed executable. That choice > knowingly exposed the key to arbitrary public users, even if they didn't > expect this to happen from doing so. > > -- Eric > > On Jun 18, 2017 10:24 AM, "Ryan Sleevi via dev-security-policy" < > dev-security-policy@lists.mozilla.org> wrote: > > > As Daniel noted, this is considered a key compromise event, and a > violation > > of the subscriber agreement that all CAs are required to adhere to, with > > respect to the protection of the private key. > > > > The issuing CA is obligated to revoke this certificate within 24 hours of > > being made aware of this. > > > > Thank you for bringing it to the community's attention. > > > > On Sun, Jun 18, 2017 at 12:29 PM Daniel Cater via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > This is now on crt.sh here: > > > https://crt.sh/?id=156475584&opt=cablint,x509lint > > > > > > This is indeed a key compromise event, thanks for the level of detail > > > provided. > > > > > > An attacker in control of a network could use this to impersonate > > > https://drmlocal.cisco.com/ and leverage that to potentially steal a > > > user's secure cookies from other Cisco subdomains if they were scoped > to > > > the whole cisco.com domain. > > > ___ > > > 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 > > > ___ > 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: Turktrust SubCA abuse and MITM'ing
I found two and they were both expired so I disable them and did some research which ended me in many sites and also here in this forum. If this happened so long ago and was caught why is it in my Galaxy Grand Prime that I bought brand-new less than two years ago.This is one- TURKTRUST_Certificate_Services_Provider_Root_2. The thumprint is b4:35:d4:e1:11:9d:1c:66:90:a7:49:eb:b3:94:bd:63:7b:a7:82:b7. The other is similar but not exact. I disable them but they were there for two years. I updated if they're still there. Need advice? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Koen, The compromised certificate for drmlocal.cisco.com serial number 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked. A new certificate is being reissued to drmlocal.cisco.com and we will work with the developers of the YES video player to ensure that the issue does not happen again. If you should find such an issue again in a Cisco owned domain, please report it to ps...@cisco.com and we will ensure that prompt and proper actions are taken. Regards, - -Troy - -- Troy Fridley, CISSP Incident Manager, Cisco PSIRT Phone: 614-336-4385 E-Mail: troy.fridleyATcisco.com PGP Key ID: 0x7B31ED20 -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAllGmSwACgkQ1ANYX3sx7SASCgCg/ABvJQZSZf+pIG16AMgMPwF8 z4oAnRrpx2I5NJizxg2H1aftlwyJ15fT =ayil -END PGP SIGNATURE- On Sunday, June 18, 2017 at 5:18:23 AM UTC-4, Koen Rouwhorst wrote: > > If this is indeed considered a key compromise, where do I go from here, and > what are the recommended steps to take? Do I need to contact the subscriber > (Cisco), and ask them to send a revocation request for this certificate to > the issuer? Or do I need to notify the issuer (HydrantID), and ask them to > revoke this certificate? > > Thanks. > > Best regards, > Koen Rouwhorst ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable
On Monday, June 19, 2017 at 1:27:46 AM UTC+3, Nick Lamb wrote: > On Sunday, 18 June 2017 16:37:13 UTC+1, Eric Mill wrote: > > One question though, is whether the key was compromised at the time of > > intentionally shipping it in a distributed executable. That choice > > knowingly exposed the key to arbitrary public users, even if they didn't > > expect this to happen from doing so. > > Yes, the subscriber intentionally compromised this key when they implemented > this decision. This was a foreseeable consequence. If they didn't foresee it, > that's not because it wasn't foreseeable but because they're foolish. A > reasonable person who understood what was going on here (public key > cryptography, the purpose of certificates in the Web PKI) should have > understood they were intentionally compromising their key. You assume too much about a "reasonable person". Yes, most developers understand PKI / key management to a point, but many (many) just don't, or do and simply make the mistake of not thinking it through, like many other software defects. Bottom line - could happen unintentionally. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
