Hi Dimitris, 

‎You certainly echo the sentiment of others in this forum by directing me to the CABF but my concerns are particular to HARICA at this point. Simply put, the CABF BR has security gaps in section 3.2.2.4 which can result in certificate mis-issuance. There is no reason HARICA must tolerate such gaps in its own policies.

So the question I guess comes down to this: Is HARICA able to tighten its own controls regarding section 3.2.2.4 and go beyond what the BR has outlined?

Thanks.

From: Dimitris Zacharopoulos
Sent: Monday, February 22, 2016 2:23 AM‎


>> PK >> The one ‎change I would ask for, before inclusion of the HARICA root in the Mozilla trust store, is that the CPS be updated in regards to the use of these options. Where possible, I would just say that an option will not be used. If not possible, I would like to see details on how the vulnerabilities in each case will be mitigated.‎

All these methods are approved and published in the CA/B Forum Baseline Requirements. Perhaps it would be best to raise these concerns in the CA/B Forum's public mailing list (pub...@cabforum.org). In any case, if the CA/B Forum changes these methods, all CAs (including HARICA) will have to adjust their practices (and practice documents) to remove the verification methods you mentioned.‎
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to