In , 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 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
dev-security-policy mailing list

Reply via email to