[SSL Observatory] certificates for .local names [was: Re: DFN and subordinate CA domain-scoped whitelists]

[Ralph Holz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://lists.eff.org/pipermail/observatory/attachments/20111110/0549bbbf/attachment.sig>