PrintableString, UTF8String, and RFC 5280
Ryan Sleevi
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
4.1.2.6 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.
Peter Gutmann
>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
Is there any official position on strings that have completely invalid
encodings like embedded NULL characters in them (presumably in memoriam of the
Kaminsky/Marlinspike certificate-spoofing bug) as one of Microsoft's CA
certificates among numerous others do?
Peter.
Ryan Sleevi
wrote:
bringing it up? Do you believe it’s still applicable in the Web PKI of the
past decade?
I ask, because this is already addressed rather extensively, and has been
for some time, within linters, and since at least 2012 with respect to the
Baseline Requirements, through the incorporation of RFC 5280, and thus
transitively the incorporation of DNS preferred name syntax.
I’m not sure which of Microsoft’s CAs you’re referring to, so you’d have to
be more precise. Do you mean the publicly trusted certificates? Or
something only trusted on Windows? If you could link to the crt.sh entry,
that might be easier.
It could be that you’re referencing the use of BMPString, which systems
like Active Directory Certificate Services used. Those, being 16-bit code
points, certainly “seemed” like they had embedded NULs, but only if
misinterpreted as 8-bit.
>
Peter Gutmann
>Do you believe it’s still applicable in the Web PKI of the past decade?
Yes, the specific cert I referenced is current valid and passed WebTrust and
EV audits.
>If you could link to the crt.sh entry, that might be easier.
Here's the Microsoft one I mentioned:
Microsoft RSA Root Certificate Authority 2017
https://crt.sh/?id=988218851&opt=x509lint,zlint,cablint
There are numerous others. This particular one isn't just a CA cert, it's a
root cert.
>It could be that you’re referencing the use of BMPString
I'm just quoting X509lint:
ERROR: URL contains a null character
Given that this was exposed as a major security hole ten years ago, I was
surprised when someone notified me that these things exist, and that no-one
seems to have done anything about it.
Peter.
Ryan Sleevi
wrote:
> Ryan Sleevi <ry...@sleevi.com> writes:
>
> >Do you believe it’s still applicable in the Web PKI of the past decade?
>
> Yes, the specific cert I referenced is current valid and passed WebTrust
> and
> EV audits.
>
audits in general) provide, or more aptly, misleading as to how they work :)
But I agree, this is concerning.
> >If you could link to the crt.sh entry, that might be easier.
>
> Here's the Microsoft one I mentioned:
>
> Microsoft RSA Root Certificate Authority 2017
>
> https://crt.sh/?id=988218851&opt=x509lint,zlint,cablint
> There are numerous others. This particular one isn't just a CA cert, it's
> a
> root cert.
>
> >It could be that you’re referencing the use of BMPString
>
> I'm just quoting X509lint:
>
> ERROR: URL contains a null character
>
> Given that this was exposed as a major security hole ten years ago, I was
> surprised when someone notified me that these things exist, and that no-one
> seems to have done anything about it.
>
incidents at https://wiki.mozilla.org/CA/Incident_Dashboard that we take
incidents seriously as they're brought to attention, and have spent
considerable effort in making sure that anyone finding anything odd has a
clear path to reporting and a clear path to trying to resolve these issues
systematically. You can also see linters appropriately warning about this -
and the expectation for CAs to be monitoring such certificates for errors.
As to the incident, I'm showing this root only trusted by Microsoft at
present - https://crt.sh/?caid=108560
<https://crt.sh/?caid=108560&opt=x509lint,zlint,cablint> .
https://bugzilla.mozilla.org/show_bug.cgi?id=1582254 has not yet included
them in the Mozilla store, so you should feel free to add comments there.
I don't think there's anything to conclude "nothing is being done about
it", but you can also see, from the original message and the discussion on
the bug, that no, we did not talk about this topic. It's probably better to
start a new thread if you'd like to talk about it further.
Peter Gutmann
>I don't think the hyperbole helps here.
It wasn't hyperbole, it was extreme surprise. When someone told me about this
I couldn't believe it was still happening after the massive amount of
publicity it got at the time, so it was more a giant "WTF?!??" than anything
else.
Other CA certs with this issue include further audited and (in some cases) EV-
approved certs, all from Microsoft:
https://crt.sh/?id=988218851&opt=x509lint,zlint,cablint
https://crt.sh/?id=988140328&opt=zlint,x509lint,cablint
https://crt.sh/?id=988215004&opt=zlint,cablint,x509lint
https://crt.sh/?id=988137612&opt=x509lint,cablint
https://crt.sh/?id=1197076917&opt=x509lint,cablint
https://crt.sh/?id=1197067049&opt=x509lint,cablint
https://crt.sh/?id=1197079848&opt=x509lint,cablint
https://crt.sh/?id=1197075787&opt=x509lint,cablint
https://crt.sh/?id=554380367&opt=x509lint
https://crt.sh/?id=918173942&opt=x509lint,cablint
I don't know who trust what where, but Chrome at least seems to trust these
two:
https://crt.sh/?id=554380367&opt=x509lint
https://crt.sh/?id=918173942&opt=x509lint,cablint
>It's probably better to start a new thread if you'd like to talk about it further.
Sure, it just came to mind when I saw this thread, which is why I posted it
here.
Peter.