On 12/27/2008 12:52 AM, patri...@certstar.com:
Hi,
Patricia, even though I value your suggestion, I believe this is not the appropriate time and place to raise them. Please note, that you are not a certification authority but a reseller. It's the certification authority which needs to have reasonable and sufficient controls in place to prevent that from happening. They bear the ultimate responsibility.
Lately we have all seems that the certificate system is not 100% secure - mistakes happen. It might never become fully bullet proof but one simple change might help a lot.
I would agree with you in case I'd have had to resort to special tools and hacking your servers in order to overcome domain validation procedures. However in your case there was no validation at all. This is not a mistake, it's negligence from bottom to top. I believe that you are new to digital certification and it seems to me that you haven't understood the very basics of certification. However the fact that the issuing CA hasn't checked your implementations suggests gross negligence on their part and a complete failure of any controls that might have been in place. I believe that no such controls exist at all.
How about creating certificate type that is registered in a central database and require all CAs to check this DB before issuing new certificates?
Why? So that you can search the database for new customers? Do you believe that this would remove the burden to perform domain control validation? And why shouldn't I be able to get certificates for my domain from multiple certification authorities? Heck, your CA even issues certificates multiple times with the same subject line. I guess they won't be very happy with your proposal.
Once in that database no certificates could be issued for this specific domain. I think that most high profile sites would take advantage of such service.
High profile sites should use EV certificates anyway these days. Additionally it would require participation of all CAs, something which is very unlikely from happening. Otherwise a customer simply searches for another CA not participating...
-- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
