On 22/2/2016 6:52 μμ, Peter Kurrasch wrote:
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.
Dear Peter,
The CA/B Forum has been working on updating that section of the BRs
regarding domain name validation rules. The latest proposal (not
officially approved yet) removes the ability for CAs to use validation
procedures other than the options that will be listed. HARICA will
update the CP/CPS when the BRs are updated. In any case, options 1-3 are
rarely used, mainly because the gr domain does not support whois
queries. Option 6 is also rarely being used. Nevertheless, we would like
to have all available approved options at our disposal.
Sincerely,
Dimitris
*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
