Eddy Nigg wrote: > On 10/02/2008 10:23 PM, Frank Hecker: > > > > Our goal here is to avoid having to evaluate lots and lots of > > subordinate CAs, and instead have the roots take care of their own > > subordinates and ensure they're compliant to policy. > > > > I'd like to pick this discussion up once again and evaluate what the > goals of Mozilla
The goals of Mozo are written somewhere else, and they only speak
softly to the issue of security from memory. I think it is worth
revisiting them, perhaps someone has them to hand?
> and the Mozilla CA policy really are.
I would interpolate the policy goals from the following snippets:
"based on the benefits and risks of such inclusion
to typical users of those product"
"would cause undue risks to users' security"
"might cause technical problems with the operation
of our software"
"provide some service relevant to typical users of
our software products;"
These speak to higher level goals. IMO, the rest of the policy
speaks to the tools that are chosen to assist in meeting those or
other goals. e.g., audit, criteria, DER,...
> Certainly the
> above is not the defined goal,
If anything, Frank seems to be implying a goal of "reasonable
efficiency" but that seems to not need to be stated. If anything,
he's talking about the efficiency of the tools that meet the higher
level goals (whatever they are), not the higher level goals.
> but rather provide some reasonable
> assurance about the CAs included in NSS and Mozilla products and allow
> users to rely on
The second part:
"allow users to rely on"
I'd flag as wrong. If there was a goal to allow users to rely on
CAs, certificates, etc, then there would be a requirement to tie in
the reliance of the Mozilla end-user, and the relying party of the
CA, as described in the CPSs and as promoted by the PKI literature
as a key person who has to read the key document and enter into this
game called reliance.
I'd suggest that Mozilla end-users, for the most part, in general,
are not relying parties. They may not rely on the certs, or they
are likely in for a surprise if they ever want to turn a failure
into a recovery.
They might *use* the certificates, and then go on to rely in other
ways. And, they may go to the CA's website and find out what it
takes to become relying parties ... But these are different things.
Then, the first part:
"reasonable assurance"
If you are defining it as the below, then that makes sense.
> - 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
However I would also raise a caution here: current Mozilla policy
is separated into EV and non-EV. I don't think this is written down
anywhere. Either way, the strength of the difference is such that I
do not believe it that the word "reasonable" applies any more.
E.g., if EV was "reasonable" then the DV/AV, etc should be turned
off as being "not reasonable". If the latter was "reasonable" then
we don't need EV. QED.
Which is to say, perhaps a different wording. Perhaps more like:
"provide a level of assurance that is appropriate
to the user's needs, and is matched by the
software's security and UI."
(Or somesuch, just brainstorming here.) Now, we would need to match
that to the (implied) policy goals above (assuming they are still good):
"provide a level of assurance that brings benefits
to the end-user's use of the product, without unduly
impacting:
* the risks and liabilities of the user,
* the compatibility and operation of the software,
* the risks, liabilities and obligations of other
parties (including CAs, Mozilla and developers)"
OK, I added the last one for free.
> Should any of the goals above not be that of Mozilla and its policy
> please speak up...
iang
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
