On Thu, Dec 27, 2018 at 9:04 AM Nick Lamb via dev-security-policy < [email protected]> wrote:
> On Thu, 27 Dec 2018 15:30:01 +0100 > Jakob Bohm via dev-security-policy > <[email protected]> wrote: > > > The problem here is that the prohibition lies in a complex legal > > reading of multiple documents, similar to a situation where a court > > rules that a set of laws has an (unexpected to many) legal > > consequence. > > I completely disagree. This prohibition was an obvious fact, well known > to (I had assumed prior to this present fever) everyone who cared about > the Internet's underlying infrastructure. > > The only species of technical people I ever ran into previously who > professed "ignorance" of the rule were the sort who see documents like > RFCs as descriptive rather than prescriptive and so their position > would be (as it seems yours is) "Whatever I can do is allowed". Hardly > a useful rule for the Web PKI. > As I wrote in the thread on underscores, I am one of the people who believed it was not clear if underscores were allowed or not. This was reflected in the earliest versions of certlint/cablint. If you think it should have been clear, consider the following examples from the real world: - 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. - 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. These are just two cases where the widely deployed and widely accepted status does not match the RFC. > > It would benefit the honesty of this discussion if the side that won > > in the CAB/F stops pretending that everybody else "should have known" > > that their victory was the only legally possible outcome and should > > never have acted otherwise. > > I would suggest it would more benefit the honesty of the discussion if > those who somehow convinced themselves of falsehood would accept this > was a serious flaw and resolve to do better in future, rather than > suppose that it was unavoidable and so we have to expect they'll keep > doing it. > 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. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
