> I realize this is almost entirely critical, and I hope it's taken as > critical of the proposal, not of the investment or interest in this space.
Not a problem for being critical and we don’t take it personally. We appreciate the discussion, the time you spend and the opportunity to propose different approaches to solving this issue. Our goal is not to defend non-compliant or insecure practices. Quite the opposite, with our research we hope to find a solution that leads in certain constellations to a quicker resolution while rewarding projects that follow the standards. We don’t want to promote our proposal as a better proposal for all possible constellations, but we believe it can in certain situations be as secure and more practical as the original proposal on this mailing list. We have carefully read your email, and believe we’ve identified the following important points: 1. Potential feasibility issue due to lack of path building support 2. Non-robust CRL implementations may lead to security issues 3. Avoiding financial strain is incompatible with user security. If we have missed one or misunderstood you, please let us know. We’d like to address these points below. #1 Potential feasibility issue due to lack of path building support If a relying party does not implement proper path building, the EE certificate may not be validated up to the root certificate. It is true that the new solution adds some complexity to the certificate hierarchy. More specifically it would turn a linear hierarchy into a non-linear one. However, we consider that complexity as still being manageable, especially since there are usually few levels in the hierarchy in practice. If a CA hierarchy has utilized the Authority Information Access extension the chance that any PKI library can build the path seems to be very high. Even if the path could not be built, this would lead to a fail-secure situation where the EE certificate is considered invalid and it would not raise a security issue. That would be different if the EE certificate would erroneously be considered valid. Additionally, only the concerned EE certificates are affected. There is no impact on all the other actors in the ecosystem. Since lack of proper path building is neither a security issue, nor a compliance issue, and only the concerned subscribers are affected, it would be up to the subscriber to decide whether to take the risk that his certificates are wrongly labeled as invalid by certain relying parties. In the blog post at medium.com you mentioned in your last answer, you have analyzed various PKI libraries for their path building capacity. If this community believes it would clarify the situation, we could run tests with some of those libraries to see, how they are able to build the path when our proposal was applied to a simple 4-level PKI hierarchy. #2 Non-robust CRL implementations may lead to security issues Relying parties using applications that don’t do a proper revocation check do have a security risk. This security risk is not introduced by our proposal but inherent to not implementing core functionality of public key infrastructures. The new solution rewards relying parties that properly follow the standards. Indeed, a relying party that has a robust CRL (or OCSP check) implementation already would not have to bear any additional security risk. They also would benefit from the point that our solution can be implemented very quickly and so they would quickly mitigate the security issue. On the other hand, relying parties with a non-functional revocation mechanism will have to take corrective measures. And we can consider it a fair balancing of work and risk when the workload and risk is on the actors with poor current implementations. It can be noted that the new solution gives some responsibility to the relying parties. Whereas the original solution gives responsibility to the subscribers who did nothing wrong about this in the first place. The new solution can be considered fairer with this regard. #3 Avoiding financial strain is incompatible with user security User security is fundamental for the PKI ecosystem. Our proposal increases the risk exposure level only for those relying parties with a fundamentally insecure application. Taking into account economic constraints in real life, we believe that the increase in security should be balanced in terms of cost and effort. Such a tradeoff may provide sufficient levels of security while maintaining affordability. This also leads to a quicker time to implement which limits the exposure and increases security. One last thing we wanted to get your feedback on, is whether you agree that the new solution we proposed ensures that if SICA and ICA are considered revoked, there is no security risk for SICA2. Thank you for your time and continued discussion. Nils and team _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
