Re: FW: StartCom inclusion request: next steps
On Tue, Sep 19, 2017 at 3:09 PM, Nick Lamb via dev-security-policy wrote: > I have no doubt that this was obvious to people who have worked for a public > CA, but it wasn't obvious to me, so thank you for answering. I think these > answers give us good reason to be confident that a cross-signed certificate > in this situation would not be available to either end subscribers or > StartCom unless/ until the CA which cross-signed it wanted that to happen. > > It might still make sense for Mozilla to clarify that this isn't a good idea, > or even outright forbid it anyway, but I agree with your perspective that > this seemed permissible under the rules as you understood them and wasn't > obviously unreasonable. I'm pretty sure it's already forbidden, since policy version 2.5 anyway (has effective date after the Certinomis shenanigans though): "The CA with a certificate included in Mozilla’s root program MUST disclose this information within a week of certificate creation, and before any such subordinate CA is allowed to issue certificates." 2.5 added the "within a week of certificate creation" [1] . "Creation" vs "My Safe", "Creation" wins. :-) [1] https://github.com/mozilla/pkipolicy/commit/b7d1b6c04458114fbe73fa3f146ad401235c2a1b ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Old roots to new roots best practice?
On Monday, September 18, 2017 at 1:58:03 AM UTC, Ryan Sleevi wrote: > I agree, Gerv's remarks are a bit confusing with respect to the concern. > You are correct that the process of establishing a new root generally > involves the creation of a self-signed certificate, and then any > cross-signing that happens conceptually creates an 'intermediate' - so you > have a key shared by a root and an intermediate. > > This is not forbidden; indeed, you can see in my recent suggestions to > Symantec/DigiCert, it can and often is the best way for both compatibility > and interoperability. Method #2 that you mentioned, while valid, can bring > much greater compatibility challenges, and thus requires far more careful > planning and execution (and collaboration both with servers and in > configuring AIA endpoints) Great, from that I gather method 1 is indeed not discouraged and maybe even preferred over 2, which is certainly good to hear, thanks. :-) Wrt to the StartCom bulletpoint, I guess this was a mistake on Mozilla's part then and should probably be acknowledged as such, @Gerv. > However, there is a criticism to be landed here - and that's using the same > name/keypair for multiple intermediates and revoking one/some of them. This > creates all sorts of compatibility problems in the ecosystem, and is thus > unwise practice. > > As an example of a compatibility problem it creates, note that RFC5280 > states how to verify a constructed path, but doesn't necessarily specify > how to discover that path (RFC 4158 covers many of the strategies that > might be used, but note, it's Informational). Some clients (such as macOS > and iOS, up to I believe 10.11) construct a path first, and then perform > revocation checking. If any certificate in the path is rejected, the leaf > is rejected - regardless of other paths existing. This is similar to the > behaviour of a number of OpenSSL and other (embedded) PKI stacks. > Similarly, applications which process their own revocation checks may only > be able to apply it to the constructed path (Chrome's CRLSets are somewhat > like this, particularly on macOS platforms). Add in caching of > intermediates (like mentioned in 4158), and it quickly becomes complicated. > > For this reason - if you have a same name/key pair, it should generally be > expected that revoking a single one of those is akin to revoking all > variations of that certificate (including the root!) Hmmm, I think I see the point you are making here, in general. Like, if both a revoked a non-revoked version of an intermediate are sent by a server, it might potentially break a client that does "naive" revocation checking like you described; path first, then check (e.g. openssl?). Worse, a client that has an intermediate cache _and_ does "naive" revocation checking might break long after the revoked one has been last sent (maybe the revoked one even came from a different server altogether). That would suck and the only server-side fix would be to switch to a cert signed by a new intermediate. Do you know a real-world client example for the latter though? Old Apple as you mentioned? Or was this just theoretical? Either way, in the specific case, StartCom, this criticism seems to be inapplicable, as the revoked one was never deployed in the first place. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Old roots to new roots best practice?
Forgot the links: [1] https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/hNOJJrN6WfE [2] https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/RJHPWUd93xE/RqnC3brRBQAJ [3] https://crt.sh/?spkisha256=fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2 [4] https://crt.sh/?spkisha256=82b5f84daf47a59c7ab521e4982aefa40a53406a3aec26039efa6b2e0e7244c1 [5] https://crt.sh/?spkisha256=706bb1017c855c59169bad5c1781cf597f12d2cad2f63d1a4aa37493800ffb80 [6] https://crt.sh/?spkisha256=f7cd08a27aa9df0918b4df5265580ccee590cc9b5ad677f134fc137a6d57d2e7 [7] https://crt.sh/?spkisha256=60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 [8] https://crt.sh/?spkisha256=d3b8136c20918725e848204735755a4fcce203d4c2eddcaa4013763b5a23d81f [9] https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Old roots to new roots best practice?
Quoting Gerv from the latest StartCom thread [1]: "* The key for their new root certificate was also used in a couple of intermediates (one revoked as it was done incorrectly - again, lack of testing!). While this is probably not a policy violation, it's not good practice." Everyone including StartCom itself acknowledges that the one "done incorrectly", the revoked one, shouldn't have happened. This thread is not about that. I want to understand the meaning and reasoning for the rest of the bullet point as it makes no sense to me. I asked this before in the StartCom/Certinomis thread [2], where Kathleen said the same as Gerv, but it got no response, so I'm trying again. I can think of 3 ways to support old and new roots in parallel: 1. In the other thread I mentioned that major CAs like Amazon [3], Comodo [4] and GlobalSign [5] also seem to use the key for a root cert in an "intermediate". This is used to create the following trust paths: modern client: new root (in store) --- issuing intermediate A0 --- leaf legacy client: old root (in store) --- new root! (same key/name, but different cert; "intermediate") --- issuing intermediate A0 --- leaf 2. The alternative solution seems to be to "reuse" the key of the issuing intermediate instead, as done by e.g. Entrust [6] or Let's Encrypt/IdenTrust [7]. Paths: modern: new root --- issuing intermediate A1 (eg signed by ISRG Root) --- leaf legacy: old root --- issuing intermediate A2 (same key/name as A1, different cert, eg signed by IdenTrust) --- leaf 3. Yet another solution would be to have no key/name sharing @ CA level, and instead sign a leaf with multiple keys during the issuing process to create multiple unrelated paths. That would result in having more than one leaf cert though, so it is not a viable solution in general. modern: new root --- issuing intermediate N --- leaf L1 legacy: old root --- issuing intermediate O --- leaf L2 (different cert, but possibly same key) Looks like StartCom chose 1. [8] instead of 2. This was explicitly permitted by Mozilla in [9]. So why are they now criticized for it? Am I missing something, did I get it wrong above? In general: Is 1. really "not good practice" to switch roots, do Mozilla or others prefer 2.?* * I sure hope not. Option 1 implicitly makes server admins provide either only the new path, or both old and new paths, never just the old one. Option 2 allows "only old" as well. Since trust stores keep old roots for compat, "only old" works when admins test it, so they can use that and forget "new". Hence you can't easily remove legacy roots from the trust store because compat; chicken/egg. (unless you get the right=new intermediates into the trust store/interm cache/validation path somehow; that's ugly but sometimes possible e.g. with NSS you can have neutral trust entries and iiuc AIA chasing could also do this?). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Expired Certificates Listed by Certificate Manager
On Tuesday, August 15, 2017 at 12:32:01 PM UTC, Gervase Markham wrote: > OneCRL does not obsolete certdata.txt-based distrust because not > everyone checks OneCRL. While we can't add every cert in OneCRL to > certdata.txt, we should add the big dis-trusts to it. Do you think > there's anything missing? I'm not following this CA stuff for that long, but one thing that comes to mind is the us gov pki. The symantec cross-sign has expired by now and the identrust one only has 5 months left, so going by current public info this will resolve itself soon. Still, for 2 years now a huge, intransparent, complex subtree is (probably) blocked for OneCRL clients, but trusted for non-OneCRL (+non-OCSP) users. Imho this is/was a little more high-profile than most other entries. Another situation: Old Wosign/StartCom roots are slated to be removed from certdata soon afaik. Finally, end of that story, right? But old WoSign has a revoked cross-signed by Certum until 2020. So Firefox and OCSP clients will get the expected result: No more old WoSign. "Just certdata"-consumers will still have it trusted and hardly anybody will know that this is happening or how. Candidate for addition? In general: When I read the messages on this list, I get the following impression: 1. GOOD: Revocation alone is "not really enough", mis-issuance is still bad and it reflects badly on a CA if there are too many issues or their handling is poor. 2. HOWEVER: In practice, once a cert is revoked and added to OneCRL, both the CA and Mozilla consider that particular issue resolved. A revoked cert or subtree is considered "not in scope" any more (and understandably so, there isn't much more that can be done on the technical level save removing the entire root for really bad cases). So to me it kinda felt like non-OneCRL is not taken into account by Mozilla any more. But since you said certdata distrust might still be used, a suggestion: The Mozilla workflow seems to be missing a step that checks whether a revoked subCA will 1. keep issuing certs (e.g. I just read up on the Disney CA that was revoked, then started issuing non-compliant certs) and 2. whether exisiting certs at the time of revocation had critical issues (e.g. failed validation). In both cases certdata addition should be at least considered. Otoh, additions stemming from e.g. the recent reports seem to be good candidates for OneCRL-only distrust. Same if a subCA just moved roots or stopped operating and that was the reason for revocation. Basically: Figure out/inquire why the revocation happened and classify as high or low risk. Maybe Mozilla's policy could be adjusted to require CAs to provide such an explanation on revocation? I'm aware that there is a "revocation reason" in OCSP already, but that is insufficient (e.g. "cessation of operation" for identrust federal bridge cross...). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom cross-signs disclosed by Certinomis
On Friday, August 4, 2017 at 12:27:13 AM UTC, Kathleen Wilson wrote: > Along this line of discussion, I have not felt comfortable with StartCom's > current root inclusion request (bug #1381406), because Hanno raised a concern > about the private key used by the new root is also used by two intermediate > certificates, one of them revoked. This doesn't see like good practice to me, > and I'm not sure that Inigo's response is sufficient. OK, maybe I'm just not getting it but what exactly *is* the issue that was brought up in that bug? I would think that this is, as the StartCom response seems to confirm, just the way you cross-sign new roots with existing ones? Old roots signing new roots is done by other CAs as well and I'm not aware of any talk or rule that this is discouraged or forbidden? My understanding is this (please correct me if I'm wrong): Hanno's crtsh link [0] just has a spkisha256 parameter. The list contains the root's self-sign and two instances where the root was signed by an old StartCom root. I get similar output with the spkisha256 of other trusted roots, i.e.: Amazon [1]: New roots signed with old Starfield Services Root that they bought Commodo [2]: Newer roots signed with their old AddTrust Root GlobalSign [3]: R3 root signed with their R1 root How, if not like this, can roots be cross-signed at all, technically? How are the above 3 examples different from the way StartCom did it? (If they aren't, I think it's important that the record is set straight and this specific thing doesn't appear in the real or mental list of things that new StartCom did wrong... If they are, disregard of course. :-D ). [0] https://crt.sh/?spkisha256=d3b8136c20918725e848204735755a4fcce203d4c2eddcaa4013763b5a23d81f [1] https://crt.sh/?spkisha256=fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2 [2] https://crt.sh/?spkisha256=82b5f84daf47a59c7ab521e4982aefa40a53406a3aec26039efa6b2e0e7244c1 [3] https://crt.sh/?spkisha256=706bb1017c855c59169bad5c1781cf597f12d2cad2f63d1a4aa37493800ffb80 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Expired Certificates Listed by Certificate Manager
On Wednesday, July 26, 2017 at 12:55:06 AM UTC, David E. Ross wrote: > Under the Servers tab for Certificate Manager, I see several root > certificates whose expiration dates have passed. I believe these were > all marked untrusted at one time. For example, I see six DigiNotar > certificates, CNNIC's MCSHOLDING TEST, Equifax's MD5 Collisions, among > others. Is it safe to delete these? IIRC, Mozilla just likes to keep expired distrust around because it cannot be overridden in the UI, whereas expired or unknown certs might be something a regular user might consider not that big of a deal and click through. In this context @Mozilla: Those additional distrust entries are coming from NSS, but they are all pre-OneCRL afaics. Is this coincidence (= there wasn't any "high-profile" enough distrust warranting nss addition) or has the certdata-based distrust been entirely obsoleted by OneCRL (= there will never be any new distrust entries in certdata)? I'm asking because some/most linux distros consume certdata, and they usually do have some blacklist capability where they put the certdata based distrust, but I don't know of any that parses OneCRL. I guess they all should, right? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Final Decision by Google on Symantec
WRT to the deadlines: If the decision is to sync up, I think it's worth noting that Firefox probably needs to release 2-3 weeks after a Chrome "release date" to achieve this in practice. Why? Firefox updates take ~10days from release date to reach previous version numbers. Chrome _can_ do it in the same time, but sometimes they slow update propagation considerably - and the distrust events could very well be reasons to do this. Take for example Chrome 57: Release date for desktop was March 9 [1], but propagation was throttled heavily for the first ~20 days, resulting in a total of ~30 days. [2] Chrome 57 for Android, supposedly released March 16 - always a week later than desktop! - was also held back for most? users for ~3-4 weeks iirc (can't find a graph right now, sorry). So unless Mozilla is eager to deal with most of the immediate outfall of the trust changes on its own (at which point we might as well set stricter deadlines), it should strategically fall behind. Dates in question: * Firefox 60 on 2018-05-01 for old PKI notBefore >=2016-06 -> already close, only 2 weeks after * Firefox 64 on 2018-11-27 for the full distrust -> 5 weeks after. Bonus: All the 1-year certs from the old PKI will have expired as well. [1] https://chromereleases.googleblog.com/2017/03/stable-channel-update-for-desktop.html [2] http://gs.statcounter.com/browser-version-market-share/desktop/worldwide/#daily-20170301-20170501 On Monday, July 31, 2017 at 2:01:57 PM UTC, Gervase Markham wrote: > On 29/07/17 23:45, Peter Bowen wrote: > > First, when the server authentication trust will bits be removed from > > the existing roots. This is of notable importance for non-Firefox > > users of NSS. Based on the Chrome email, it looks like they will > > remove trust bits in their git repo around August 23, 2018. When will > > NSS remove the trust bits? > > The NSS trust store represents Mozilla's decisions about what is > trustworthy. However, particularly if we match Chrome's dates, there is > a slightly unusual situation as we have taken a decision on > trustworthiness but, for other reasons, Firefox still trusts those certs > for a period. So one might well ask, should the decision be implemented > in NSS earlier than, or at the same time as, or even later than, Firefox > implements it? A good question. If you enjoy making things harder for other people you can go with earlier :-P . Seriously though, that would only make sense from a Mozilla release process perspective but is totally unexpected and annoying for any other NSS consumer - they will just have to postpone that NSS update or restore the roots temporarily. I think it makes most sense to land Firefox internal distrust shortly before branching, like Chrome, use beta for gauging impact, release, then ~2 weeks after release date do a NSS point release with only the certdata changes for other consumers and future Firefox versions. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: An alternate perspective on Symantec
Inspired by David's message, 2 suggestions for the Symantec plan: 1. Mozilla - and ideally Google as well - should clearly and explicitly communicate in the official statement on this that the "new" Symantec will still be strictly monitored even after the current remediation plan has been implemented. Their issue history still very much counts, potentially resulting in much harsher responses to future policy violations than would be the case for first-time offenders/other CAs. This is to counter the potential misconception (aka marketing) that everything is totally fine now. 2. Having Symantec inform their subscribers, as David mentions, is a great idea. Specifically, I think Symantec should be required to make their subscribers aware of the Mozilla-written! statement regarding the future of their CA, soon (<=1 month?) after its release. This is to prevent too many subscribers from getting caught by surprise in the future (see StartCom), to give them a chance to see more than one side, CA view _and_ Mozilla view, and to ensure they know they are Symantec subscribers in the first place (RapidSSL cert chaining to a GeoTrust root bought from some reseller = Symantec? yeah, totally obvious...). ___ 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
On Tuesday, June 6, 2017 at 2:03:29 PM UTC, Gervase Markham wrote: > > 1) Scope of Distrust > > Google proposal: existing CT-logged certificates issued after 1st June > 2016 would continue to be trusted until expiry. > Symantec proposal: all CT-logged certificates should continue to be > trusted until expiry. > Rationale for change: if transparency is enough to engender trust, that > principle should be applied consistently. This also significantly > reduces the revalidation burden. As mentioned in the other Symantec thread, right now Firefox doesn't do CT so notBefore >=2016-06 is the non-CT way of at least partially distrusting the old/unknown PKI soon-ish. I don't think it's a good idea to just broaden this to 2015-01 unless we know we can do CT by 2018-02. (Not sure if we'd be able to defend 2016-06 alone if Google agrees to do 2015-01 though) Then again, also in the other thread, you said "Mozilla would wish" the old PKI to be distrusted "sooner than November 2020" and you "expect it to be some time in 2018". Which I found to be a very bold proposition. Has Symantec commented on that yet? If not, can you make them? :-) In the event that we actually get 2018, allowing some older certs for a few more months might be worth conceding. A little less technically enforcable risk reduction from 2018-02 to 2018-?? in exchange for the "real deal" sooner than expected sounds good. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom issuing bogus certificates
For completeness, same for EV: https://crt.sh/?cn=ev&icaid=46855 Looks like some poor soul has been experimenting with test certificates for 3 weeks now, but has yet to succeed in issuing one that isn't violating the BRs... ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Plan for Symantec posted
On Monday, May 22, 2017 at 4:46:16 PM UTC, Gervase Markham wrote: > On 21/05/17 19:37, userwithuid wrote: > > With the new proposal, the "minimal disruption" solution for Firefox > > will require keeping the legacy stuff around for another 3.5-4 years > > and better solutions will now be a lot harder to sell without the > > leverage provided by Google. > > Why so? In eight months' time, if Chrome is no longer trusting certs > issued before 2016-06-01, why would it be a problem for Firefox to stop > trusting them shortly thereafter? A) It wouldn't. Specifically, for all certs under current Symantec roots, to sync with Google we can check: 1. If the chain contains a whitelisted intermediate (= "Managed CA"), don't impose further notBefore restrictions 2. For all other intermediates, only trust certs with notBefore between 2016-06-01 and 2017-08-08 This is a whole lot better than no restrictions and should definitely be done. (Also, Jakob explained this above as well, I'm just repeating it). My point was about the fringe parts of Symantec's current PKI. In 8 months, Chrome will _actually_ eliminate all of those using both CT-enforcement and notBefore => the "old" PKI is now WYSIWYG and quite fresh from their point of view. No more unknowns or waiting for Symantec to draw their map and discover SSP2 while forgetting SSP3. :-P For Firefox, this doesn't hold true. Not all certs under Symantec roots issued since 2016-06-01 are or need to be CT-enabled, so that date doesn't really align with better issuance practices for everything Mozilla actually trusts. At the end of the day it's gonna be fine of course: Most of the legacy will also be disabled in practice with the notBefore restrictions in Firefox. And anyway: What good is a cert if it isn't trusted by half of all web users? We can ride that Chrome market share wave. Still, Google's solution w.r.t. to the old PKI is just technically superior. B) Anyway, I don't want to derail the discussion and get back to what to do with the intermediate PKI ("Managed CA" under old roots) and new PKI (new roots, 2018?), that is also very important. One suggestion on that: Let's define the date on which we remove the old roots from NSS and disallow the use of any "Managed CA" via policy so that the intermediate PKI can't tranform into a de-facto long-term PKI. This is meant to force Symantec to focus their efforts on their own new roots. I don't think they should have that intermediate PKI as a comfy fallback when things with the new roots don't turn out that well or get delayed (they seem to have a tendency for delaying things...). One such date would be 2021-06-01, after the last 39 months cert issued by the Managed CA on 2018-02-28 expires. That allows the Managed CA to operate unrestricted (only BR-compliant) until 2019-02-28 at least, then enter a sunset period with shorter lifetimes. Lots of time to get the new roots fully operational. We could shave off up to 7 months on both dates (purge and sunset) if we don't allow the Managed CA to issue 39mo certs in the first place, only 27. Mozilla's first proposal was 13 months for new certs, so 27 - which will become mandatory soon anyway - sounds quite reasonable to me. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Plan for Symantec posted
On Sunday, May 21, 2017 at 11:31:54 PM UTC, Michael Casadevall wrote: > There's also a fair number of points dealing with who can sign and for > what while Symantec spins up the new roots (which the Google proposal > says a trusted third party CA signed by Symantec"). > > I'm against this point specifically because third-party CA operations is > how we got into this mess. I agree with your general concern, but the OP states: "These sub-CAs must be operated by a non-affiliated organization that operates roots currently trusted in the Android and Chrome OS trust stores that have been trusted for a period of at least two years." This to me sounds very similar in theory to Certum/Asseco doing OV for WoSign, which on this list has been considered OK. Personally, I'd rather not have any of this CA mixing, 3rd-party delegating, cross-signing of whole trees, root-buying etc. but all this stuff seems to be an integral part of current industry practice.+ I say in theory because Symantec's "good arguments" (aka monies) have the potential to make the selected CA their bi...dding doer by means of contract in reality. What else is new though? I'm positive Symantec would have always found some business arrangement with another CA for their customers that want > 9 months cert lifetime and/or EV under Google's first proposal, so we would have gotten some "Managed CA" one way or the other. Worst case it would have been mixed in with other certs, not having a dedicated subCA or other marker. Now it's explicit, separate and even has some additional rules. NSS* already trusts that other CA to do proper validation right now, and they might just be smart enough to realize that they will be watched way more closely when Symantec starts using them to not do anything totally stupid. I honestly think that this "Managed CA" will get more practical oversight both by auditors and by the community than most of the roots in NSS. + Appreciation footnote for the DTP discussion @ cabf and the GlobalSign->Google root transfer discussion on here * Android trust store seems to be a subset of NSS' ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Plan for Symantec posted
To me, the most noticable difference between how Google and Mozilla can take action is with regards to exisiting certs. As proposed, Google has a really neat timeline to get rid of Symantec's questionable legacy stuff quickly and effectively. (Legacy stuff which we - and arguably Symantec themselves judging from their responses on here so far - still don't have a complete picture of). Come 2018-01-18 (8 months from now), Google could comfortably say it _actually_ only trusts (relatively) new Symantec certs - thanks to the 2016-06 CT requirement. No more undisclosed old subCAs that are technically capable of issuing trusted certs, no more reliance on notBefore which could technically be faked; if they choose to do so, Google can enable unconditional technical enforcement of CT for all things Symantec and everyone who is interested can use the logs to get a complete picture of what will actually be trusted in Chrome 65. Mozilla doesn't have this (yet). Google's first proposal would have been great because if all certs have to be reissued within a year anyway to be trusted by Chrome (~ half of the browser market), Mozilla could have at least implemented a simple notBefore check to latch on to that legacy purge. With the new proposal, the "minimal disruption" solution for Firefox will require keeping the legacy stuff around for another 3.5-4 years and better solutions will now be a lot harder to sell without the leverage provided by Google. Quite unfortunate development. This has the potential to end up mirroring the WoSign response, where Mozilla and Apple sanction new certs via notBefore and then... wait - worst case up to 3.5 years - while Google acts and effectively gets rid of the legacy in < 1 year using technical restrictions.* Now I can't think of any fix other than "copy Chrome -> enforce CT" or "prematurely distrust older certs anyway -> make everyone hate or ditch Mozilla", maybe someone else knows a way. As it stands, I suspect that in all likelihood Chromium will again have the better code solution over Firefox, which is kinda meh, but whatever. :-) * FTR: Google fucked up majorly by not communicating their plan and deadlines for WoSign clearly. Critical info on future distrust steps was only vaguely hinted at in the single proper announcement made on this. Still, it's awesome to see the agreed upon policy change (= distrust current WoSign, have them start fresh with new roots) implemented within a reasonable timeframe. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Problem Reporting Mechanisms
On Wednesday, May 17, 2017 at 11:24:54 AM UTC, Gervase Markham wrote: > Well, such contacts are normally per CA rather than per root. I guess we > could add it on the CA's entry. Tbh, I'm not really familiar with your salesforce setup, I was just using this as a stand-in for "place where CA can be made to keep it current". :-) > Well, I want to make sure that people who want to report e.g. a bad cert > found in the wild know where to go. This was triggered by an event where > Microsoft wanted to report something to GoDaddy (IIRC) but using the > wrong contact. So the intent was really: How can an external entity (= not the certificate owner or authorized party) report a security issue, abuse scenario or policy violation with regards to certificates you issued? Specifically, what contact email address or webpage can be used to ensure a timely and competent response? (plainly: how to reach "tech" or "compliance", not sales/marketing/customer-support/general/...) > > IMHO, a wiki page with manually copied info has a good chance to get > > stale as CAs change their documents, websites, primary domains, etc. > > It's true, but the other option is "dig in my CP/CPS". But there could be more "other options": dig yourself << community collected and maintained info < CA verified community info < info CAs are "forced" to maintain, policed by community So I guess my second choice - after getting CAs to unbundle this specific info from their pdfs and maintain it via the CCADB (or wherever else it makes sense) - would be to go ahead with the manually created wiki page and make them confirm it regularily via CA communications. Then there is still a degree of accountability for the correctness. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Problem Reporting Mechanisms
After skimming the responses and checking a few CAs, I'm starting to wonder: Wouldn't it be easier to just add another mandatory field to the CCADB (e.g. "revocation contact"), requiring $URL or $EMAIL via policy and just use that to provide a public list? It seems to me that most revocation related procedures are very specific to CA-customers (e.g. log in and use the revoke button) and often not even TLS related (e.g. send a document signed with key you want to revoke, use the revocation password you got when creating the email cert, ...). I think it's not your intention for the wiki page to capture that, or is it? >From what I can see, for non-customers the "instructions" - if there are any - >really seem to amount to: A) Send email with cert info + reason you suspect >misuse, we'll check or B) use web form to do the same. IMHO, a wiki page with manually copied info has a good chance to get stale as CAs change their documents, websites, primary domains, etc. (That being said, trying to use CPS urls from the CCADB [0] I got some 404s and some 30* lead nowhere as well. Also some CAs link an outdated version when the website has a WAY more recent one, though that might be because of the English vs native lang situation. Point is, CCADB entries might also be outdated, but at least that will be a policy violation now, right?). [0] https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Find a 5-year certificate
> https://bugzilla.mozilla.org/show_bug.cgi?id=908125 . > > Gerv Wow, embarrassingly weak google-fu on my part... Sorry and thanks! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Find a 5-year certificate
In this context, I was wondering: Has there been a discussion yet on Firefox enforcing cert lifetime in code not just via policy? Most everything seems to be in place already due to EV, but DV doesn't have a limit atm. [0] Now in practice, thanks to killing sha1, most of those legacy certs are probably distrusted anyway. But then again, backdating is technically possible, until full CT can provide protection in ~4 years iiuc, and it's a pretty stealthy way for CAs to subvert current guidelines (unless you do it WoSign-style I guess...) Limiting to 60 months could be done right now as a sanity check and shouldn't cause any problems, right? [0] https://github.com/mozilla/gecko-dev/blob/455ab646d315d265b4c0c3f712a69aae40985fcf/security/certverifier/NSSCertDBTrustDomain.cpp#L1112 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy