Please allow me to comment on a few responses... Gervase Markham wrote: > Following discussion on the CABForum email list, a new draft, a two-day > face-to-face meeting in San Francisco..... Taken from http://wiki.mozilla.org/User:Johnath/EVDraft13ReviewComments
It would be *nice*?? if revocations were never dropped.... /After discussion on the CA/Browser Forum mailing list, it was agreed that no change was necessary here. This requirement would place unwarranted burdens on CAs and certificate holders. The RFC states that revoked certs must appear at least on the first regularly-scheduled CRL update after the expiry date./ This is one of most lame things I ever heard (sorry for the language)...but let me explain this: / This requirement would place *unwarranted burdens* on CAs and certificate holders./ About which burden are they talking about? *Burden?* Supposed that EV certificates are issued only after a rigorous verification procedure, such certificates shouldn't be *never, ever* issued in first place, if there might be the slightest chance for a fraud or reason for future revocation. Full Stop! Can anybody explain to me, why an EV certificate should be a candidate for revocation ever? And if this would ever happen, this would be a very grave situation and such a certificate should never be dropped from the CRL/OCSP. And if they expect this to be an *unwarranted burden*, than perhaps I should ask about the dimensions of the expected revocations...which doesn't sound good at all! The only valid reason for revocation might be, that the user has lost or corrupted the private key or the private key is suspected to be compromised. In this case, the situation is similar grave and the CA must protect its client properly by revoking the certificate and *keep it revoked*. Also here I suggest, that the CA takes measures and provides proper support and training to the client in order to prevent this from happening in the first place. Additionally there is no burden whatsoever on the certificate holder as suggested in the response for having a revoked certificate listed in the CRL forever...or please enlighten me about which burden they are talking about. /The RFC states that revoked certs must appear.../ The RFC states...??? Really? I don't believe it! Well...the various RFCs state or don't state many things....If they want to go with the RFCs, so why bother creating guidelines which are supposed to improve things? The RFC don't require many things, still the proposed guidelines do exactly that...Common! This can't be serious.... _ Conclusion:_ Revocation of a certificate is not something which should be taken lightly - it certainly isn't equivalent to expiration. If this isn't going to be improved, then I suggest to make urgent changes to the code, in order to not allow connection to web sites with expired certificates anymore. Very unfriendly for the certificate holder and visitors so...Except that, obviously CRL checking should be ON by default anyway! Concerning audits: /...//that they were going to do an equivalence analysis between WebTrust and ETSI to see whether one could do an WebTrust EV Audit *on top* of an ETSI audit//.../ WOW! What an improvement! This almost knocked me out of my chair... Why the insistence of the Webtrust monopole? How about *opening up the guidelines and requirements for auditors without strings attached*, in order to enable potential auditors worldwide to perform third party audits? Why should this organization and its auditors hold CAs hostage and enjoy a monopole status? What about Europe, Asia, Africa, South America, Australia? Is only North-Americas Webtrust and its auditors capable and enlightened enough to do that properly? Or is it perhaps poorly about financial interests? _Conclusion:_ Mozilla should request the publishing of the guidelines for auditors and define requirements for auditors *without* any lock-in or requirements of membership to any organization. Potential auditors should be able to perform third party audits of CAs to the letter worldwide. Otherwise I suggest, that Mozilla as an open, global and community orientated organization refrains from voting in favor of the EV guidelines! -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
