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
