Hi, > This is backed up by a claim about the policies of the parent CAs and > their technical control over the secret key material for subordinate > CAs, not on any externally-explicit statements of scope like name > constraints. > > In response to that, i did a bit of digging that turned up: > > 2) some CAs were able to violate these constraints as recently as 19 > months ago, to create certificates with a validity of at least 5 years. > At least some of these certificates are still in use on the web today, > not revoked.
I am not sure if .local is a good example here. From reading mozilla.dev.security.policy, I think constraints on .local etc. have been added to the Problematic Practices after those certificates had been issued. I think it was sometime during the last 2 years. Thus, I am not not convinced yet that DFN's practices have ever been violated or been in gross violation of, say, Mozilla's requirements. Anyway, I think this is slowly taking it too far. This is just one issue in a whole sea of them. My take on it is that it would have been scientifically correct to expand on the issue of "tightly controlled authorities that can only forward certification requests" because it's not wrong to define "CA" as "in control of the keying material", and DFN's sub-CAs are not in control of that. At the same time it is also true that in X.509 parlance those certificates do indicate CAs, and even if their keying material is with DFN, this does constitute further attack vectors. On the whole, being explicit here would acknowledge the different facets of the attack surface, which is different here than for some loosely controlled sub-CAs (as for example those that enterprises run and that are certified by a root CA). I am much more afraid of the latter, and they exist and many commercial CAs refuse to disclose them. Conclusion: as a reviewer of the paper, I would have written that in the "comments to the author" section and asked the authors to be more cautious in their claim plus clarify the issue. At the same time, however, it would not have led me to assign lesser value to the work as a whole or doubt the remaining results. I certainly would not have doubted their integrity. Ralph
signature.asc
Description: OpenPGP digital signature
