On Thu, Aug 31, 2017 at 8:18 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Would it be beneficial to Mozilla in particular and the larger PKI > community in general if the following was added to implementations: > Hi Jakob, This was rather extensively discussed in the IETF during the production of the nameConstraints extension - whether to fail open or fail closed, if you will, with unrecognzied name types. The existing RFCs document the behaviour that is implemented by clients, so no, it would not be wise to repurpose this behaviour in a contradictory way - that would go against the mission of ensuring an interoperable Web based on shared standards. The approach to change the semantic meaning of extensions in such a way is to define a new such extension - which may have the same encoding, but have the semantic processing restrictions you mentioned. One way that could be done in an interoperable way is to ensure both the 'legacy' nameConstraints extension (to handle the existing Web PKI) and the 'new' nameConstraintsVersion2 extension (poorly named, but with the same ASN.1 production and different semantic meaning for processing) be required for a certificate to be considered 'constrained'. Such a document would ideally go through the IETF, but COULD be incubated in an appropriate venue (such as WICG) to allow iterative and flexible development. However, the implementation isn't quite as 'simple' as you describe, and so would require more work. For example, one flaw would be that unless such a constrained certificate specified a Directory Name constraint, then every certificate issued would be a violation of the name constraint unless it was a fully empty subject ( see https://no-subject.badssl.com/ to understand the compatibility issues this causes; particularly, try it on macOS). So more work is needed. But that general concern - of being able to extend new name types and not necessarily have the CA be able to issue for them - has been discussed in the past. The original idea was that as new name types are introduced that have semantic meaning for applications, you would revoke the existing cert and reissue a new one (with new constraints) using the same Subject/Key, as that would ensure a continuity of validity for situations where you did want to restrict the naming scheme. So, technically, there are options for CAs today :) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
