On Thu, 27 Dec 2018 16:56:39 -0800 Peter Bowen via dev-security-policy <[email protected]> wrote:
> - The character Asterisk (U+002A, '*') is not allowed in dNSName SANs > per the same rule forbidding Low Line (U+005F, '_'). RFC 5280 does > say: "Finally, the semantics of subject alternative names that > include wildcard characters (e.g., as a placeholder for a set of > names) are not addressed by this specification. Applications with > specific requirements MAY use such names, but they must define the > semantics." However it never defines what "wildcard characters" are > acceptable. As Wikipedia helpfully documents, there are many > different characters that can be wildcards: > https://en.wikipedia.org/wiki/Wildcard_character. The very same > ballot that attempted to clarify the status of the Low Line character > tried to clarify wildcards, but it failed. The current BRs state > "Wildcard FQDNs are permitted." in the section about subjectAltName, > but the term "Wildcard FQDN" is never defined. Given the poor > drafting, I might be able to argue that Low Line should be considered > a wildcard character that is designed to match a single character, > similar to Full Stop (U+002E, '.') in regular expressions. Are you, in fact, now arguing this? If you, in fact, ever believed this, do you not think it has very significant implications that should have been raised previously? e.g. If these are wildcards, putting one in an EV cert would be a serious problem. Did you go back and check there were problem reports for any cases where EV certs have these imaginary underscore wildcards? Let's be real: There was never any such idea, the underscores are not "wildcards" they're present because some CAs took a lackadaisical approach to name validation that suited their customers better. > - The meaning of the extendedKeyUsage extension in a CA certificate is > unclear. There are at least two views: 1) It constrains the use of > the public key in the certificate and 2) It constrains the use of > end-entity public keys certified by the CA named in the CA > certificate. This has been discussed multiple times on the IETF PKIX > mailing list and no consensus has been reached. Similarly, the X.509 > standard does not clarify. Mozilla takes the second option, but it > is entirely possible that a clarification could show up in a future > RFC or X.500-series doc that goes with the first option. In the absence of a consensus from the relevant IETF Working Groups I don't see why you'd expect a future RFC. Certainly there shouldn't be any mechanism to get a Standards Track RFC without consensus. We can't do anything about ISO, if they go completely off the rails I guess we'd have to decide what to do about that when it happens, it doesn't feel tempting to try to get ahead of that particular calamity. > Of course people are going to try to do better, but part of that is > understanding that people are not perfect and that even automation can > break. I wrote certlint/cablint with hundreds of tests and continue > to get reports of gaps in the tests. Yes, things will get better, > but we need to get them there in an orderly way. This feels pretty orderly to me? We're a pretty long way from, say, the end of Vernor Vinge's novel "Rainbows End", where government spooks issue blanket revocations for all certificates under a major root CA. (It's fun to imagine how disappointingly little effect this would have in our real world) Nick. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
