On Thu, Aug 31, 2017 at 4:13 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> I am aware that this was the original specification. However like many > other parts of PKIX it may not be as good in 20/20 hindsight. Agreed. But in general, in order to maintain interoperability, there's a process for building consensus, and repurposing extensions as you propose is generally detrimental to that :) > Moving the information to a new extension would basically just bloat > certificates with more redundant data to be sent in every certificate > based protocol exchange. But changing the original decision in a > backwards compatible manner may still be a good idea, either as a > "stricter security policy" or (better, if it works well in controlled > tests) as part of an update RFC for the IETF standard that specified the > original semantics. I can understand your perspective, but I must disagree with you that it's "backwards compatible". It isn't - it's a meaningful semantic change that breaks interoperability. At the least, that's something that bears documentation and consensus - that is, don't "embrace, extend, extinguish" - if you will. Yes, it means that technically constrained sub-CA certificates may be 'bloated' in order to ensure the desired degree of security. That's a trade-off for the compromises necessary to avoid audits. That's not, however, an intrinsic argument against the process, or a suggestion it cannot be deployed. > The interaction between a nameConstraints extension not specifying > directorynames and the directoryname in the Subject field would be an area > needing careful specification, based on compatibility and historic concerns. > Yes. Which would not be appropriate for m.d.s.p (for reasons of both consensus and intellectual property). That is a concern for some members, and is why organizations like W3C and groups such as WICG exist :) > A first order approximation would be that the absence of directory name > constraints in a non-empty nameconstraints extension would not prohibit the > (mandatory) inclusion of a directory name as the Subject Name of a > certificate (but would still block its inclusion as a SAN). > It does, as proposed, so your proposal is not 'backwards compatible' anymore :) > A second order approximation could apply certain non-directory-name > constraint semantics to certain directory name elements. For example > an "emailAddress" directory name field could be subject to the > constraints for rfc822name absent explicitly contradictory directory > name constraints. An official specification would have to enumerate > these situations explicitly. Indeed. > However in practice, such a replacement of (relying part redistributed) > SubCA certificates would be at least as difficult as simply switching to > a new SubCA. Either solution would be unlikely to make subscribers stop > distributing the old SubCA cert with their existing non-expired end > cert, but changing to a new SubCA would at least prevent accidental > reuse of the expired/revoked SubCA cert with new end certs. They are not relying party distributed. They're subscriber distributed. And as the Subscriber has a direct or transitive relationship with the Issuer, that's not unreasonable. I agree that it's an error prone process, and I agree that changing the name (and not just the key) is an ideal scenario to transition. However, unless you revoke the old certificate, it's unconstrained. And if you revoke the old certificate, then everything it's issued is no longer valid, unless you reissue for the same name and key with new constraints. Which is why folks thought it was a good idea at the time. I'm not trying to defend the ideas as good - the idea of making nameConstraints a whitelist, rather than a blacklist, has been something bandied about for the better part of a decade. However, it's a mistake we have to live with, and if we want to correct it, it means specifying something new, and in a way that is interoperable, both with the old and others. I tried to give you a suggestion on how to do so, should you feel motivated to pursue it. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
