I've been trying to think of a ways to raise the bar for security using
practical approaches. Apologies for the long soapbox :)
The following is one idea - it would enable MF to provide a realtively
short summary of CAs and their capabilities. This may play well with
some other ideas (like allowing non-expert users to indicate their
level of security ranging from "I'm paranoid so lock everything down"
to "I don't want you to pick settings for me, I'll do it myself"). In
having a trivial self selection process at installation time and a
matrix of relevant data on hand it may be possible to improve security
policy selection for the user as well as turn up competition for
security and quality. At minimum it would enable the savvy user to make
relatively informed decisions.
What do you think about requiring that for each root or CA to be
included (new or legacy!) require that the CA respond to:
a What authentication do you do? Be as brief and specific as possible.
("for this root we do 2 email roundtrips at least 2 days apart but
within a week - each roundtrip contains a 64 bit PIN that must be
entered into a webform within 24 hours. We do not authenticate [and
therefor do not include in the certificate] the identity of the
enrollee") ("For this root we use 3 non-Internet methods to confirm
that the enrolee is entitled to use the legal identity specified for
the subject of the certificate as well as the right to use any domain
names specified for the subject of the certificate")
b What kind of assurances to you provide around "a"? Do you have a cash
warranty program? For how much?
c What kind of freshness service do you provide in case you have to
revoke a certificate for bad issuance or in case of a policy violation
by the subscriber? For CRL or OCSP do you always include a pointer in
the subscriber certificate (so that software can easily check the
revocation status)? If so how reguarly is the CRL or OCSP information
updated (monthly? weekely? hourly? real-time?).
d What kind of usage policy do you have? Please answer the Yes No
questions, please add extra policies information you feel is relevant.
d1 For certificates you want enabled for SSL Server identitification -
would you revoke the certificate if you learned it was being used for
phishing?
d2 For certificates you want enabled for Secure Email - would you
revoke the certificate if you learned it was being used for UCE?
d3 For certificates you want enabled for Software Signing - would you
revoke the certificate if you learned it was being used to sign
software that did not up front and clearly disclose it's behavior?
e Do you include an issuerLogo in every certificate? This helps enablee
consumers and relying parties to identify you and builds a reputation
of trust in your brand.
e What kind of software development, operational quality, and security
standards to you conform to, check all that apply:
e1 ISO 9000
e2 FIPS 140-1
e3 FIPS 140-2
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
