Re: Old roots to new roots best practice?
Hi there, 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) 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!) Note that all of this presumes the use of two organizations here, and cross-signing. If there is a single organization present, or if the 'intermediate' *isn't* intended to be a root, it's generally seen as an unnecessary risk (for the reasons above). Does that help explain? On Sun, Sep 17, 2017 at 11:37 AM, userwithuid via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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=fbe3018031f9586bcbf41727e417b7 > d1c45c2f47f93be372a17b96b50757d5a2 > [4] https://crt.sh/?spkisha256=82b5f84daf47a59c7ab521e4982aef > a40a53406a3aec26039efa6b2e0e7244c1 > [5] https://crt.sh/?spkisha256=706bb1017c855c59169bad5c1781cf > 597f12d2cad2f63d1a4aa37493800ffb80 > [6] https://crt.sh/?spkisha256=f7cd08a27aa9df0918b4df5265580c > cee590cc9b5ad677f134fc137a6d57d2e7 > [7] https://crt.sh/?spkisha256=60b87575447dcba2a36b7d11ac09fb > 24a9db406fee12d2cc90180517616e8a18 > [8] https://crt.sh/?spkisha256=d3b8136c20918725e848204735755a > 4fcce203d4c2eddcaa4013763b5a23d81f > [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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: StartCom inclusion request: next steps
I didn't understand the original below comment by StartCom very well about the cross-sign, but after Ryan's message I understand it better in retrospect: > On Thu, Sep 14, 2017 at 11:05 AM, Inigo Barreira via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I´ve never said this. In fact, despite having that cross-signed which were provided to us in july we have never used and provided to any of our customers to build a trusted path. So none of those 5, or the new ones, go with the Certinomis path because none have it. But all those 5 certs are untrusted because we´re not in the Mozilla root, not the new one, and the old one was distrusted. > > In fact, recently, I asked for permission to use the Certinomis cross-signed certificates and have no response. I don´t know if this is an administrative silence which may allow me to use it but until having a clear direction we haven´t used it. So this appears to be saying that "all those 5 certs are untrusted" because StartCom didn't provide the full chain to customers, even though such a chain could be constructed. The cross-signature wasn't published in CT until August 2nd, but that's not any sort of guarantee that the cross-signature wasn't discoverable by other means -- its availability until August 2nd is a function of actions by Certinomis that are not disclosed. The August 2nd date is also after StartCom's actions were being publicly questioned, so it suggests the possibility that the cross-signature would have been kept secret for longer, and was only submitted to CT once scrutiny had increased. Whether the cross-cert was issued before the audit report date is also a mystery, especially if it's possible that either Certinomis or StartCom was operating under the assumption that the cross-signature is irrelevant until "delivered" to customers. StartCom has remarked several times in this thread that they are being treated unfairly, but I can think of at least one comparison to a previous distrust event, which is that one of the more significant (in my opinion) issues with Symantec's now-deprecated PKI is that there existed chains that brought U.S. Federal PKI certificates into being trusted by Mozilla. Those chains were, as far as I know, never delivered proactively to customers, but could easily be constructed by any interested party with sufficient knowledge of the universe of cross-signatures. For example, Qualys' SSL Labs reports would automatically construct those chains for sites using FPKI certs, and let users download the full chain in one click. The threat model here is not what ordinary inexpert customers do, but what opportunities an adversary has available to them among the universe of trusted CAs to obtain certificates. In the Symantec/FPKI case, the problem was that an adversary could easily use an FPKI certificate to intercept connections made by Mozilla products, whether or not Symantec or the FPKI ever advertised or proactively enabled this use case. What made this such a big issue, in addition to the scope of the technical impact, is that the issue was not noticed or elevated for years, during which multiple "generations" of cross-signs had been issued and expired. It brought Symantec's ability to understand their own PKI into serious question. So I think the biggest issue here is not so much the technical impact, but that StartCom was communicating inaccurate information to Mozilla. The certs were publicly trusted by Certinomis, whether the cross-signature was delivered to StartCom or to customers or to no one. While presumably this inaccuracy was unintentional, it was enough to cause Gerv to express public confusion and doubt about whether the certificates were part of the cross-signed hierarchy. It also reflects a potentially dangerous difference of perspective between StartCom and root stores in how StartCom evaluates the trust and impact of the certificates they issue. For a CA that has been operating for as long as StartCom has, I think it's fair to describe this as concerning. I also think that Certinomis, whose cross-signing practices are now being scrutinized, should proactively post to this list with a timeline of its own actions during this process, so that their actions can be understood in the context of StartCom's. -- Eric ___ 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
