On 10/24/2008 05:34 PM, Frank Hecker:
Eddy Nigg wrote:
I'd like to pick this discussion up once again and evaluate what the
goals of Mozilla and the Mozilla CA policy really are. Certainly the
above is not the defined goal, but rather provide some reasonable
assurance about the CAs included in NSS and Mozilla products and allow
users to rely on
- domain name control validation for web sites
- email control validation for email
- identity or organization validation for code signing
- in case of EV, compliance to the EV guidelines
- sound physical and logical security, controls, business continuity
and other aspects as they are covered by the acceptable audit criterion
Unlike Ian, I'm not going to try to parse what "rely on" means. Leaving
that issue aside, I think the above is a reasonable summary of what the
Mozilla CA policy says. However as Ian notes, the above are not really
goals or ends in themselves, they're means to an end, namely to minimize
security risks to typical Mozilla users, trading off risks vs. benefits
in an approach consistent with that taken with other security-relevant
parts of the product.
Of course! But lets see this in the right context of CAs, their current
requirements and obligations. We should also find the right context in
relation to the investments made in cryptographic libraries, most
notably NSS itself.
It can't be (IMO) that there are huge requirements placed on CAs -
including auditing - and at the same minute dismissed through some
questionable practices (like "we'll audit other CAs" or "we'll set up
CA's on the Falklands through remote"). IMO it's a security risk if the
physical and logical controls of a CA are not audited, confirmed and
attested by a third party auditor - the very same it is for any root CA.
That's why Mozilla decided that this is one of the requirements in order
to mitigate and minimize the risk for typical users.
It seems to me that this was the right approach as MITM attacks are
effectively prevented and encryption (and identification) to a high
degree guarantied. The recent example showed clearly that no CA issued
certificates were involved (and the failure was that of the user - with
some help from the UI). But overall, it seems to be working.
Basically what I'm asking for is, to apply the same requirements equally
upon all CAs, being it root or otherwise. It doesn't mean that Mozilla
has to review and approve each intermediate CA (so it can do that under
certain circumstances and is even required to do so as the Austrian
example has shown - even though they are subordinate only to some
extend), instead the applying party shall provide attestation confirming
those.
Having said that, I suggest that we start to process the requests for
inclusion in a more efficient way and stick to the schedules we've
defined. Kathleen does an excellent job and I really believe that we own
better performance to the CAs which applied. Kathleen is also filtering
and detecting many occurrences of problematic practices or
incompleteness in the requests, those which might be picked on in the
public discussion. This pre-filtering and pre-evaluation is an important
part of the process and will help to process those requests more
efficiently.
IMO a CA should not come up for discussion if clear deficiencies are
detected or the request most likely will receive some objections. This
includes the latest CA which had the OCSP problem (which was detected,
but nevertheless advanced to the public discussion) and this should have
been cleared upfront.
In this respect I suggest to review the upcoming CAs for public
discussion and process those with the most likely least problems first.
Schedule CAs, which might be problematic, which might be incomplete or
which most likely will fall into a grey area, back - in favor of those
which are clearly conforming to the Mozilla CA policy (and don't have
problematic practices).
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog: https://blog.startcom.org
_______________________________________________
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
