On Fri, Jun 20, 2008 at 5:44 PM, Eddy Nigg <[EMAIL PROTECTED]> wrote:
> This boils down to either of the two other options. If NSS isn't able to
> choose the DigiNotar root or treat the cross-signed certificate as
> revoked, than the email bit of Entrust should be set to off until the
> issue is solved in a different way. Incidentally Entrust failed to make
> sure that certificates signed by them adhere to their own policies
> (assuming that they themselves validate email addresses - don't remember
> now from memory) or that of the Mozilla CA policy.
>
> *** Which leads me to suggest once again that CAs should sign an
> agreement and/or acknowledgment of the Mozilla CA policy as a binding
> document. Acceptance into NSS should imply adherence to the requirements
> of Mozilla and nothing less than that ***

I tend to disagree.

I think that Mozilla needs to grow enough balls to boot out anyone who
doesn't continue to adhere to the standards for inclusion after
approval.  This CANNOT be a one-time requirement.  Otherwise things
like this will simply continue to happen -- and it's the users who
Mozilla seem to think rely on Mozilla to protect their security that
lose.

Mozilla's afraid of losing marketshare?  How about putting something
in NSS to inform the users of a previously-trusted certificate why
it's been removed?  A warning dialog saying something like "For your
protection, this email certificate's trust has been revoked because:
this CA has delegated its full trust to another CA which has been
shown to not adhere to the same level of identity verification for
email certificates.  We cannot guarantee that the person who sent this
is the person that the certificate states that it was issued to."
would be very useful here.

The system as it stands only works as long as all parties behave...
and there isn't anywhere near enough of a means (or desire :P) to
enforce the rules when they don't behave.  This, more than anything,
is what this thread is about.  This, more than anything, is what needs
to be resolved.

As well -- is there any system, at all, in place for reviewing changes
to CPSes to included roots?  Or do those changes slip through without
review (like Thawte's v1 to v2 to v3 CPS updates seemed to)?

Auditors always audit against the last-issued CPS.  That we know that
they passed an audit with an acceptable CPS and continue to pass their
audits is not enough.  If the CPS updates aren't evaluated and
negative changes acted on, the system is easily subverted -- and with
over 120 trust anchors in the store, that is far too many entities to
trust not to try to subvert the system for their own or their
shareholders' gain.

-Kyle H
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to