In https://bugzilla.mozilla.org/show_bug.cgi?id=1593814 , Rob Stradling, Jeremy Rowley, and I started discussing possible steps that might be taken to prevent misencoding strings in certificates, and it seemed appropriate to shift this to a more general m.d.s.p. discussion, rather than solely on the bug. Hopefully folks know I'm all in favor of discussing systemic remediations on list, and would love to see more of that, as they hopefully get wider attention.
The context is DirectoryString, which is a string type that supports many different encodings, as it's a CHOICE. Such fields are generally left up to a CA's discretion - after all, CHOICE exists to, well, give a choice. DirectoryString comes to us from X.500 and related; a carryover from the Directory Access Protocol and it's more well-loved sibling, the Lightweight Directory Access Protocol. When RFC 2459 was specified, it tried to get all CAs to converge on a single type, to reduce variance, confusion, and complexity. It introduced a normative MUST that, if issued after 2003-12-31, CAs MUST use UTF8String, and until then, should try to minimize variance using a set of rules. RFC 3280, published 2002, continued that sunset. However, when RFC 5280 was published in 2008, it removed that sunset, and basically left the compatibility language in from previous versions. The reasons should be obvious: RFCs are signs, not cops, and unless/until someone enforces compliance with RFCs, then it's really up to implementors. On the related bug, one of the suggestions was to reduce the risk of PrintableString misencoding, CAs can and should align on using UTF8String for encoding DirectoryString types. UTF8String, while requiring valid UTF-8 code points, is significantly more flexible in what it can represent. Rob Stradling helpfully, and rightfully, pointed out that CAs would still need to maintain code to correctly encode PrintableStrings. That's because several attributes in the Subject - such as countryName and serialNumber - still use PrintableString. However, I think Rob's point emphasizes the risks, and the mitigations. In my view, the big risk is that CAs are encouraged to adopt the customer's preferred spelling or localization for entities like organization, organizationalUnit, or locality - fields which are DirectoryStrings - and thus prone to misencoding, especially if the CA lifts the encoded values from CSRs. Because the BRs and EVGs don't prohibit adopting the customer's preferred values, so long as they're validated appropriate (e.g. in a QGIS or QIIS) as valid forms, this remains a risk. Related to the issue from DigiCert, I (and colleagues at other root programs) have seen issues in how CAs encode their certificate issuer names and subject names. For example, we've seen CAs use one string form in the Subject, and a different string form in Issuer, despite the language in RFC 184.108.40.206 regarding the same encoding. Without wanting to go into a full discussion there about the encoding, I raise it as another issue where aligning on a common choice for DirectoryString substantially reduces the risk of issues. I'm curious to hear from more CAs, and I suspect Rob will have more excellent points to the contrary, but thought it best to consider discussion on-list rather than on-bug :) Put differently: Are there reasons to continue to use PrintableString for newly issued certificates, and CAs? There are risks to continuing to allow flexibility, and complexities in getting that flexibility right, so reducing that complexity is one of the ways we can significantly reduce risk. _______________________________________________ dev-security-policy mailing list email@example.com https://lists.mozilla.org/listinfo/dev-security-policy